Central Governance User's Guide - Axway Documentation Portal

Central GovernanceVersion 1.1.23 October 2017

User Guide

Copyright © 2017 Axway. All rights reserved.

This documentation describes the following Axway software:

Central Governance 1.1.2

No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.

This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.

Axway recognizes the rights of the holders of all trademarks used in its publications.

The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.

Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.

Contents

Preface 22

About Central Governance 22

Who should use this guide 22

Other documentation 23

Axway solutions 23

Help troubleshooting 23

Axway online 23

Accessibility 24

Screen reader support 24

Support for high contrast and accessible use of colors 24

1 Getting started 25

Getting started prerequisites 25

Getting started tasks 25

More help for beginners 26

Architecture 27

Concepts about Central Governance objects 28

Objects you can use in flows 29

Descriptions of objects in flows 30

Who manages objects in flows 33

Client and server communication profiles 33

Protocols in flows 34

Legacy flows for Transfer CFTs 35

First file transfers with Transfer CFTs 35

Prerequisites 35

Identify products 36

Add applications 36

Add a flow 36

Deploy the flow 37

Add a test file 37

Send a file 37

Monitor the transfer 38

Change direction of the flow and transfer another file 38

Execute a secure file transfer 38

First file transfer with SecureTransport and Transfer CFT 39

Prerequisites 40


Add an application 40

AxwayCentralGovernance 1.1.2 User Guide 3

Add a partner 40

Add a flow 41

Deploy the flow 42

Add a test file 42

Send a file 42


First file transfer with Gateway and Transfer CFT 43

Prerequisites 43



Add a partner 44

Add a flow 45

Deploy the flow 46

Add a test file 46

Send a file 46


2 Operations 47

Services 47

Descriptions 47

Services page 47

Status of Central Governance and services 47

Visibility service starts, stops in error 50

Central Governance services logs 50

Configuration and startup 52

Start configuration web server 52

Editing some fields requires follow-up actions 53

Secure external database connections 54

Complete configuration 55

Save and start 63

Default ports and firewall requirements 64

Resolving port conflicts 68

Processes 68

Logging in 69

Default credentials 69

Open log-on page 69

Log on 69

Audit reports 70

Supported browsers and requirements 70

Tips for using the user interface 71

License file 72

Flow and transfer monitoring 72

Options to retrieve data 72

Actions 73


Dashboards and reports 76

Run dashboards and reports 76

Default dashboards and reports 76

User privileges for dashboards and reports 77

Caution about audit and flow reports 78

Customize the Transfer CFT connection 78

3 Database administration 79

Internal storage database maintenance 79

Prerequisites 79

Silent mode option 80

Backing up data 80

Restoring data 80

More information 81

Embedded application database maintenance 81

Data directory 81

Backing up data 81

Restoring data 82

More information 82

Flow monitoring and audit data maintenance 82

4 Tools 84

cgcmd command 84

Parameters 84

Startup behavior 86

Command line interface 88

Prerequisite 88

Usage 88

CLI modes 89

Permissions enforcement 90

Use CLI remotely 92

Typographical conventions 92

Errors 93

CLI commands 94

Command usage details 102

Using APIs with Central Governance 109

Business use case 109

Managing flows with APIs 109

Introduction 110

API examples 113

API Manager and Central Governance 119

5 Certificates 132

Security service 132


Security menu 132

Administration menu 133

If CAs change after Transfer CFT registration 133

Governance CA 133

Business CA 135

Roles for managing certificates 135

Add system administrator role 135

Add certificate role 135

Assign role 136

Manage invalid or expired certificates 136

How it works 136

Usage 137

Alerts for expiring certificates 137

How it works 137

Configure 137

Replace SSO certificate 138

Prerequisites 138

Add entity 138

Import certificate 139

Replace certificate 139

Update SSO certificate before expiration 139

Certificates for HTTP, FTP, PeSIT 140

Keys for SFTP 142

6 User management 144

List users 144

Add a user 145

Steps 145

Notifying user of new account 145

Customizing email templates 146

View, edit, remove a user 147

View user 147

Edit user 147

Remove user 148

User lockouts 148

Unlock users 148

Configure lock-out threshold 149

Password recovery 149

Roles and privileges 149

Roles 149

Default roles 150

Privileges 151

Manage roles 152

Manage privileges 153


About the Default User 154

Password policy 154

User organizations 154

Manage organizations 155

If you use an external identity store 155

View list of organizations 155

Add organization 155

View, edit organization 156

Remove organization 156

7 Fine-grained access control 157

Objects, resources and actions for FGAC 157

FGAC-enabled predefined privileges 159

Steps to enable FGAC 160

Guidelines for creating FGAC privileges 161

Any FGAC-enabled object 161

Product, Product Group, Product Configuration and Update Package resources 161

Application and Application Group resources 164

Flow resource 166

HTMLDashboard and HTMLReport resources 167

Design web dashboards 168

8 Identity stores 169

Internal and external identity stores 169

LDAP identity store 169

Use Identity Store List page 170

LDAP identity store fields 170

Example LDAP setup for AD 174

Connection 174

LDAP tree 174

Authorization 175

User mapping 175

Log on as LDAP user 176

Prerequisites 176

Steps 176

9 Product registration 177

Transfer CFT registration 177

1. Registration request 178

2. Certificates for Transfer CFT 178

3. Mutually authenticated connection 179

4. Transfer CFT configuration updated 179

Use local settings for Sentinel 181

Registration approval 182


Assign a policy during registration 183

Change CAs after Transfer CFT registration 183

Transfer CFT registration troubleshooting 185

SecureTransport registration 187

Unique and duplicate server communication profiles 187

PeSIT services 188

Prerequisites 188

Registration process 191


Registration results 195

Status monitoring 195

Detect updated version 195

Remove and re-register 196

SecureTransport registration troubleshooting 196

Gateway registration 197

Prerequisites 198

Registration process 198


Registration results 201

Status monitoring 201

Remove and re-register 201

Gateway registration troubleshooting 202

10 Product updates 204

Update summary and workflow 204

Summary 204

Workflow 205

Manage product updates 205

Prerequisites 205

Upload and view updates 205

Apply an update to a product 205

Remove an update from the list 206

Troubleshoot product updates 206

11 Product operations 207

Product statuses and operations 207

Statuses 207

Operations 208

Transfer CFT status monitoring 209

SecureTransport status monitoring 209

Gateway status monitoring 209

Start and stop products 210

Start products 210

Stop products 210


View or edit product details 210

Product logs 211

View log 211

Filter log 211

Remove products 212

Guidelines 212

Steps 213

12 Transfer CFT configuration 214

Change configuration 214

Configuration change management 215

Configuration dictionary 216

Overview 216

Fields 216

Network configuration 216

Overview 216

Fields 217

About transfer acceleration 222

Bandwidth allocation 223

Overview 223

Fields 223

Transfer processing 224

Overview 224

Fields 224

Folder monitoring 227

Overview 227

Fields 227

Move and File examples 230

CRONJOBs 233

Overview 233

Fields 233

CRONJOB schedule syntax 234

Transfer request mode 236

Overview 236

Fields 237

Transfer list 237

Overview 238

Fields 238

Access and security 239

Access management options 239

Fields 240

Visibility 244

Overview 244

Fields 245


Logging 247

Overview 247

Fields 248

Log format 248

13 SecureTransport configuration 250

SecureTransport network zones 250

Overview 250

Manage network zones and communication profiles 251

Change SecureTransport configuration 252

Network zone and server communication profile fields 252

Network zone fields 252

Server communication profile fields 253

14 Gateway configuration 258

Change Gateway configuration 258

Deployment conflict management 259

Central Governance flows conflicts 259

Conflicts with legacy objects 259

Server communication profile fields 260

PeSIT 260

SFTP 262

FTP 264

HTTP 266

Gateway active/passive cluster 268

Flow definition 269

15 Policies 271

Policy lifecycle 271

Phases 271

Status changes 272

Business lifecycle scenario 273

Manage policies 274

Add a policy 274

Assign a policy 275

Deploy a policy 275

View, edit a policy 275

Copy a policy 276

Remove a policy 276

16 Applications 277

Manage applications 277


View or edit an application 278


Remove an application 278

Application groups 279

Flow management 279

Assign applications and add group at same time 279

Add group and add applications to it 280

Remove application from group 280

Manage application groups 280

Add a group 280

Edit a group 280

Remove a group 281

View group members 281

17 Groups 282

Grouping products 282

Things to know 282

18 Partners 283

Manage partners 283

View list of partners 283

Add partner 284

View, edit partner 284

Remove partner 284

Remove a server communication profile from a partner 284

Partner fields 285

General information 285

Server communication profiles 285

19 Unmanaged products 291

Use Unmanaged Products page 291

Add, view, edit unmanaged products 292

Add unmanaged product 292

View unmanaged product 292

Edit unmanaged product 292

Unmanaged product fields 292

Protocol 293

Details 294

Contact 294

20 General concepts about flows 295

Composition, deployment, execution 295

Flow composition 295

Flow deployment and execution 296

Direction in flows 296

Direction = Sender pushes file 297


Direction = Receiver pulls file 298

Flow lifecycle 298

Phases 299

Business scenario 300

Communication profiles 302

Relays in a flow 303

Flow identifiers 303

Flow patterns 304

Internal flow: One to one 305

Internal flow: One to many 307

Internal flow: Many to one 308

Internal flow: One to one via relay 309

Internal flow: One to many via relay 310

Internal flow: Many to many via relay 311

External flow: Inbound 312

External flow: Outbound 313

External flow: Partner to partner 314

21 SecureTransport flow concepts 316

SecureTransport as source in flows 316


Flow definition 317

SecureTransport as relay in flows 317

Overview 317

Relay examples 318

SecureTransport as target in flows 321


Flow definition 322

22 Transfer CFT flow concepts 323

Transfer CFT as relay in flows 323

Overview 323

Relay using store and forward 323

Relay without store and forward 325

Transfer CFT flow transfer modes 325

Transferring groups of files 325

Group transfer modes 326

Transfer mode: Sender pushes files 326

Transfer mode: Target pulls files 329

Flow conversion, validation 332

Transfer CFT source 333

Transfer CFT target 333

Transfer CFT relay 333

When conflicts are found 333


Transfer CFT store and forward 334

Flows with store and forward relays 334

Transfer CFT partner template 335

Transfer CFT broadcast and collect 336

Broadcast 336

Collect 337

Transfer CFT bandwidth allocation 337

How allocation works 338


Track a copied file 339

23 Gateway flow concepts 340

Gateway as relay in flows 340

Overview 340

Relay examples 341

Gateway as relay in PeSIT flows 343

Relay examples 343

Store-and-forward 345

Relay properties in a PeSIT flow 345

Gateway as relay in SFTP, FTP, or HTTP flows 346

Gateway as target in flows 346

Send properties 347


Flow definition 348

24 Defining flows 349

Prerequisites 349

Flow definition outline 349

Manage flows 350

Flow List page 350

Flow details page 350

Add a flow 351

Add source and target 351

Prerequisites 352

Steps 352

Next steps 353

Add a relay 353

Add relay 354

Remove relay 354

Specify the protocol 354

Prerequisites 355

Fields 355

HTTP client communication profile 362

PeSIT client communication profile 364


SFTP client communication profile 366

FTP client communication profile 368

Symbolic variables 370

Save and deploy a flow 372

Configuration change management 373

Back up flows from UI 373

Use flow backup 374

Change flow backup directory 374

25 SecureTransport fields in flows 375

Source fields in flows 375

Receive properties 375

File processing 378

Send properties 378

Target fields in flows 378

Receive properties 378

File processing 378

Send properties 378

Send properties in flows 380

Prerequisites 380

Multiple receivers 380

SFTP, FTP, HTTP: Send properties, sender pushes file 380

SFTP, FTP, HTTP: Send properties, receiver pulls file 382

PeSIT: Send properties, sender pushes file 384

PeSIT: Send properties, receiver pulls file 387

Receive properties in flows 389

Prerequisites 389

Multiple senders 389

SFTP, FTP, HTTP: Receive properties, sender pushes file 390

SFTP, FTP, HTTP: Receive properties, receiver pulls file 391

PeSIT: Receive properties, sender pushes file 393

PeSIT: Receive properties, receiver pulls file 395

File processing properties in flows 397

26 Gateway fields in flows 407

Receive properties in flows 407

Prerequisites 407

Multiple senders 407

PeSIT fields 408

SFTP, FTP and HTTP fields 410

Local properties in flows 411

Prerequisites 411

PeSIT fields 411

SFTP, FTP, or HTTP fields 412


Routing criteria 413

Prerequisites 413

Routing criteria properties 413

Broadcast behavior 417

Acknowledgment behavior 417

Transfer processing in flows 417

Transfer processing fields 417

Add or remove processing actions 418

Transfer processing execution 418

Send properties in flows 418

Prerequisites 418

Multiple receivers 419

PeSIT fields 419

SFTP, FTP or HTTP fields 420

PeSIT file properties for interoperability 422

27 Transfer CFT fields in flows 423

Transfer CFT source fields in flows 423

Source transfer properties 424

Source file properties 428

Transcoding and character translation 434

Source processing scripts 436

Transfer CFT target fields in flows 442

Target transfer properties 443

Target file properties 448

Target processing scripts 452

28 Transfer CFT legacy flows 457

Corresponding Transfer CFT objects 457

Flow migration example 458

Legacy flows lifecycle 459

Global statuses 459

Object statuses 460

Deploy and remove actions 460

Manage templates 461

List templates 461

Add template 461

Deploy template 462

View, edit template 462

Remove template 462

Send template fields 462

Transfer properties 463

File properties > filename 465

File properties > file encoding 467


File properties > record format 469

Processing scripts 470

Receive template fields 474

Transfer properties 475

File properties 477

File properties > file encoding 478

File properties > record format 480

Processing scripts 481

Manage partners 484

List partners 484

Add partner 484

Deploy partner 484

View, edit partner 485

Remove partner 485

Partner fields 485

Partner access 486

Protocol 486

Network sessions 487

Manage distribution lists 487

List distribution lists 487

Add distribution list 488

Deploy distribution list 488

View, edit distribution list 488

Remove distribution list 488

Distribution list fields 489

Processing scripts submission 490

29 Environment promotion and staging 491

Guidelines 491

Flow promotion use cases 492

Application to application 492

Application to application with relays 495

Application to business and business to application 495

Application to business and business to application with SecureTransport relay 497

Deploying promoted flows 498

Prerequisites for promoting flows 498

The import algorithm 498

Conditions about protocols and communication profiles 499

Conditions about participants 501

Conditions about file-transfer middleware 501

Summary of export and import actions 502

30 Alert rules 505

Flow error 505


Product configuration deployment error 506

Flow deployment error 506

Product failure 506

Product registration error 506

Certificate expiration 507

Use Alert Rule List page 507

Sort rules 507

Filter rules 507

Activate or deactivate a rule 507

Subscribe or unsubscribe to a rule 508

Copy a rule 508

Edit a rule 508

Remove a rule 508

Why deactivate an alert rule 509

Edit alert rule messages, recipients 509

Rule editing steps 509

Conditions fields 510

Notification fields 511

Use context values in notifications 512

31 Deployment monitoring 513

Deployment monitoring concepts 513

Monitoring for SecureTransport 513

Monitoring for Gateway 513

Monitoring for Transfer CFT 514

Flow deployment monitoring 515

Product updates 516

Predefined filters for deployment monitoring 516

Retry configurations, policies, flows, updates 517

Appendix A: Transfer CFT capacity planning 519

Planning steps 519

Performance factors 519

Workload characteristics 520

Performance objectives 520

Planning guidelines 521

Performance benchmarks 522

Test environment 522

Test scenarios 524

Recommendations 526

Appendix B: Transfer CFT corresponding parameters 527

Transfer CFT configuration in Central Governance and CFTUTIL 527

Network > protocols 527


Network > general 529

Network > general > keep alive between transfers 529

Network > pTCP 529

Network > UDT 530

Network > PeSIT tuning > transmission 530

Network > PeSIT tuning > synchronization 530

PeSIT password 531

Bandwidth allocation 531

Bandwidth allocation > priority 531

Transfer processing 532

Transfer processing > When file exists 532

Transfer processing > default scripts > source | target 533

Transfer request mode > asynchronous 533

Transfer request mode > synchronous 533

Transfer list 534

Transfer list > entry retention 535

Transfer list > entry retention > retention period 535

CRONJOBs 536

Cipher 536

Access and security > access management 537

Access and security > security > FIPS 538

Visibility 538

Visibility > servers 539

Visibility > events 540

Logging 541

Logging > file rotation 541

Folder monitoring 542

Transfer CFT legacy flows in Central Governance and CFTUTIL 544

Distribution list 544

Partners 545

Send template > transfer properties 547

Send template > file properties > files 548

Send template > file properties > file type (Linux and Windows) 549

Send template > file properties > file type (IBM i) 550

Send template > file properties > file type (z/OS) 550

Send template > file properties > record format 551

Send template > processing scripts > pre-processing 551

Send template > processing scripts > post-processing 551

Send template > processing scripts > acknowledgment 552

Send template > processing scripts > error 553

Receive template > transfer properties 553

Receive template > file properties > files 555

Receive template > file properties > file type 555

Receive template > file properties > record format 556


Receive template > file properties > file type (IBM i) 556

Receive template > file properties > file type (z/OS) 556

Receive template > processing scripts > post-processing 557

Receive template > processing scripts > acknowledgment 557

Receive template > processing scripts > error 558

Transfer CFT configuration for FTYPE=TEXT 558

Transfer CFT configuration for encoding/transcoding 558

Transfer CFT configuration for record format 560

Transfer CFT configuration for no file exists, file exists 560

Flow configurations in Central Governance and CFTUTIL 561

Flow definition: Source 562

Flow definition: Target 574

Transfer CFT configuration for FTYPE on Windows and Linux 585

Transfer CFT configuration for FTYPE on IBM i 586

Transfer CFT configuration for FTYPE on z/OS 586

Transfer CFT configuration for encoding/transcoding 587

Transfer CFT configuration for record format 588

Transfer CFT configuration for no file exists, file exists 589

Transfer CFT partners in flows 591

Operating systems and deployment correspondence 597

Appendix C: SecureTransport corresponding fields 599

Protocol fields in Central Governance and SecureTransport 599

PeSIT 599

SFTP 601

FTP 602

SecureTransport SFTP, FTP, HTTP flow definition 603

SecureTransport step definition mapping 603

Central Governance updates to SecureTransport objects 610

SSH keys 616

SFTP transfer site definition 617

FTP transfer site definition 620

HTTP transfer site definition 623

SecureTransport PeSIT flow definition 627

SecureTransport step definition mapping 627

Central Governance updates to SecureTransport objects 635

SecureTransport general definitions in flows 641

Subscription 641

Route package 643

Route 643

Certificates used for authentication 647

Certificates used with FTP, HTTP, PeSIT 647

Folder monitoring when SecureTransport is source in flow 648

Folder monitoring when SecureTransport is target in flow 650


Appendix D: Flows deployed on SecureTransport 651

Objects created in SecureTransport 651

Account for the sender 651

Account for the receiver 651

Objects deployed in sender account 652

Objects deployed in receiver account: Subscription 653

Deployed flow examples 653

Appendix E: Gateway corresponding fields 657

Server communication profiles 657

PeSIT protocol 657

SFTP protocol 659

FTP protocol 661

HTTP protocol 663

PeSIT flow configuration 664

Incoming exchange between the Sender and the Relay 665

Gateway relay properties 668

Outgoing exchange (between the Relay and the Receiver) 674

SFTP flow configuration 680


Gateway relay properties 684

Outgoing exchange between the Relay and the Receiver 687

FTP flow configuration 693


Gateway Relay properties 696

HTTP flow configuration 697


Outgoing exchange between the Relay and the Receiver 702

Gateway exchmd and sgatemd objects 706

exchmd (Gateway object for governance by Central Governance) 706

sgatemd (object for governance by Central Governance) 708

Appendix F: Objects created on Gateway 710

Product registration 710

Configuration updates 710

Static configuration entry 710

Key 710

SSH profile 711

Network profile 711

Flows deployed on Gateway 711

Remote site for the sender 711

Remote site for the receiver 712

Local site 712

Key 712


SSH profile 712

VFD 713

Application 713

Transfer model 713

Glossary 714


Preface

This guide describes the tasks for managing registered products such as Transfer CFT with Central Governance. This guide is the print version of the Central Governance online help and has the same content.

About Central GovernanceCentral Governance is the management platform for Transfer CFT and SecureTransport. It provides:

l A global data flow repository with end-to-end data flow definitions, from business applications and partners to the infrastructure level.

l Centralized supervision of data flows, consistent with definitions in the repository.

l Alert management to track problems linked to products or data flow processing, including a subscription mechanism for alert notifications.

l Standard web dashboards for a global view of data flow activity. You also can create custom dashboards.

l Automatic discovery of products to be managed.

l Centralized management of product configuration and associated deployment, including mass processing capabilities for highly distributed environments, which include groups and configuration policies.

l Centralized day-to-day operations management such as starting and stopping products and viewing their logs.

Who should use this guideThis guide is for people who administrate and use Central Governance to manage registered products. This guide presumes you have knowledge of:

l Your company’s business processes and practices

l Your company’s hardware, software and IT policies

l The Internet, including use of a browser

Others who may find parts of this guide useful include network or systems administrators, database administrators and other technical or business users.


Preface

Other documentationRefer to the Help Center tab in the user interface for complete user documentation with information about configuring and managing Central Governance. Online help also is available throughout the UI.

Axway solutionsCentral Governance, a Unified Flow Management (UFM) product, is a core part of Axway solutions that integrate selected Axway products to solve business issues. UFM governs data flows within your enterprise and externally with business partners. Reference solutions are:

l B2B Integration to exchange, transform, and process standardized electronic business documents within your B2B community.

l Managed File Transfer to securely transfer data in one-to-one, one-to-many, and many-to-many scenarios.

l Data Flow Integration to provide services for standardizing the exchange of business data with internal and external partners.

l Financial Integration to support data transfers in finance channels such as SWIFT and EBICS and transforms data into financial protocols.

Your organization might use Central Governance in the context of reference solutions. Find details about the product's role in documentation on the Axway Support support website at support.axway.com.

Help troubleshootingIf you have problems viewing or navigating the help, accessed via help links throughout the user interface, refresh or reload the page. Or clear your browser's history or cache, restart the browser and try again.

Axway onlineGo to Axway Support at support.axway.com to contact a representative, learn about training programs, or download software, documentation and knowledge-base articles. The website is for customers with active Axway support contracts. You need a user name and password to log on.


https://support.axway.com/


Accessibility

Axway strives to create accessible products and documentation for users. The following describes the accessibility features of Central Governance documentation.

Screen reader support l Alternative text is provided for images whenever necessary.

l The PDF documents are tagged to provide a logical reading order.

Support for high contrast and accessible use of colors

l The documentation can be used in high-contrast mode.

l There is sufficient contrast between the text and the background color.

l The graphics have the right level of contrast and take into account the way color-blind people perceive colors.


1 Getting started

This topic provides a workflow for new users of Central Governance to start using the product as a unified-flow management platform for supported Axway products. This is a high-level outline. Follow the references for more details about tasks.

The Central Governance user documentation assumes you have experience and operational knowledge of the products you register in Central Governance.

Getting started prerequisites l Central Governance is installed and started. See the installation guide or Configuration and startup on page 52.

l You have logged on to the user interface. See Logging in on page 69.

Getting started tasks 1. Review the services and components that comprise Central Governance. See Architecture on

page 27.

2. If you did not complete this task during initial configuration of Central Governance, determine whether you need to replace default certificates. Although you can use the default certificates, best practice is to replace the defaults with your own certificates. In any event, make sure you have resolved this before registering any product with Central Governance. See:

l CA services

l Business certificate authority on page 60

l Governance certificate authority on page 60

3. Add users and assign them roles with appropriate privileges for using the Central Governance user interface or the UIs of registered Transfer CFTs or both. See User management on page 144. Note that Central Governance also supports LDAP connectivity. See Identity stores on page 169.

4. Become familiar with tasks for basic operations of Central Governance. See:

l Operations on page 47

l Tools on page 84


1 Getting started

5. Register Axway products in Central Governance. Products supported for registration are:

l Transfer CFT 3.1.2 and higher

l Gateway 6.1.17 and higher

l SecureTransport 5.3.1 and higher

For details see Product registration on page 177 or the documentation of the product you want to register.

6. Learn about flows1, the primary objects Central Governance manages. See:

l Concepts about Central Governance objects on page 28

l General concepts about flows on page 295

l Transfer CFT flow concepts on page 323

l SecureTransport flow concepts on page 316

l Gateway flow concepts on page 340

7. Learn about using applications, partners and unmanaged products in flows. See:

l Applications on page 277

l Partners on page 283

l Unmanaged products on page 291

8. Create and deploy flows. See:

l Defining flows on page 349

l Save and deploy a flow on page 372

If you have used Transfer CFT previously, also see Transfer CFT legacy flows on page 457

9. Activate default alert rules, modify alert rules or subscribe to alert rules to receive alerts via email. See Alert rules on page 505.

10. Use the view all flows report to monitor file transfers. See Flow and transfer monitoring on page 72.

11. Use dashboards to view graphical displays of file-transfer activity. See Dashboards and reports on page 76.

12. Make plans for regular purging and archiving of records in the database related to audit reports and monitoring of flow transfers to avoid disk space issues. See Flow monitoring and audit data maintenance on page 82.

More help for beginnersIn addition to this getting started topic, there is a tutorial that walks beginners through the steps for using Central Governance to perform basic file transfers. The tutorial mostly uses default values and

1A flow specifies the technical details and communications protocols for exchanging business data between business applications or partners.


1 Getting started

is designed to be completed within a short time. See First file transfers with Transfer CFTs on page 35, First file transfer with SecureTransport and Transfer CFT on page 39. and First file transfer with Gateway and Transfer CFT on page 43.

ArchitectureA single instance of Central Governance can be deployed on one computer per network. The system supports active-passive resiliency in a clustering environment to bring another instance of Central Governance online if the primary fails. The following illustrates the architecture.

Note The Gateway portions of this documentation have a Restricted Availability status. This implies a limited availability for certain features or tasks that may still be under development or testing. Restricted Availability is a temporary state leading to a planned General Availability.

The following provides a high-level description of the Central Governance nodes. A node represents processes that deliver one or more services.

Core services

Supports the Central Governance graphical user interface, identity management and management of all functions related to product configuration and flow definition.


1 Getting started

Access and security

Provides a role-based access control model based on single sign-on. It manages permissions for users of Transfer CFT that are registered in Central Governance. The node also manages PKI1 and certificates. Optionally, it can integrate with an LDAP2 server for externally managed users and their credentials.

Visibility

Tracks transfers and manages notifications and alerts. It has an events monitoring table for users. It also can connect to an external SMTP server and send alert email messages to users specified within Central Governance. The messages provide links for accessing the Central Governance user interface for more information.

The Visibility service is powered by Axway Sentinel, a data-collection and reporting product for monitoring file transfers in unified-flow management solutions.

Agent

Supervises all Central Governance nodes. The main entry point of Central Governance, it starts, stops, and monitors nodes. The agent also deploys configurations and applies updates.

If a node fails and the status changes to crashed, the Agent will try to restart it. If the node cannot be restarted, the Agent stops all the other nodes, and the status of Central Governance changes to crashed.

Additionally there is the Transfer CFT connector, a plugin used as a proxy to connect to local or remote Transfer CFTs. Central Governance can communicate with few or many Transfer CFTs.

This version of Central Governance is compatible with Transfer CFT versions 3.1.2 and higher, SecureTransport 5.3.1 and higher, and Axway Gateway 6.17.1 and higher.

Central Governance has two embedded databases:

l Internal storage is a NoSQL MongoDB database for Central Governance configuration data, including policies, flows and partner definitions.

l Application database is a MySQL database for transfer tracking data, user roles and privileges, certificates and dashboards. Central Governance can be configured to use an external database instead for this purpose.

Concepts about Central Governance objectsCentral Governance has many objects with different purposes in managed file transfer (MFT3). This topic describes the objects and their roles.

1Public key infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.2Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.3Managed file transfer (MFT) refers to software or a service that manages the secure transfer of data from one computer to another through a network or over the Internet.


1 Getting started

Objects you can use in flowsObjects you can use in flows1 for transferring files are:

l Registered products

l Unmanaged products

l Applications and application groups

l Partners

Roles in flowsThe following table shows the roles of these objects in flows.

Role Product Unmanaged product

Application Application group

Partner

Source no (note)

yes yes yes yes

Target no (note)

yes yes yes yes

Relay yes yes no no no

Note Registered products must be associated with applications to be used as sources or targets in flows. Products, on their own, cannot be used as sources or targets.

When to use in flowsThe following table shows when to use the objects in file transfers.

Legend

A2A - Application to application transferA2B - Application to business (partner) transferB2A - Business to application transferB2B - Business to business transfer

Object Use in transfers

Product A2A, A2B, B2A (note 1)

Unmanaged product A2A, A2B, B2A



1 Getting started

Object Use in transfers

Application A2A, A2B, B2A

Application group (note 2)

Partner A2B, B2A, B2B

Note 1. Products are associated with applications.

Note 2. Application groups typically are used for filtering a set of applications with a common business characteristic, managing FGAC1, or defining a flow with a large set of applications. See Applications and application groups on page 32.

As the previous table infers, applications are associated with business applications within organizations and partners are associated with external organizations with whom you have business relationships. Central Governance is agnostic over the type of systems partners use to communicate with applications.

Descriptions of objects in flowsThe following summarizes each object you can use in flows.

ProductsProducts are instances of Axway products that can register with Central Governance and become governed by it. You can use Central Governance to:

l Start and stop products

l View and change the configurations of products (except SecureTransport is view only)

l View logs of products (except SecureTransport and Gateway)

l Associate products with applications and application groups for use as sources or targets in flows

l Use products as relays between sources and targets in flows

l Use products in a client or server role when communicating via any of multiple supported protocols

l Apply service packs and patches to products (except SecureTransport and Gateway)

You also can assign products to groups. Grouping products enables you to deploy configurations and perform operations all together. For example, perform operations such as starting or stopping from the command line interface by specifying the group of products.

1Fine-grained access control (FGAC) is a way to manage users' access to objects or capacity to perform actions. For example, you could enable some users to view specific objects in the user interface, but prohibit other users from viewing the same objects.


1 Getting started

For Transfer CFTs you can create policies. A policy represents common configuration settings for multiple Transfer CFTs. You can simultaneously deploy the same configuration changes to all Transfer CFTs assigned to a policy. For example, if multiple Transfer CFTs use parallel TCP (pTCP), you can create a policy with this configuration and deploy it to the Transfer CFTs.

Related topics

Product registration on page 177

Defining flows on page 349

Unmanaged productsUnmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be:

l Transfer CFTs 3.1.2 or higher that are not registered with Central Governance

l SecureTransports 5.3.1 or higher that are not registered with Central Governance

l Gateways 6.17.1 or higher that are not registered with Central Governance

l Earlier versions of Transfer CFT, Gateway, or SecureTransport that cannot register with Central Governance

l Axway products other than Transfer CFT, Gateway, or SecureTransport

l Third-party products

Unlike registered products, Central Governance cannot detect, start, stop or change the configurations of unmanaged products. However, the Central Governance user interface provides a way to define unmanaged products and include them in flows.

Unmanaged products:

l Support only the PeSIT protocol

l Can be used as sources, targets or relays in flows

l Can be used in a client or server role in communications

You can use multiple unmanaged products as sources or targets in flows, but only a single unmanaged product can be used as a relay, although there can be multiple relays.

Central Governance cannot manage the configurations of unmanaged products or apply service packs or patches on them. It also cannot deploy flows to unmanaged products. You must deploy flows on them manually.

Related topics

Unmanaged products on page 291

Defining flows on page 349


1 Getting started

Applications and application groupsAn application is the logical representation of a business software application that is the true sender or true receiver in a file exchange. An application represents a back-end enterprise resource planning system such as SAP or PeopleSoft.

All applications are associated with products. The products perform the actual communication between applications and other systems.

An application can be associated with one or multiple products of the same or different type. One or multiple applications can be used as the source or target in a flow. An application, by virtue of the associated products, also can be used in a client or server role in communications.

Closely related are application groups. These are logical sets of applications that can be used in flows as sources or targets. Application groups also can be used in client or server roles in communications.

When to use applications or application groups:

l Use applications, singly or multiple, when they represent clearly stable applications in flows that send the same type of information to accounting or financial applications.

l Use application groups when you want to add applications to flows while making no or few other changes to the flows. In short, you expect the number of participating applications to grow.

Related topics

Applications on page 277

Application groups on page 279

PartnersPartners represent entities such as companies that send or receive business data in file transfers governed by Central Governance flows. Partners can use third-party products or Axway products not registered in Central Governance to communicate with other parties over supported protocols.

Partners can be sources or targets in Central Governance flows. They also can be in client or server roles, depending on whether the partners initiate transfers. Partners support multiple types of communication protocols.

Only server communication profiles are managed in partner objects. Client communication profiles for partners are managed in flows.

Related topics

Partners on page 283

Communication profiles on page 302


1 Getting started

Who manages objects in flowsSome objects refer to a different abstraction level or perspective (for example, business versus technical).

l Partners, applications and application groups are about what participants communicate in a flow. Typically, business users manage these objects.

l Unmanaged products and products are about how participants communicate in a flow or mediation. Typically, technical users manage these objects.

Client and server communication profilesCommunication profiles define a a capability or capacity for a client or server to communicate with a sender or receiver. Communication profiles have properties and configurations for protocols (HTTP, SFTP, FTP, PeSIT). You use a client communication profile when the owner is the initiator of the communication. Otherwise, you use a server communication profile.

Client and server communication profiles can be shared between senders and receivers.

With Transfer CFT and unmanaged products, client-server communication are not represented in flows. They are implicitly and automatically used depending on protocol link properties (direction, authentication level, network protocol, acknowledgment).

ClientA client communication profile defines communication capability when the owner is the initiator, or requester, of the communication. You define the client authentication (user name and password, key or certificate). For SecureTransport you also define the network zone to use. With Gateway you can optionally define network zone(s) usage.

ServerA server communication profile defines communication capability when the owner is a receiver of the initialized communication.

A server communication profile defines the server connection (host, port or URL) and the server authentication. It also might specify requirements for SSL/TLS, FIPS and client authentication level.

PeSIT also requires you to define a network protocol to be used (TCP, UDT, pTCP) and is the only protocol where a server has a login/password for authentication.

For SecureTransport, which has the concept of network zone, a server communication profile can be attached directly to its server, via a private network zone, or to a reverse proxy (edges) in the DMZ.

Related topics

Communication profiles on page 302


1 Getting started

Protocols in flowsYou define protocols between segments in flows: between source and target, source and relay, relay and relay, and relay and target. Protocols are the communication medium between middleware initiators and receivers in file transfers. In a many-to-one or one-to-many flow, the protocol is a set of protocol links or exchanges. In many-to-many flows from applications to applications, the protocol is all combinations of source-target middleware.

Protocol detailsA protocol in a flow specifies:

l The protocol (HTTP, SFTP, FTP, PeSIT).

l The direction of the communication and initiator (client or server).

l Security, such as SSL/TLS server authentication, mutual authentication, password or key.

l The client communication profile used by the initiator.

l The server communication profile used by the receiver.

l Whether acknowledgments are sent (for example, PeSIT).

The Central Governance user interface enforces compatibility of the client and server communication profiles.

Protocol directionA file is transferred from the source to the target along the configured mediation route, and acknowledgments from receivers to senders go in the opposite direction. However, for each protocol in the flow you can select the initiator in the flow segment.

Sender pushes filesThe sender is the client initiator. You must use a client communication profile on the sender and a server communication profile on the receiver.

Receiver pulls filesThe receiver is the client initiator. You must use a server communication profile on the sender and a client communication profile on the receiver.

Related topics

General concepts about flows on page 295

Specify the protocol on page 354


1 Getting started

Legacy flows for Transfer CFTsLegacy flows for Transfer CFTs are a feature for enabling long-time users of Transfer CFT to transition flow management to Central Governance. Legacy flows address the following use cases:

l Flows can be managed in Central Governance for individual Transfer CFTs. In the Central Governance user interface, users can manage partners and send and receive templates for a specific Transfer CFT.

l Users can employ an established procedure to migrate Transfer CFT flow definitions to the Central Governance flow-management process.

Transfer CFT legacy flows on page 457

First file transfers with Transfer CFTs Use the following procedures in sequence to configure two Transfer CFTs in Central Governance for a file transfer1. The procedures are intended to help new users get started using Central Governance as the managing agent of multiple Transfer CFTs.

The procedures describe simple transfers, with and without security, and mostly using default settings in Central Governance for flows2. There are steps for sending a file from one Transfer CFT to another and monitoring the transfer in Central Governance.

For more help see Getting started on page 25 for a workflow for using Central Governance to manage registered products.

Prerequisites l Central Governance is installed and running.

l At least two supported versions of Transfer CFT are installed and have registered successfully with Central Governance. For details, see Transfer CFT registration on page 177 or Transfer CFT user documentation.

l Other than installing and registering, you do not have to perform any configuration tasks on the Transfer CFTs.

l You are logged on to the Central Governance user interface with a user with permissions to check product status and configure applications and flows. Minimally, the user is assigned to the default Middleware Manager role or a user-defined role with similar permissions.

l The Transfer CFTs to use in the transfers are started. To verify, select Products on the top toolbar in the Central Governance UI and check the status of the Transfer CFTs on the Product

1in Transfer CFT, the data transport and exchange of the actions to be taken on the data (read, write, create, delete) from one computer (partner) to another via a network. One of the partners is the sender and the other the receiver.2A flow specifies the technical details and communications protocols for exchanging business data between business applications or partners.


1 Getting started

List page.

l You have access to CFTUTIL commands on the participating Transfer CFTs.

Identify productsYou need the names (for the SEND and RECV commands) and the hostnames (to create the applications). Click Products on the top toolbar to open the Product List page. Copy or write the host names of the two Transfer CFTs you want to exchange files.

Add applicationsAn application1 must be associated with a registered product for the product to be used as a source or target in a flow. In these steps you add two applications. Each is associated with one Transfer CFT.

1. Click Applications on the top toolbar to open the Application List page.

2. Click Add application.

3. Type a unique name for the application.

4. Paste or type the host name for the sending or receiving Transfer CFT.

5. Click anywhere on the page. Because the host name is for a registered Transfer CFT, Central Governance populates the Products field with the Transfer CFT name.

6. You can ignore the other fields.

7. Click Save application.

8. Repeat the steps to add an application associated with the second Transfer CFT.

Add a flowDo the following to add a flow that contains the source and target applications. In this flow, the source connects to the target and transfers files to it.

1. Click Flows on the top toolbar to open the Flow List page.

2. Click Add flow.

3. Type a friendly name for the flow. For example, the daily sales data for stores in the western region might be named West Daily Sales.

You can ignore the details and contact fields.

4. Click Source to select the flow source. With the source type set to Applications and the product type set to Transfer CFT, click Add source. Select the application you want as the sender of files and click Select as source.

1The logical definition of a business application that is the real endpoint of a file exchange.


1 Getting started

5. Click Target to select the flow target. With the target type set to Applications and the product type set to Transfer CFT, click Add target. Select the application you want as the receiver of files and click Select as target.

6. Ignore the source and target sections for transfer properties, files properties and processing scripts. This flow uses the default settings for those.

7. Click Protocol between the source and target. Use PeSIT as the exchange protocol and Sender pushes file as the direction.

Type the flow identifier, an IDF1 in Transfer CFT. When the flow is deployed, this value is deployed to the participating Transfer CFTs. The flow identifier for the daily sales data from the western region might be named WR01.

Use the default settings for network protocol, SSL/TLS, acknowledgment and PeSIT properties.

8. Click Save.

Deploy the flowDo one of the following to deploy the flow on the source and target Transfer CFTs:

l If on the Flow List page, select the flow and click Deploy.

l If on the flow details page, click Deploy.

You can verify the deployment by doing one of the following:

l On the Flow List page, click the name of a flow to open its details page. Click the Deployed at link under the flow name at the top of the page to open the Flows section of the Deployment List page.

l Select Administration > Deployments and click Flows on the left side of the Deployment List page.

Add a test fileSet up a file to use in a transfer. For example, you can use a text file named test.txt that contains any text. Put the file in a directory the sending Transfer CFT can access. For example, on Windows the directory can be C:\test.

Send a fileDo the following to transfer the test file from Transfer CFT in the sending application to Transfer CFT in the receiving application.

Access the CFTUTIL commands on the participating Transfer CFTand execute a command in the following format:

1An IDF is a model file identifier, or file identifier, in Transfer CFT.


1 Getting started

CFTUTIL SEND IDF=<flow identifier>, PART=<name of the receiving Transfer CFT>, FNAME=<path and file name of the file to send>

Monitor the transferSelect Flows > Flows Report on the top toolbar to monitor the status of the transfer.

In the Dashboards UI 1. Select Administration > Dashboards to open the Dashboards UI.

2. Click My documents on the Menu.

3. Double-click an item to view status. For example, Middleware Manager.

Change direction of the flow and transfer another fileDo the following to change the direction of the flow and transfer another file. Previously, the sender pushed the file. With this change, the target pulls the file.

Change the direction of the flow 1. Click Flows to open the Flow List page.

2. Click the name of the flow you added earlier to open its details page.

3. Click Edit to change the flow.

4. Click the protocol between the source and target. Set the direction as Receiver pulls file.

5. In the file properties for the source, enter the name of the file on the source Transfer CFT to transfer. For example, on Windows C:\test\test.txt.

6. Click Save and Deploy.

Transfer the fileAccess the CFTUTIL commands on the participating Transfer CFTand execute a command in the following format:

CFTUTIL RECV IDF=<flow identifier>, PART=<name of the source Transfer CFT>

Execute a secure file transferThe previous file transfers were without security. Use this procedure to transfer a file with security.

1 Getting started

1. Change the configuration of the two Transfer CFTs to add a PeSIT protocol with security. Do the following for each Transfer CFT.

a. Click Products on the top toolbar to open the Product List page.

b. Click the name of a product to open its details page.

c. Click Configuration on the right side of the page.

d. Click Edit.

e. In the Protocols section of the page, click Add protocol.

f. Make sure SSL_DEFAULT is selected in the drop-down list.

g. Enter 1762 as the port in.

h. Click Save and Deploy to push the changed configuration to Transfer CFT. When prompted click Deploy configuration to deploy now and restart Transfer CFT.

i. Repeat these steps for the other Transfer CFT.

2. Add a flow as before in Add a flow on page 36 using the same applications. However, for the PeSIT protocol select Mutual authentication in the SSL/TLS field. Save and deploy the flow to the Transfer CFTs.

3. See Send a file on page 37 for the procedure to transfer a file.

You can monitor the file transfer as before.

First file transfer with SecureTransport and Transfer CFT

Use the following procedures in sequence to configure a Transfer CFT and a SecureTransport in Central Governance for a file transfer1. The procedures are intended to help new users get started using Central Governance as governance solution for Transfer CFT and SecureTransport.

The procedures describe simple transfers, mostly using default settings in Central Governance for flows2. There are steps for sending a file from a Transfer CFT to a SecureTransport, making the file available via SFTP to a business partner and monitoring the transfers in Central Governance.




1 Getting started


l At least one Transfer CFT and one SecureTransportare installed and have registered successfully with Central Governance. For details, see Product registration on page 177 or Transfer CFT user documentation.

l Other than installing and registering, you do not have to perform any configuration tasks on the Transfer CFTs. On SecureTransport, make sure that SFTP is enabled before registration.

l You are logged on to the Central Governance user interface with a user with permissions to check product status and configure applications, partners and flows. Minimally, the user is assigned to the default Middleware Manager role or a user-defined role with similar permissions.

l The Transfer CFT and SecureTransport to use in the transfers are started. To verify, select Products on the top toolbar in the Central Governance UI and check the status of the Transfer CFT and SecureTransport on the Product List page.

l You have access to CFTUTIL commands on the participating Transfer CFT.

Identify productsClick Products on the top toolbar to open the Product List page. Copy or write the host name of the Transfer CFT and the name of the SecureTransport you want to exchange files.

Add an applicationAn application1 must be associated with a registered product for the product to be used as a source or target in a flow.




4. Paste or type the host name of the sending Transfer CFT.




Add a partnerDo the following to add a business partner.



1 Getting started

1. Click Partners on the top toolbar to open the Flow List page.

2. Click Add partner.

3. Type a unique name for the partner.


5. Click Save.

Add a flowDo the following to add a flow that contains the source application and the target partner. In this flow, the source application sends files to SecureTransport via its Transfer CFT. SecureTransport then makes the file available to the target partner.


2. Click Add flow.

3. Type a friendly name for the flow. For example, the invoices to be sent to customers might be named Customer Invoices.



5. Click Target to select the flow target. With the target type set to Partners, click Add target. Select the partner you want as the receiver of files and click Select as target.

6. Click + Relay to add a relay to the flow.

7. Click Relay to select the product used as relay. Click Edit relay, select the SecureTransport you want to use as relay and click Select as relay.

8. Click Protocol between the source and relay. Use PeSIT as the exchange protocol and Sender pushes file as the direction.

Type the flow identifier, an IDF1 in Transfer CFT. The flow identifier for the customer invoices might be named CI01.


9. Click Protocol between the relay and target. Use SFTP as the exchange protocol and Receiver pulls file as the direction.

Use the default settings for client authentication, FIPS transfer mode and SFTP properties.

10. For the Client communication profile, click Create new one. Type a friendly name for the Client communication profile name and type the desired login and password the partner will use to connect to SecureTransport.

11. Ignore the source sections for transfer properties, files properties and processing scripts. This flow uses the default settings for those.



1 Getting started

12. Click Send properties on the relay. In Directory, type the directory in which the files will be made available to the partner. For example, type /invoices.

13. Click Save.

Deploy the flowDo one of the following to deploy the flow on the participating Transfer CFT and SecureTransport:







Send a fileDo the following to transfer the test file from Transfer CFT in the sending application to SecureTransport.


CFTUTIL SEND IDF=<flow identifier>, PART=<name of the receiving SecureTransport>, FNAME=<path and file name of the file to send>

The file is now made available by SecureTransport to the partner. In order to retrieve the file, the partner must:

1. Connect to SecureTransport with an SFTP client using the credentials defined in the flow.

2. Go to the /invoices folder.

3. Download the file.

1 Getting started

Monitor the transferYou can monitor the status of the transfers in Central GovernanceVisibility user interface.

Select Flows > Flows Report on the top toolbar to open the Visibility UI.

In the Dashboards UI 1. Select Administration > Dashboards to open the Dashboards UI.

2. Click My documents on the Menu.

3. Double-click an item to view status. For example, Middleware Manager.

First file transfer with Gateway and Transfer CFT

Use the following procedures in sequence to configure a Transfer CFT and a Gateway in Central Governance for a file transfer1. The procedures are intended to help new users get started using Central Governance as governance solution for Transfer CFT and Gateway.

The procedures describe simple transfers, mostly using default settings in Central Governance for flows2. There are steps for sending a file from a Transfer CFT to a Gateway, making the file available via SFTP to a business partner and monitoring the transfers in Central Governance.




l At least one Transfer CFT and one Gateway are installed and have registered successfully with Central Governance. For details, see Product registration on page 177 or Transfer CFT user documentation.

l Other than installing and registering, you do not have to perform any configuration tasks on the Transfer CFTs. On Gateway, make sure that SFTP is enabled before registration.



1 Getting started

l You are logged on to the Central Governance user interface with a user with permissions to check product status and configure applications, partners and flows. Minimally, the user is assigned to the default Middleware Manager role or a user-defined role with similar permissions.

l The Transfer CFT and Gateway to use in the transfers are started. To verify, select Products on the top toolbar in the Central Governance UI and check the status of the Transfer CFT and Gateway on the Product List page.

l You have access to CFTUTIL commands on the participating Transfer CFT.

Identify productsClick Products on the top toolbar to open the Product List page. Copy or write the host name of the Transfer CFT and the name of the Gateway you want to exchange files.

Add an applicationAn application1 must be associated with a registered product for the product to be used as a source or target in a flow.




4. Paste or type the host name of the sending Transfer CFT.




Add a partnerDo the following to add a business partner.

1. Click Partners on the top toolbar to open the Flow List page.

2. Click Add partner.

3. Type a unique name for the partner.


5. Click Save.



1 Getting started

Add a flowDo the following to add a flow that contains the source application and the target partner. In this flow, the source application sends files to Gateway via its Transfer CFT. Gateway then makes the file available to the target partner.


2. Click Add flow.

3. Type a friendly name for the flow. For example, the invoices to be sent to customers might be named Customer Invoices.



5. Click Target to select the flow target. With the target type set to Partners, click Add target. Select the partner you want as the receiver of files and click Select as target.

6. Click + Relay to add a relay to the flow.

7. Click Relay to select the product used as relay. Click Edit relay, select the Gateway you want to use as relay and click Select as relay.

8. Click Protocol between the source and relay. Use PeSIT as the exchange protocol and Sender pushes file as the direction.

Type the flow identifier, an IDF1 in Transfer CFT. The flow identifier for the customer invoices might be named CI01.


9. Click Protocol between the relay and target. Use SFTP as the exchange protocol and Receiver pulls file as the direction.

Use the default settings for client authentication, FIPS transfer mode and SFTP properties.

10. For the Client communication profile, click Create new one. Type a friendly name for the Client communication profile name and type the desired login and password the partner will use to connect to Gateway.

11. Ignore the source sections for transfer properties, files properties and processing scripts. This flow uses the default settings for those.

12. Click Send properties on the relay. In Directory, type the directory in which the files will be made available to the partner. For example, type /invoices.

13. Click Save.

Note For a transfer to work between Transfer CFT and Gateway, the properties for the file sent and the properties for how the file is received and stored should match



1 Getting started

Deploy the flowDo one of the following to deploy the flow on the participating Transfer CFT or SecureTransport:







Send a fileDo the following to transfer the test file from Transfer CFT in the sending application to Gateway.


CFTUTIL SEND IDF=<flow identifier>, PART=<name of the receiving Gateway>, FNAME=<path and file name of the file to send>

The file is now made available by Gateway to the partner. In order to retrieve the file, the partner must:

1. Connect to Gateway with an SFTP client using the credentials defined in the flow.

2. Go to the /invoices folder.

3. Download the file.

Monitor the transferYou can monitor the status of the transfers in Central Governance Visibility user interface.

Select Flows > Flows Report on the top toolbar to open the Visibility UI.

2 Operations

The following topics relate to Central Governance operations and processes.

ServicesCentral Governance provides services for governing the product. The services and their statuses are displayed on the Central Governance Services page. Click Administration on the top toolbar to open the page.

DescriptionsThe services – also called nodes – are:

l Core services – Manage basic platform functions.

l Access and Security – Manage certificates for securing file transfers.

l Visibility – Monitor file transfers. The Visibility service is powered by Axway Sentinel, a data-collection and reporting product for monitoring file transfers in unified-flow management solutions.

l Transfer CFT connector – Communications services for Transfer CFT.

l Application database – Data storage for access and security and visibility services. This service is listed only if the embedded application database is in use. If an external database is being used instead, this service is not displayed on the page.

l Internal storage – Data storage for core services.

Services pageOn the Services page you can:

l View status to determine if all services are running properly.

l Start a stopped service.

l View service logs to determine the cause of problems.

Status of Central Governance and servicesYou can view the status of Central Governance and its services on the

Central Governance Services page. Click Administration on the top toolbar to open the page.


2 Operations

Service statusesEach service – also called a node – displays one of the following statuses.

Started in error

A service is in abnormal state because it failed to start or stop. The status is always associated with an error message.

Stopped in error

A service is in abnormal state because it failed to initialize or it crashed. The status is always associated with an error message.

Started

A service has started.

Starting

From the time a start command occurs to the time the service returns a status or until a timeout.

Stopped

A service has stopped.

Stopping

From the time a stop command occurs to the time the service returns a status or until a timeout.

Unreachable

Central Governance cannot get the status for a service. This can occur if network issues prevent communication. This status is always associated with an error message.

You can start a stopped service in the user interface. Other operations are available using commands outside of the UI. See cgcmd command on page 84 for basic administrative functions and Command line interface on page 88 for more advanced options.

Operation Conditions

Start Perform on a stopped service.

Stop Perform on a started or in error service.

Force Stop Perform on an in error service.

Restart Perform on a started or in error service.


2 Operations

Central Governance statusesThe status of Central Governance as a whole is determined by the statuses of the various services.

In error

At least one service – also called a node – is started or stopped in error.

Unreachable

At least one service has an unreachable status.

In progress

At least one service is starting or stopping.

Partially started

At least one service is stopped and one is started.

Started

All services are started.

Stopped

All services are stopped. This status is not visible in the user interface.

Crashed

All services are stopped due to a recovery problem. This status is not visible in the user interface.

Crashed indicates Central Governance was stopped because the Agent was unable to recover a crashed node and reacted by stopping all nodes. This differs from the stopped status, which indicates Central Governance was stopped normally.

Unavailable

One or more services cannot start. Restart Central Governance to resolve. This status is not visible if you cannot connect to the user interface.

Service actionsThe actions available for Central Governance are:

l If at least one service is starting or stopping, no actions are available.

l If at least one service is stopped, the Start All action is available. The action applies only to stopped services.


2 Operations

Visibility service starts, stops in errorIf the Visibility service reports a status of started in error or stopped in error, this is likely the result of the operation timing out before the service can start or stop correctly. For example, stopped in error can occur when a large amount of data was in process when the service was being stopped.

You can prevent these errors by adding a properties file and setting values for properties within it.

1. Create a file named lifecycle.conf.

2. Add the following properties to the file:

start.timeout=

stop.timeout=

These properties require values in milliseconds. To determine values, consider how long it usually takes the Visibility service to start or stop after running cgcmd start or cgcmd

stop. For example, if it takes about two minutes for the service to stop, use

stop.timeout=120000. If stopped in error status continues to occur, increase the value

until the service stops normally.

The minimum valid value is 500 for both properties, but there is no reason to set either property this low.

3. Navigate to:

<install directory>\runtime\com.axway.nodes.sentinel_<UUID1>\uma

4. Add a subdirectory under uma named capabilities.

5. Copy the lifecycle.conf file to:

<install directory>\runtime\com.axway.nodes.sentinel_<UUID>\uma\capabilities

6. Restart Central Governance for the new properties to become effective.

Central Governance services logsUse the Central Governance services logs to monitor usage or diagnose problems. There is one summary log for all core services and one log for each service.

View log 1. Select the Administration tab to view the list of Central Governance services.

2. Locate the service whose log you want to view and click View log.

1A universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.

2 Operations

The log page is displayed where you can:

l Click Refresh anytime to update the log entries.

l Sort the entries by newest or oldest.

l Filter the entries, saving filters for future use.

l Use the Log drop-down list to view the log of a selected service.

The following describes all log table columns. The columns apply to the service logs as noted.

Date/time

The server date and time of the log entry. Format: YYYY-MM-DD hh:mm:ss.

Applies to logs for all services.

Service

Identifies the internal service associated with the log entry.

Applies to log for Core Services.

Level

Level of the log entry. Levels, from highest to lowest verbosity, are DEBUG, INFO, WARNING, ERROR.

Applies to logs for Core Services, Access and Security, Visibility and Transfer CFT connector.

Message

Actual log message.

Applies to logs for all services.

Filter logYou can filter a log by one or multiple conditions. The filters you add are saved until deleted or the browser cache is cleared. You can, for example, filter by level, leave the page and return, and the displayed log entries are filtered by level.

Click Filter and select a filter type to add. You can add multiple filters.

Not all filter types are available for all logs. For example, the service filter is available only for the Core Services log.

Date/time

You can filter log entries by age in hours or generated within a date range.

Service

You can filter log entries by full or partial service names. This filtering is not case sensitive. Only one filter can be set for the service column.


2 Operations

Level

You can filter log entries by severity. This filtering provides cumulative verbosity. If you filter by Info level, Info messages and all message levels above the Info level are displayed. If you filter by Fatal level, only fatal log entries are displayed.

Message

You can filter log entries by full or partial messages. This filtering is not case sensitive. You can filter by one or more messages.

Added filters are displayed at the top of the page. Click a filter to change it. Click the appropriate X icon to delete a single filter or to clear all filters.

Configuration and startupYou can change the configuration of Central Governance that was set initially after installation. You can change any settings except:

l You cannot change the application database type (internal or external). If Central Governance has been installed with the embedded database, it is not possible to switch to an external one. Likewise, if Central Governance has been installed with an external database, it is not possible to activate the embedded one and switch to it afterwards.

l If the database type is external:

o You cannot change from one database to another. For example, you cannot change from Oracle to MySQL.

o You cannot use a fresh database. You must use the same database or an exact duplicate of the old one. For example, if the database is MySQL, do nothing to keep using it. Otherwise, you must dump the database and install the dump on a new MySQL database. The new database must have the same tables and data as the old database. You must ready the duplicate database before starting the configuration process.

Only change the configuration using the configuration user interface. Do not instead change property values in configuration files.

Although except for the database exclusion you can change values of any fields, additional tasks are required when values of some fields are changed. See Editing some fields requires follow-up actions on page 53.

Start configuration web serverYou must stop Central Governance and then run the cgcmd configure command from the installation directory to start an internal web server that hosts the configuration user interface.

Once the web server has started, the command lists the URL for opening the web page in a browser. If the computer on which the command was executed has a default browser, the page opens automatically. Otherwise, open the page with the provided URL.


2 Operations

By default the web server runs on port 8082. But you can change the port when invoking the command. For example:

cgcmd configure -p <port>

See cgcmd command on page 84 for more information about the cgcmd command.

Editing some fields requires follow-up actionsAfter using the configuration web page the first time to initially configure Central Governance, you can use the page again to edit field values. However, changing some fields requires performing additional tasks to make sure Central Governance continues running properly.

General > FQDN

Changing the FQDN field also requires you to update all registered products manually with the new host value. If you do not, Central Governance cannot reach the registered products. The status of registered products becomes unreachable.

Access and Security > HTTPS client authentication port

Changing the HTTPS client authentication port field also requires you to redeploy the configurations of all registered Transfer CFTs after restarting Central Governance. Redeploying makes the port change effective on the Transfer CFTs. Only Transfer CFTs are affected and not any other types of registered products.

Access and Security > Shared secret

Changing the shared secret in Central Governance requires also changing the shared secret used by registered products. The shared secret is used to establish connections between Central Governance and registered products.

Change the shared secret in Central Governance and SecureTransports at the same time. To change:

1. Stop Central Governance, start the configuration web server and change the shared secret on the configuration page.

2. Stop the Central Governance agent in SecureTransport and change the shared secret on its Central Governance configuration page.

3. Restart Central Governance.

4. Restart the SecureTransport Central Governance agent.

Change the shared secret in Central Governance and Gateway at the same time. To change:

5. Stop Central Governance, start the configuration web server and change the shared secret on the configuration page.

6. Stop the Central Governance agent in Gateway, run the Gateway Installer in configure mode, then change the shared secret on Central Governance configuration dialog.

7. Restart Central Governance.

2 Operations

8. Restart the Gateway Central Governance agent.

For Transfer CFT you don't have to change the shared secret immediately. Transfer CFT communicates with Central Governance differently than SecureTransport or Gateway. If the shared secret is changed in Central Governance, Transfer CFT Copilot can still connect to Central Governance without changing the shared secret. However, if a change is made in Central Governance that affects its communication with Transfer CFT, such as changing a CA, the shared secret in Transfer CFT must be current. See If CAs change after Transfer CFT registration on page 133 for more information.

To change the shared secret in Transfer CFT, stop the product, run the installer in configure mode and change the shared secret.

Access and Security > Business certificate authority

Changing the business CA also requires you to make changes in the registered Transfer CFTs. See Change CAs after Transfer CFT registration on page 183 for more information.

Access and Security > Governance certificate authority

Changing the governance CA also requires you to make changes in the registered Transfer CFTs. See Change CAs after Transfer CFT registration on page 183 for more information.

Visibility > Front-end port

Changing the Front-end port field also requires you to redeploy the configurations of all registered Transfer CFTs after restarting Central Governance. Redeploying makes the port change effective on the Transfer CFTs.

You must change the front-end port for registered:

l Gateways: Using the Gateway Installer configure mode in the Central Governance configuration dialog.

l SecureTransports: Using the SecureTransport administration user interface.

Transfer CFT connector > Secured communication port

Changing the Secured communication port field also requires you to update all registered Transfer CFTs manually with the new port value. If you do not, Central Governance cannot reach the registered products. The status of registered products becomes unreachable.

Secure external database connectionsIf you choose to use an external database, instead of the default embedded database, to store data in the application database, you can have secure JDBC1 connections for one or more of the following:

l Access and Security service

l Visibility service

1Java database connectivity (JDBC) is an API for the Java programming language that defines how a client can access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.


2 Operations

l Dashboards service

This option is available for all supported database types.

To have secure connections you must:

1. Obtain valid server certificates and configure your database system to use them.

2. Select Use secured JDBC connection for a service on the Central Governance configuration page.

3. Click Browse and select the public certificate file to upload for the secure connection. This file contains the CA1 or trust chain for the SSL certificate used by the external database server. The imported file must contain only one certificate. Supported keystore formats are PKCS#12 and Java KeyStore (JKS).

4. Enter a password for the certificate. This is required to enhance security even though the uploaded file does not contain a private key.

Complete configurationChange fields as you require on the configuration page.

When appropriate, the user interface provides default values in the fields and as tooltips.

Many of the fields are for port values. See Default ports and firewall requirements on page 64 for the list. One reason to use your own rather than a default value is port conflicts. A default port assignment could conflict with a port used by another application or process on your system. Ports already in use are detected when you submit the configuration page, which enables you to select other values. However, you also can use a command to discover and resolve port conflicts. See Resolving port conflicts on page 68.

In addition, when firewalls are present, some ports must be opened to enable communications with remote systems.

GeneralFQDN

The name used by systems outside your network to connect to Central Governance. This can be a fully qualified domain name (FQDN), IPv4 address or a load-balancer URL. FQDN example: myhost.domain.com.

You can use an IP address in this field only when it can be resolved to a valid FQDN.

Host name

The host name for Central Governance. This can be the host name only or the same as the FQDN field value. This also can be a virtual name for running Central Governance in an active-passive cluster.

1A certificate authority (CA) is a trusted third party that issues digital certificates for use by other parties.


2 Operations

This is not necessarily the machine where Central Governance is installed, but the machine where it will run. Technically, the name refers to the network card where Central Governance will bind the sockets for all the ports in use.

UI port

The SSO port for connecting in a browser to the Central Governance user interface.

LicenseClick Browse and select the Central Governance license file in the file system. You must have a valid license file to run Central Governance. See License file on page 72 for more information.

Log levelThe level of events written to log files for Central Governance and its services. The log levels, from lowest to highest verbosity, are:

l Error

l Warning

l Info

l Debug

l All

Selecting the highest verbosity level might slow the performance of Central Governance.

SMTP serverCentral Governance requires a connection to an external SMTP server to send notifications and alert messages to its users. You might have to consult with your network administrator to configure this.

SMTP server host

The name of the SMTP server for outbound email messages.

SMTP server port

The port for outbound messages typically is 25. Outbound messages include alerts and notifications to users of Central Governance.

Authentication

Requiring authentication for outbound messages is uncommon. If your server requires authentication, click Yes and complete the user name and password fields.


2 Operations

AgentCentral Governance name

Unique name of the Central Governance agent. This name is used to identify this instance of Central Governance in communications with other instances of Central Governance and with registered products.

Port

Agent cluster infrastructure listening port. External agents use this port to register products with Central Governance and communicate with it.

Registration approval

Indicates if products require approval before registering with Central Governance. Products, as of Transfer CFT 3.2.2, Gateway 6.17.1, and SecureTransport 5.3.1, must be approved before the registration process begins when this is set to Yes.


Core servicesHTTPS port

User interface (non-SSO) HTTP over SSL1. This is the internal port on which the SSO2 server connects to Central Governance core services3.

Application databaseType

Indicates whether to use the embedded internal database or an external database for storing application data. You can use the embedded database only if your user license allows. If not, you only can use an external database. Note that you cannot change the type once Central Governance has been fully installed. So it is not possible to switch from an embedded database to an external one afterwards, and vice-versa.

Note The embedded MySQL application database is for use by Central Governance only. Do not try to use this database with any other Axway or third-party product.

1Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information.2Single sign-on (SSO) enables a user to log on once and gain access to all products managed by the SSO system without being prompted to log on again for each product.3Core services support the Central Governance graphical user interface, identity management and management of all functions related to product configuration and flow definition.


2 Operations

If you select External, you are choosing to use an external database. Complete the database connection fields in the database sections under:

l Access and security on page 58

l Visibility on page 61

l Dashboards database on page 62

The following fields apply only when you have selected to use the internal MySQL database for storing application data.

Port

Port for the embedded MySQL database.

Root and confirm root password

Password for the embedded MySQL database. The root user can create other users of the service.

Access and securityExecutive port

Internal administrative port that runs and monitors the Access and Security service.

HTTP port

User interface and API server port for HTTP plain connections.

HTTPS port

User interface and API server port for HTTP connections over SSL.

PKI port

PKI1 legacy socket server. Central Governance does not use this port by default.

PKI SSL port

PKI legacy secure socket server. Central Governance does not use this port by default.

HTTPS client authentication port

Client authentication for HTTP over SSL. This port is used when Transfer CFTs register with Central Governance.

1Public key infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.


2 Operations

Component authenticationShared secret and confirm shared secret

The value you set for the shared secret is used by products when registering with Central Governance. You must provide this value to operators of products before they attempt to register.

The shared secret, like passwords, is encrypted in the database.

EncryptionKey for encrypting and decrypting passwords in the database and encrypting when exported. Also, encrypting private certificates and keys when exported. This key is the default when exporting. The value must be at least 8 characters.

Confidential information such as passwords and private certificates used in Central Governance are encrypted to enhance security. The encryption algorithm is based on the key you enter.

DatabaseFields to complete depend on whether you selected to use an internal or external database for the application database.

If internal, the fields are:

User

User of the database schema.

Password and confirm password

User password.

If external, select the database type and complete the fields for connecting to the database.

The database user must have rights to create tables.

For Oracle, you can define the URL using one of the following methods:

l Using the SID of the database. For example:

jdbc:oracle:thin:@{host}:{port}:{SID}

l Using the service name of the database. For example:

jdbc:oracle:thin:@{host}:{port}/{serviceName}

If using Oracle RAC, the URL must include the service name.

You only have to create the database or schema in the database application. Central Governance creates the tables when you start the server the first time. However, you must use a different database or schema for access and security, visibility and dashboards.


2 Operations

If the database is external, you can click Check database connection to verify the values for connecting to the database.

See Secure external database connections on page 54 if you want a secure JDBC connection.

Business certificate authorityGenerates end-entity certificates used by products to secure transfers. Use the default Central Governance intermediate certificate used by the internal CA to generate end-entity certificates. Or, select the custom option and import a password-protected JKS or P12 certificate authority file.

If you choose the custom option, the imported file must contain only one certificate. In the certificate the Basic constraint isCA must be set to true, indicating the certificate is a self-signed root certificate or an intermediate certificate.

Best practice is to change the default business CA with a CA certificate signed by a known CA.

After registering Transfer CFTs in Central Governance, changing the business CA might affect flows. See If CAs change after Transfer CFT registration on page 133 for more information.

Governance certificate authorityGenerates end-entity certificates used by Central Governance to secure communications internally and with other products. Use the default Central Governance intermediate certificate used by the internal CA to generate end-entity certificates. Or, select the custom option and import a password-protected JKS or P12 certificate authority file.

If you choose the custom option, the imported file must contain only one certificate. In the certificate the Basic constraint isCA must be set to true, indicating the certificate is a self-signed root certificate or an intermediate certificate.

Note If you use an intermediate certificate as a governance CA certificate, you must add the root CA certificate that signs this intermediate certificate in the Transfer CFT PKI database.

Best practice is to change the default governance CA with a CA certificate signed by a known CA.

After registering Transfer CFTs in Central Governance, changing the governance CA might result in Transfer CFTs becoming unavailable. See If CAs change after Transfer CFT registration on page 133 for more information.

NotificationsCertificate expiration

Number of days until a certificate expires. The value must be 1 or greater, but not exceed 90 days. The default value is 60 days.


2 Operations

VisibilityFront-end port

Plain-text listening port for events such as flow monitoring, alert notifications and auditing. The port is used by Central Governance and registered products that use the plain-text Visibility service.

Front-end HTTPS port

Secured listening port for events such as flow monitoring, alert notifications and auditing. The port is used by Central Governance and registered products that use the secured Visibility service.

RMI port

Communications port between the user interface and the server.

HTTP port

Port for connecting in a browser to the Visibility service correlation user interface.

HTTP stop port

Port for administrating the web server that runs the dashboards option.

HTTPS port

Port for connecting in a browser to the dashboards user interface over SSL.

SSO port

Port for connecting in a browser to the dashboards user interface over SSO1.

DatabaseFields to complete depend on whether you selected to use an internal or external database for the application database.


User



User password.



1Single sign-on (SSO) enables a user to log on once and gain access to all products managed by the SSO system without being prompted to log on again for each product.


2 Operations










Dashboards databaseFields to complete depend on whether you selected to use an internal or external database for the application database.


User



User password.












2 Operations


Transfer CFT connectorRegistration port

Port on which Central Governance listens for initial connections from Transfer CFTs when the Transfer CFTs are registering with Central Governance.

Secured communication port

Port used for mutually authenticated communications between Central Governance and Transfer CFTs.

Internal storagePort for the embedded MongoDB NoSQL database for storing configuration data.

Root and confirm root password

Password of root user for the embedded NoSQL database. The root user can create other users of the service.

User

User of the NoSQL database. This is the user Central Governance uses to communicate with the internal storage database.


User password.

Save and startReview the values on the configuration page. Click Save and start when you are sure the values are correct.

Do not install or run Central Governance as root on Linux. Use a common user.

After clicking Save and start, a page is displayed showing the startup status. If all goes well, green check marks are displayed for the following nodes:

l Application database

l Access and Security

l Visibility

l Internal storage

l Core services

l Transfer CFT connector


2 Operations

When Central Governance has started, you are prompted to click a link for opening the log-on page in a browser. See Logging in on page 69.

An X within a red circle indicates a problem with a node. If this occurs, the system rolls back any nodes that had started before encountering the problem node. The rollback stops and deletes any nodes that had been added successfully. After the rollback, you can click Edit configuration, check values and try again to start.

You can review the cgcmd.log file in the Central Governance logs directory for troubleshooting clues. You also can review the cg_support_yyyy-mm-dd_hh-mm-ss file that writes to the Central Governance install directory when a system start fails and rolls back. This compressed file contains a copy of the initial-settings.properties file and copies of the Central Governance logs, config and scripts directories. It also contains log files for nodes and other node files. You can send the file as an email attachment to Axway support when working with them to troubleshoot an issue.

Default ports and firewall requirementsThe following are the default ports used in Central Governance, except when noted for external systems, to listen for connections. All ports are configurable during the configuration process after installation or later. You can place the cursor over a port field to display the default value on the configuration web page.

If a firewall is in use, open the ports marked as required or optional, when applicable, in the following table. This enables communications with remote systems.

l Required - Port is needed to enable communication between Central Governance and registered products.

l Optional - Port must be opened only when the functionality is used.

l Not required - Communications are internal to Central Governance and opening ports does not apply.

When reason = external server the port is used by an external system to listen for connections, not internally by Central Governance, and must be opened on the remote computer. Port 444, used by SecureTransport for REST API, also is an external port.

Default port

Use Used by Reason Allow port through firewall

External

25 External SMTP1 server to send outbound messages

External server Required

1Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail (email) transmission.


2 Operations

Default port


389 External LDAP1 server

External server Optional

444

8444

REST2 API3

444: For SecureTransport root installation

8444: For SecureTransport non-root installation

SecureTransport Administrator

Product communication Required

1433 External SQL Server application database

SQL Server External server Optional

1521 External Oracle application database

Oracle External server Optional

1766 Web Services (plain text)

Registered Transfer CFT

Product registration Required

1767 Web Services (SSL) Registered Transfer CFT

Product registration/communication

Required

3306 External MySQL application database

MySQL External server Optional

Internal

1303 Secure Visibility port for monitoring, alerting, and auditing events

Registered products

Visibility events Required

1Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.2Representational State Transfer (REST) is a software architecture style for building scalable web services. REST consists of a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.3An application programming interface (API) is a protocol intended for use as an interface by software components to communicate with each other.


2 Operations

Default port


1305 Visibility event server for monitoring, alerting and auditing events

Registered products

Visibility events Required

1308 Visibility service RMI1

Not required

1309 Visibility HTTP service (for example, correlation user interface)

End user UI administration Optional

3307 Embedded MySQL application database

Not required

5117 Access and Security service executive

Not required

5701 Agent cluster for communication with product agents

SecureTransport, Gateway

Product communication Required

6090 Access and Security service HTTP

End user Not required

6453 Access and Security service HTTPS

End user UI administration Optional

6666 Access and Security service HTTPS client authentication

Transfer CFT Product communication Required

6667 Visibility service dashboards SSO2

Not required

1Remote method invocation (RMI) is a distributed object technology for the Java programming language. It is available as part of the core Java application programming interface (API) where the object interfaces are defined as Java interfaces and use object serialization.2Single sign-on (SSO) enables a user to log on once and gain access to all products managed by the SSO system without being prompted to log on again for each product.


2 Operations

Default port


6900 Central Governance user interface.

End user UI administration Required

7000 Access and Security service PKI1 socket server

Not required

7101 Access and Security service PKI secure socket server

Not required

8005 Visibility service dashboards HTTPS

Not required

8081 Core Services HTTPS Not required

8082 Central Governance configuration user interface

End user UI administration Required

8086 Visibility service dashboards HTTP

Not required

12553 Transfer CFT connector registration


12554 Transfer CFT connector communication


27017 MongoDB NoSQL database for internal storage

Not required

1Public key infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.


2 Operations

Resolving port conflictsIf you suspect a port conflict, use the netstat command to generate a list of ports in use on your system. You can resolve conflicts by changing the port used by Central Governance or by another application or process.

The command can be executed in the following ways.

Windows

In a command prompt or DOS window, type netstat -a -n or netstat -an to display a list of ports in use. You can instead type netstat -a -n | more to page through the list.

Unix and Linux

On a command line, type netstat -a -n or netstat - an to display a list of ports in use. Or, to find whether a specific port is in use, type netstat -a | grep [port number].

ProcessesThe following table lists the processes that are running when all Central Governance nodes are started. Some nodes have more than one process.

The Agent and some nodes are Java virtual-machine processes.

Process Description

java Agent

mongod Internal storage node

mysqld Application database node *

java Operating node

java Access and security node JVM 1

java Access and security node JVM 2

java Visibility node JVM 1



* When Central Governance is used with the embedded MySQL database.

The processes are the same on all supported operating systems, but on Windows have the extension .exe.


2 Operations

Logging inYou are ready to log on the user interface after Central Governance has started.

Default credentialsUse the temporary password for the default credentials only when logging on the first time. Use your own assigned credentials if you have them.

l Org is the organization

l [email protected] is the user ID

l Initial01 is the temporary first-time password

You are prompted to change the temporary password when logging on as this user the first time.

Open log-on pageYou can open the Central Governance log-on page in a browser by:

l Clicking the link at the bottom of the configuration status page after Central Governance has started.

or

l Opening the log-on page with a URL in the following format:

https://<host>:<UI port>

Where:

l <host> is the fully qualified domain name or IP address of the computer running Central Governance

l <UI port> is the port Central Governance listens for connections. The default is 6900.

If a message is displayed about an untrusted certificate, you must accept the certificate to continue to the log-on page. The message is normal with some browsers; you can ignore the warning.

Log onLog on with your assigned credentials or the default credentials with the temporary password if logging on the first time. You can click Help at the top right of the page after logging on to open the online help.

2 Operations

Audit reportsMany events related to executed actions are tracked, typed and stored in the database. These can be actions by users, the server, organizations or managed products. Central Governance enables you to search for and display this data.

Select Administration > Audit to generate an audit report in the Visibility service dashboards user interface.

After executing a search, you can use controls at the top to perform other tasks on the search results page, such as filtering. You can get more information by selecting Help in the Visibility user interface.

Supported browsers and requirementsCentral Governance supports the following web browsers for navigating the user interface and help. Although all of these are supported, tests have indicated the UI performs best in Chrome.

Client OS Browser Browser version

Windows 7 - 32 and 64 bit Internet Explorer 11

Windows 7 - 32 and 64 bit Chrome Latest

Windows 7 - 32 and 64 bit Firefox Latest

Windows 7 - 32 and 64 bit Firefox Extended Support Release (ESR) Latest

Windows 8.1 - 64 bit Internet Explorer 11

Windows 8.1 - 64 bit Chrome Latest

Windows 8.1 - 64 bit Firefox Latest

Windows 8.1 - 64 bit Firefox Extended Support Release (ESR) Latest

Browsers must support the following:

l Browsers must accept cookies from the Central Governance user interface.

l On any supported version of Internet Explorer disable compatibility view if you encounter display issues while using the help.

l Local storage must be activated in all supported browsers. It is active in all browsers by default, but the following is how to verify:

o In Chrome, go to Settings | Show advanced settings | Privacy | Content settings | Cookies. Make sure the following is not selected: Block sites from setting any data.


2 Operations

o In Firefox, enter the address about:config and click I'll be careful, I promise if prompted. Scroll down to dom.storage.enabled and make sure the value is true.

o In Internet Explorer, go to Tools | Internet options | Advanced. Under Settings | Security, make sure the following is selected: Enable DOM storage.

l Central Governance has an HTML5-enabled user interface. The JavaScript option must be activate on your browser:

o In Chrome, go to Settings | Show advanced settings | Privacy | Content settings | JavaScript. Make sure the following is selected: Allow all sites to run JavaScript.

o In Firefox, go to Tools | Options. Make sure the following are selected: Block pop-up windows, Load images automatically, and Enable JavaScript.

o In Internet Explorer, go to Tools | Internet options | Security | Security level for this zone. Under Settings | Scripting, make sure the following is selected: Enable scripting of Java Applets.

The recommended screen resolution is 1200x800. The minimum supported screen resolution is 800x600.

Tips for using the user interfaceStandard website usability guidelines apply to the Central Governance user interface.

l Add bookmarks to the pages you use often. Each page has a unique URL you can use to access it directly.

l Refresh each page using the browser's page refresh or reload option.

l Navigate through the pages using the browser's back and forward buttons.

l Open a new page in a different browser tab. Best practice is opening several browser tabs to access pages quickly.

Some Central Governance context parameters are stored in the browser. If you connect to the UI using the same browser on the same machine, the same context is available. Note that context does not depend on the user connected, but is relative to the URL domain. Central Governance context parameters include:

l The filters applied on each grid

l The grid customization (columns displayed, columns order and size)

If you have problems viewing or navigating the help, accessed via help links throughout the user interface, refresh or reload the page. Or clear your browser's history or cache, restart the browser and try again.


2 Operations

License fileAn XML license file controls the functionality you are entitled to use. For example, it specifies whether you can use an embedded or external database for storing application data.

Before installing or upgrading, make sure you have obtained a license file for Central Governance from Axway. Verify it enables the features you want. The license specifies:

l Hosts where Central Governance can be installed. The license must support multiple hosts if you plan to run Central Governance in a cluster environment of multiple computers.

l The supported operating system.

l The supported embedded or external database.

l An expiration date. If there is not a date, the license is perpetual.

After installing, during the initial configuration of Central Governance, you are prompted to enter the location of the license file. After starting the server the first time, the file is stored in:

<install directory>\runtime\com.axway.nodes.ume_<UUID1>\conf\license\license.xml.

Do not move, rename or delete the file. Any attempt to change the contents makes the product inoperable. The file is hashed and signed to protect it from tampering. You can, however, open the file and review its contents.

If you receive a new license file, you can stop Central Governance and run cgcmd configure to replace the old license file. For example, you may receive a new license to replace one that has expired.

If the license expires while Central Governance is running, it keeps running but once stopped cannot be restarted.

Flow and transfer monitoringMany events related to flow execution are tracked, typed and stored in the database. You can search for and retrieve the data via the Central Governance or Axway Sentinel user interfaces. The Central Governance Visibility service is based on Sentinel.

After retrieving data, you can use toolbar controls to perform other tasks on the displayed data.

Options to retrieve dataIn Central Governance you can select Flows > Flows Report to generate a report of all flows that have executed in the past 7 days. You also can select Administration > Dashboards to open the dashboards page and then select My documents > View all flows to generate the same report.

2 Operations

You can use the Filter document control to find specific data or generate more data.

Another option is to select Flows > Monitoring to open the Visibility UI, which is based on the Sentinel UI. Select View_Flows > View all flows to display fields for filtering data. Only start and end dates are required, though flows can be filtered by start/end date, flow name, tag or status. All other filtering fields are optional. Click Execute to perform a search.

ActionsOnce data are displayed, you can use toolbar icons to perform actions, such as running commands.

For example, select one or more transfer records and click Perform action to display available actions. For SecureTransport you can resubmit a transfer, which reprocesses failed or completed transactions. Depending on the state of the transfer, for Transfer CFT you can:

l Restart the transfer

l Cancel the transfer

l Pause the transfer

For SecureTransport only, if a transfer fails on the SecureTransport you can also:

l Resubmit the transfer

For Transfer CFT only, you can also perform the following actions on a transfer depending on its status:

l Delete a transfer

l End a transfer

l Acknowledge a transfer

l Negatively acknowledge a transfer

Note Sentinel Events > Transfer steps reported must be set to ALL to enable these command options. See Visibility > Events on page 246 for details.

Transfer CFT: Restart the transferThis command reactivates a suspended or held transfer. It corresponds to the Transfer CFT START transfer control command. The Transfer CFT requesting the transfer initiates the restart. Eligible transfer statuses are:

AVAILABLECANCELEDINTERRUPTEDSUSPENDEDPRE_PROC_ABORT

After restarting, transfers in the Transfer CFT H or K phasestep in the catalog change to the D phasestep. These transfers are restarted after scanning the catalog for availability of the required resources.


2 Operations

Transfer CFT: Cancel the transferThis command suspends one or all of the send or receive transfers with selected partners and puts them in Transfer CFT KEEP status. It corresponds to the Transfer CFT KEEP transfer control command. Eligible transfer statuses are:

TO_EXECUTEAVAILABLERECEIVINGSENDINGPRE_PROC

Suspended transfers are set to the Transfer CFT K phasestep. Transfer CFT ensures the integrity of the suspended data. Depending on the protocol, it authorizes restarting the transfer from the last synchronization point set before the pause or from the beginning of the file.

Transfer CFT: Pause the transferThis command interrupts a transfer in process and puts it in Transfer CFT HOLD status. It corresponds to the Transfer CFT HALT transfer control command. Eligible transfer statuses are:

TO_EXECUTERECEIVINGSENDINGPRE_PROC

The halted transfers are set to the Transfer CFT H phasestep in the catalog. They can be reactivated:

l By an operator START command

l On receiving a transfer reactivation request from the partner

Transfer CFT ensures the integrity of the data. Depending on the protocol, it authorizes restarting the transfer from the last synchronization point set before the interruption or from the beginning of the file.

Transfer CFT: End the transferThis command ends a transfer and corresponds to the Transfer CFT END command. Eligible transfer statuses are:

PRE_PROC POST_PROC ACK_EXPECTED SENT RECEIVED ENDED-TO-ACK ACKED (compat mode)


2 Operations

Transfer CFT: Delete the transferThis command deletes a transfer and corresponds to the Transfer CFT DELETE command. All transfer statuses are eligible for this command.

Note The DELETE command is executed when you select Delete the transfer in the Dashboard, but note that the transfer is not necessarily removed from the catalog.

Transfer CFT: Acknowledge the transferThis command sends an acknowledgment for a transfer and corresponds to the Transfer CFT ACK command. Eligible transfer statuses are:

POST_PROC ACK_EXPECTED COMPLETED SENT (compat mode) RECEIVED (compat mode) CONSUMED (compat mode)

Transfer CFT: Negatively acknowledge the transferThis command sends a negative acknowledgment for a transfer and corresponds to the Transfer CFT NACK command. Eligible transfer statuses are:

POST_PROC ACK_EXPECTED COMPLETED SENT (compat mode) RECEIVED (compat mode) CONSUMED (compat mode)

SecureTransport: Resubmit the transferThis command resubmits the file for failed transfers when SecureTransport is the sender, and is available for SecureTransport v5.3.3 and higher.

On SecureTransport, the resubmit functionality tries to get the file from the original location, where it was stored during the transfer. If it cannot find the file there, it searches the archive directory for the file. The file is present in the archive if file archiving is enabled for that flow. The archived file is kept on the SecureTransport for a specified time, configurable on the product. For more information, see PeSIT: Send properties, sender pushes file on page 384.

If the resubmit failed, the Central Governance command output states that it was not successful.

For more information about configuring Central Governance to deploy SecureTransport archive parameters, see Send properties: SecureTransport pushes files to receiver on page 608.

To execute a command on a transfer:


2 Operations

1. Open the Visibility user interface.

2. Select the transfer or transfers. The icon Execute commands is enabled.

3. Click to view the transfer control commands.

4. Select the Resubmit the transfer command. Central Governance triggers the SecureTransport request.

Results

The transfer is cloned, which is reflected in CG as a new audit trace.

Dashboards and reportsDashboards and reports transform file-transfer data into meaningful graphical displays. These are a feature of the Central Governance Visibility service. You can add, edit, view and delete them in the user interface.

Dashboards are containers of reports. There also can be reports that are not within dashboards.

Run dashboards and reports 1. Select Administration > Dashboards to open the dashboards UI.

2. Select My documents on the menu to display a list of available dashboards and reports.

3. Select an entry to run it.

Default dashboards and reportsYou can use the default dashboards and reports as-is or customize them. In the dashboards user interface, select Help > Help to open a help system with information about dashboard configuration.

The role assigned to your user governs the reports you can access and run.

Users assigned to the IT Manager role can run and customize the following:

l IT Manager dashboard, which contains:

o Transfer status by product

o Product statuses

o Transfer status overview

l Audit report

l Transfer error rate history report

Users assigned to the Middleware Manager role can run and customize the following:


2 Operations

l Middleware Manager dashboard, which contains:

o Transfer status by application

o Transfer status by flow

l Protocols usage dashboard, which contains:

o Protocols used

o Protocols used (ratios)

l Transfer trends dashboard, which contains:

o Average transfer rate

o Exchanged data volume

o File transfer count

o Transfers per file size

l Trend summary dashboard, which contains

o Day trend - Bytes (MB)

o Day trend - Files

o Day trend - Transfer rate

o Week trend - Bytes (MB)

o Week trend - Files

o Week trend - transfer rate

o Month trend - Bytes (MB)

o Month trend - Files

o Month trend - Transfer rate

l And the following reports:

o SecureTransport - File processing

o Today's flows analysis

o Transfer error per hour today

o View all flows report

User privileges for dashboards and reportsThe default roles IT Manager and Middleware Manager contain privileges that enable users with these roles to manage dashboards and reports, as outlined in Default dashboards and reports on page 76. Other users who need such permissions must be assigned to roles containing one or both of the following predefined privileges or user-defined privileges based on the same Sentinel Web Dashboard resource as these:

View Web dashboards and reports

This predefined privilege enables viewing dashboards and reports.


2 Operations

Manage Web dashboards, access, reports and database

This predefined privilege enables managing dashboards and reports.

Caution about audit and flow reportsJust as with other default reports, you can change or delete the audit and view all flows reports. However, deleting these reports disables the ability to run them using the toolbar options Flows > Flows Report and Administration> Audit. Best practice is to keep these reports and not delete them.

Customize the Transfer CFT connection This section describes how to modify the Central Governance to Transfer CFT connection retry and delay settings.

You can modify the parameters listed below to customize connection timeout and retries. These parameters are located in the located in the file:

<CG_installdir>\runtime\com.axway.nodes.cftconnector_xxxxxx\uma\conf\cft-

connector.properties

cftconnection.timeout

Values [ 1 | 10 | no maximum ]

The maximum amount of time in seconds that the program waits before setting up a connection to another process. There is no application data exchange at this point, just the connection establishment.

Default value: 10 (seconds)

Note: Avoid setting the cftconnection.timeout to a low value. Doing so may result in timeout errors in CG for slower Transfer CFT machines.

cftconnection.retries

Values [ 0 | no maximum ]

The number of times to retry to establish a connection.

Default value: 0

You must restart Central Governance for modified values to be taken into account.

3 Database administration

The following topics provide information about managing Central Governance databases, internal and external. This is for database administrators or other users responsible for database maintenance and performance, including backing up and restoring data.

Central Governance has two embedded databases:

l Internal storage is a NoSQL MongoDB database for Central Governance configuration data, including policies, flows and partner definitions.

l Application database is a MySQL database for transfer tracking data, user roles and privileges, certificates and dashboards. Central Governance can be configured to use an external database instead for this purpose.

Although you can perform maintenance, do not attempt to install updates for the embedded databases. Database updates are applied when installing Central Governance upgrades, service packs or patches.

Internal storage database maintenanceThe following topics describe maintenance tasks for the embedded MongoDB database. The database contains configuration data for Central Governance. A different database, the application database, stores transfer tracking data, user roles and privileges, certificates and dashboards.

The commands to use are in the in the MongoDB bin directory at:

<install directory>\runtime\com.axway.nodes.mongodb_<UUID1>\mongodb-<data string>\bin

PrerequisitesYou need the user name and password for the MongoDB database to back up and restore data. You can look up the user name by stopping Central Governance and running cgcmd configure to open the Central Governance configuration page. The database user name is in the User field under the Internal Storage section of the page.

Back up MongoDB prior to installing Central Governance 1.1.2 SP2.

There also is a Password field, but the value is hidden. If you have forgotten the password, you can set a new one on the configuration page. See Configuration and startup on page 52 for more information.

Silent mode optionWhen backing up and restoring data, you can enter the password with -p <password> or use -p only for silent mode. In silent mode, you are prompted to enter the password after executing the command, but the value is hidden.

Backing up dataYou can export all data in binary format to a backup file with the mongodump command in the MongoDB bin directory. You can back up data when the database is running or stopped.

The following commands create a backup named dump/ in the current directory. It contains a file in BSON1 format for each exported collection.

When running

mongodump --db umcft -u <user> -p <password>

If you are using a port other than the default (27017), you must additionally provide the port:

mongodump --db umcft -u <user> -p <password> --port <port>

When stopped

mongodump --dbpath {dbpath_value} --db umcft -u <user> -p <password>

The value of dbpath is specified in the database configuration file. The file is named mongo.ini and is at:

<install directory>\runtime\com.axway.nodes.mongodb_<UUID>\mongo

The default value is ./mongo/data.

Once you have created the backup file, copy it to a directory outside of the Central Governance installation directory. This makes sure the file is available when you want to use it to restore data.

Restoring dataYou can restore data in a backup file to a new or existing database with the mongorestore command in the MongoDB bin directory. You can restore data when the database is running or stopped.

When running

mongorestore -u <user> -p <password>

1BSON, short for Bin-ary JSON, is a bin-ary-en-coded seri-al-iz-a-tion of JSON-like doc-u-ments. Like JSON, BSON sup-ports the em-bed-ding of doc-u-ments and ar-rays with-in oth-er doc-u-ments and ar-rays.

If you are using a port other than the default (27017), you must additionally provide the port:

mongorestore -u <user> -p <password> --port <port>

When stopped

mongorestore –dbpath {dbpath_value} --journal -u <user> -p <password>

Before restoring data, you can first purge the current database by running the following command:

mongorestore --drop -u <user> -p <password>

These commands restore the database dump in the dump/ directory. However, you can define the path to the directory where the dump files are located. For example, if the database is running:

mongorestore {dump_path} -u <user> -p <password>

More informationVisit http://www.mongodb.org/ for more information about the MongoDB database.

Embedded application database maintenanceThe following topics describe maintenance tasks for the embedded MySQL application database.

Data directoryData are stored in the following directory:

<install directory>\runtime\com.axway.nodes.mysql_<UUID1>\data

The directory location is not configurable.

When Central Governance is running on Linux, you must execute the following command from the <install directory>\runtime\com.axway.nodes.mysql_<UUID>\mysql\bin directory to connect to the database before running other commands:

mysql -S ../../data/axwayDB.socket -u root -p

Backing up dataYou can export all data to a backup file with the mysqldump command in the MySQL bin directory. The database must be running to back up data.



http://www.mongodb.org/

Run the following command to generate a dumpfile.sql file in the current directory. The file contains all queries for restoring the database.

mysqldump –u {conf.db.root.login} –p{conf.db.root.password} –P {conf.db.port} –-all-databases > dumpfile.sql

Once you have created the backup file, copy it to a directory outside of the Central Governance installation directory. This makes sure the file is available when you want to use it to restore data.

Restoring dataYou can restore data in a backup file to a new or existing database with the mysql command in the MySQL bin directory. The database must be running to restore data.The following command overwrites all existing data.

mysql –u {conf.db.root.login} –p{conf.db.root.password} < dumpfile.sql

Make sure there is not a space between the-p password parameter and the value.

More informationVisit http://www.mysql.com/ for more information about the MySQL database.

Flow monitoring and audit data maintenanceWhether you use the embedded application database or an external database for this purpose, regular purging or archiving or both is recommended for some types of data to avoid disk space issues:

l Data related to audit reports (see Audit reports on page 70).

l Data related to monitoring of flow transfers, which are data stored in the XFBTransfer Tracked Object.

These records are in the database for the Central Governance Visibility service, which is based on Axway Sentinel.

Never purge other data in the application database. This includes other data for the Visibility service and any data in the Central Governance Access and Security service and Dashboards databases. Also, never purge data in the internal MongoDB database.

Best practices:

l Define the rules and interval for purging and archiving data. These decisions are at your discretion, according to your organization's policies and practices. You can review database sizing recommendations in the prerequisites section of the Central Governance Installation Guide.


http://www.mysql.com/

l Define the data to purge or archive or both. This should include only the audit and flow transfer monitoring data.

l Apply a data purge and archive procedure.

The Visibility service has tools for archiving and purging data in the following directory:

<install directory>\runtime\com.axway.nodes.sentinel_<UUID1>\sentinel\tools

The following are examples of archiving the historic and current flow transfer monitoring data in the XFBTransfer Tracked Object:

l Archive of the current data:

trkcmd archive -tabname "TrkTable(XFBTransfer, current)"

l Archive of the historic data:

trkcmd archive -tabname "TrkTable(XFBTransfer)"

The result of these archive commands is two XML files in the following directory:

<install directory>\runtime\com.axway.nodes.sentinel_<UUID>\sentinel\archive

The following are examples of purging the historic and current flow transfer monitoring data in the XFBTransfer Tracked Object:

l Purge of the current data:

trkcmd purge -tabname "TrkTable(XFBTransfer, current)" -delay 0

l Purge of the historic data:

trkcmd purge -tabname "TrkTable(XFBTransfer)" -delay 0

You can also restore some archived data with the following command:

trkcmd restore -tabname "TrkTable(XFBTransfer)" -file my_archived_data.xml

For more details, see the Sentinel user documentation.



http://docs.axway.com/u/documentation/redirect.htm?help=sent

4 Tools

Central Governance has tools for performing routine and advanced tasks.

cgcmd

The cgcmd command starts and stops Central Governance, displays system status and performs basic configuration.

Command line interface

The command line interface (CLI) enables you to perform operations on Central Governance services and products.

APIs

REST APIs (Application Programming Interfaces) provide resources for configuring flows and flow components.

The following topics provide more details.

cgcmd commandThe cgcmd command starts and stops Central Governance, displays system status and performs basic configuration.

The cgcmd command is in the Central Governance install directory. You must run it from that directory. The syntax is cgcmd <parameter>.

ParametersThe following are the cgcmd command parameters.

Note If you want to stop or start an individual product or start a Central Governance service, see Command line interface on page 88.

You can run any parameter, except help, with a --verbose option to display more information when the command executes. For example:

cgcmd status --verbose

4 Tools

configureStarts an internal web server that hosts a web page for configuring Central Governance. Central Governance must be stopped before you can run configure mode.

Once the web server has started, the command lists the URL for opening the web page in a browser. If the computer on which the command was executed has a default browser, the page opens automatically. Otherwise, open the page with the provided URL.

By default the web server runs on port 8082. But you can change the port when invoking the command. For example:

cgcmd configure -p <port>

When the configuration page opens, complete configuration fields as needed. Click Save and start when done. The system starts and the settings are applied.

See Configuration and startup on page 52 for more details.

helpDisplays a list of all parameters and descriptions. It also lists the return codes and descriptions of all parameters. Invoking cgcmd without a parameter also displays the list of parameters.

repairRestores the Default User [email protected] to its initial password, user ID, role and organization. If the Default User has been deleted, it also re-adds the user to its original state. See About the Default User on page 154 for more information about this user.

Central Governance must be running to use this parameter.

restartStops and then starts Central Governance and all of its services.

If you run Central Governance on Windows as a service, start or stop the service, automatically or manually. Do not use cgcmd restart.

startStarts Central Governance and all of its services, which also are called nodes. The initial configuration must be completed before Central Governance can be started.

If you run Central Governance on Windows as a service, start or stop the service, automatically or manually. Do not use cgcmd start.

See Startup behavior on page 86 for more information.

4 Tools

statusDisplays the current started or stopped status of Central Governance. Use the verbose option to also display statuses of all nodes.

stopStops Central Governance and all of its nodes.

If you run Central Governance on Windows as a service, start or stop the service, automatically or manually. Do not use cgcmd stop.

supportPackages Central Governance log files and other files in a compressed file. You can send the file as an email attachment to Axway support when working with them to troubleshoot an issue.

When you run cgcmd support, the file is added to the Central Governance install directory. The file name is in the format cg_support_yyyy-mm-dd_hh-mm-ss. The file type is ZIP on Windows and TGZ on Linux.

Included in the package are a copy of the initial-settings.properties file and copies of the Central Governance logs, config and scripts directories. It also contains log files for nodes and other node files.

If Central Governance is on Linux, make sure that the interface configuration (ifconfig) system administration utility is in the system PATH variable and that the user has permissions to use it. The ifconfig utility must be available to enable the cgcmd support command to collect the maximum amount of data.

versionDisplays the version of Central Governance and of all applied service packs and patches.

Also displayed are versions of all nodes, components and node archive files.

If node versions are not reported, Central Governance is not fully installed or initial configuration has not been completed.

Startup behaviorStarting Central Governance can result in a fully or partially running system, depending on whether the agent and all of the nodes are started successfully.

Central Governance is fully running when the agent and the following nodes, or services, are started:


4 Tools

l Application database

l Access and Security

l Visibility

l Internal storage

l Core services

l Transfer CFT connector

All are core nodes except Transfer CFT connector and Visibility.

If a core node cannot be started, the cgcmd start command is stopped and startup fails.

If the Transfer CFT connector or Visibility or both cannot be started, Central Governance is partially started. When partially started, users can connect to the user interface, but might be unable to use all features.

Troubleshoot start or stop failuresThe following are troubleshooting guidelines when Central Governance fails to start or stop.

l Check the log files in the Central Governance logs directory. You might have to manually stop

the Agent process.

l If you are working with Axway support, you can send them an archive file containing logs and other system files helpful in troubleshooting. Central Governance generates the archive automatically on start and stop failures or you can generate it manually. See support on page 86.

l A timeout is reached when stopping. Wait until Central Governance has stopped completely and check with cgcmd status.

l Central Governance fails to stop. Check with cgcmd status. You might have to manually

stop processes.

l Expected number of nodes is not correct. For example, only three of six nodes were detected. Review the node logs, try to resolve the issue, and start the system again.

l Some node types are missing in the Central Governance installation. Review the agent and cgcmd logs, try to resolve the issue, and start the system again.

l Some node types are in error. Check their log files. Try to stop Central Governance and start it again.

l Some nodes are still starting. Wait until all nodes have started.

l Some nodes have not started. Try to start Central Governance again.

Crashed or StartingInError recoveryIf you run cgcmd status --verbose and one or more nodes have a status of Crashed or StartingInError, run cgcmd restart to stop and then start Central Governance and all of the nodes. Alternatively, you can run cgcmd stop, manually kill any hung processes, then run cgcmd


4 Tools

start.

Command line interfaceThe command line interface (CLI) enables you to perform operations on Central Governance services and products.

PrerequisiteCentral Governance must be running.

UsageThe CLI utility is in the Central Governance cli directory. The tool is named cgcli.bat on Windows or cgcli.sh on Unix and Linux.

You must enter user credentials to run CLI commands or log on to a console mode. Credentials are user ID, organization name and password. However, users only must supply passwords the first time they use CLI. Thereafter, users only need enter user ID and organization name.

For example, from the cli directory, a first-time CLI user executes the following command to list CLI user credential rules and all commands and descriptions:

cgcli -u <user ID> -o <user organization name> -p

The -p parameter initiates a prompt to enter the user password. Passwords are hidden when entered. After typing the password and pressing Enter, all rules and commands and descriptions are listed.

The first time you use CLI, your password is saved. Subsequently, you only need enter your user ID and organization name. You can use the -p parameter, but it is optional unless your password has changed. For example:

cgcli -u <user ID> -o <user organization name>

If a user ID, organization name or password contains spaces, enclose the value in quotes "like this". Quotes also are required for values of any other parameters containing spaces.

New users must log on to the Central Governance user interface and change their initial passwords before using CLI. The tool does not accept the temporary passwords assigned to new users.

There are short and long forms of command parameters. For instance, the user parameter can be used in the following forms:

l Short: -u <user ID>

l Long: --user <user ID>

So in the previous example to list credential rules, commands and descriptions, you can execute the following long forms to generate the same list:

4 Tools

First-time user

cgcli --user <user ID> --organization <user organization name> --password

User with saved password

cgcli --user <user ID> --organization <user organization name>

You invoke CLI with commands. Commands have required, optional or no parameters. The following are examples of short-form syntax:

First-time user

cgcli -u <user ID> -o <user organization name> -p <command>


cgcli -u <user ID> -o <user organization name> <command>

See CLI commands on page 94 for descriptions of the CLI commands and their uses.

CLI displays help whenever there is a syntax error in command-line use. Details of commands are displayed only when user authentication works.

CLI modesThe utility has two modes: normal and console.

Normal modeYou must enter user credentials each time you want to run a command in normal mode. For example:

First-time user

cgcli -u <user ID> -o <user organization name> -p <command>


cgcli -u <user ID> -o <user organization name> <command>

Console modeYou log on with your user credentials to run CLI in console mode. Once logged on, you can run commands without entering credentials each time.

Use the console command to log on. For example:

First-time user

cgcli -u <user ID> -o <user organization name> -p console

4 Tools


cgcli -u <user ID> -o <user organization name> console

Once logged on, user credentials are not required to invoke commands. Just run a command and any parameters. For example, to display the status of a specified Central Governance service:

serviceStatus -n <service name>

Type exit to log off console mode.

Permissions enforcementUsers must have roles with correct privileges to execute CLI commands. Without proper privileges, access-denied error messages are displayed and commands fail to run. The only exception is CLI help is not filtered against privileges and is accessible even to users who do not have roles.

The following table shows the resources and enabled actions that must be in privileges associated with roles for users to run CLI commands successfully. See Roles and privileges on page 149 for more information.

CLI command Resource Action Comment

appExport Application View

appImport Application ViewModifyCreate

Create is required when the command is used without parameters. Modify is required for using the overwrite parameter. The View action is required in both cases.

flowDeploy Flow Deploy

flowExport Flow View

4 Tools


flowImport Flow CreateModify

Create is required when the command is used without parameters. Modify is required for using the overwrite parameter. The View action on the Flow resource also is required in both cases.

A user also must have the Create action on the Application resource to use the import applications parameter.

A user also must have the Create action on the Unmanaged Product resource to use the import unmanaged products parameter.

partnerExport Partner View

partnerImport Partner ViewModifyCreate

Create is required when the command is used without parameters. Modify is required for using the overwrite parameter. The View action is required in both cases.

policyExport Policy View

policyImport Policy Create

productConfigurationDeploy Product Configuration

Deploy

productList Product View

productRestart Product Stop

Start

productStart Product Start

productStop Product Stop

serviceList Service View

serviceLog Service ViewConfigure


4 Tools


serviceStart Service Start

serviceStatus Service View

The following is an example of console output when a user attempts to run the productList command without rights for the Product resource view action.

CLI> productList

CLI> Access denied. Contact your administrator if you require access.

CLI>

Use CLI remotelyYou can use CLI on a computer that is not running Central Governance. This requires copying some Central Governance system files and having the remote computer access them. The remote computer also must set a path to a local instance of Java Runtime Environment (JRE) 1.8.

Central Governance must be running on the host computer for the remote computer to use CLI.

1. Create a directory on the computer running Central Governance. This directory is for putting copies of Central Governance files needed to run CLI. Give the directory a meaningful name. For example, cli_remote.

2. Copy the following files to the new directory:

l The Central Governance cli directory

l The Central Governance data directory.

3. Copy the directory to the remote computer.

4. In the cli directory open the cgcli.properties file for editing. Make sure the port and host properties are for Central Governance on the host computer.

5. In the cli directory open open the profile file for editing. Make sure the JVM_EXECUTABLE

property is set to the JRE on the local machine. For example, on Windows, C:\Program Files\Java\jre8\bin\java.

6. Use CLI in normal or console mode. See CLI modes on page 89.

Typographical conventionsThe following typographical conventions are used in command syntax and examples.


4 Tools

Symbols Description

<text> User-defined value is displayed inside angle brackets.

[parameter] Optional parameters are displayed inside square brackets.

{parameter | parameter}

Required parameters, one of which must be selected, are displayed inside braces and separated by vertical lines.

[parameter | parameter]

Optional parameters, one of which can be selected, are displayed inside square brackets and separated by vertical lines.

- Precedes the short form of the parameter.

-- Precedes the long form of the parameter.

ErrorsThe following table lists general errors that may result from the execution of any command.

Context Error Output

Command contains incorrect parameters. Unrecognized parameter: <parameter>.

Command help is displayed.

Mandatory parameter is missing. Missing parameter(s): <parameter1, parameter2>.


Parameter value is missing. This error occurs only for parameters that require a value. For example, on the serviceStop command, --name requires a value, but -force does not.

Missing parameter value for: <parameter_value>.


The server does not respond Web server is not available.

An unexpected error occurred during command execution. Unexpected error. The text of the actual error is displayed.

4 Tools

CLI commandsThe following are the CLI1 commands and their uses.

consoleStart CLI in console mode. See Console mode on page 89 for details.

appExportExport a list of applications filtered by name or group.

You can use this command to export applications defined in Central Governance for testing and import them in a production Central Governance environment.

When exporting applications, the reference to products (not all the definition or configuration of the product) linked to applications also are exported. If the application is contained in groups, the group definition is exported, too.

appExport [-f <file path> -format <JSON|XML> -g <group> -n <name> -s]

appExport [--file <file path> --formatfile <JSON|XML> --group <group> --

name <name> --silent]

<file path> - The name of the exported file.

<name> – One or more application names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

<group> – One or more application group names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

If you do not use the optional file parameter, applications are exported to the Central Governance cli directory. The files have the prefix export_app.

If you do not use the optional format or formatfile parameter, applications are exported to JSON files. If you use it, you can specify JSON or XML as the file type.

The group and name parameters are optional. All applications are exported if you do not use them.

The optional silent parameter is for overwriting the target file, if any, without confirmation.

appImportImport a list of applications or groups from a file.

See Command usage details on page 102 for more information.

1Command line interface (CLI) is a tool for performing actions on products and services.

4 Tools

appImport { -f <file name> } [ -o ]

appImport { --file <file name> } [ --overwrite ]

The optional overwrite parameter enables overwriting of applications by identifier. Be careful that groups are not overwritten.

<file name> - Path and file name of the application to import.

The command tries to find XML and JSON files to import. If neither format is found, importing is aborted and CLI reports the file has an invalid format.

flowExportExport a list of flows filtered by name.

You can use this command to export flows defined in Central Governance for testing and import them in a production Central Governance environment.

When exporting flows, the definition of applications or groups of applications used in flows also are exported. The products linked to the flow directly or via applications and application groups are exported, too. Definitions of any unmanaged products are exported as well.

flowExport [-ek <key> -f <file path> -format <JSON|XML> -n <flow name> -s ]

flowExport [--encryptionkey <key> --file <file path> --formatfile <JSON|XML> --

name <flow name> --silent]

<key> - The key for encrypting passwords and private certificates and keys. Although optional, Central Governance uses a default value if you do not specify one. The default value is set in the Encryption field on the Central Governance configuration page (see Encryption on page 59). Any value you specify must conform to the Central Governance password policy.


<flow name> - One or more names of flows separated by commas. Use an asterisk (*) as a wildcard to filter the results.

If you do not use the optional file parameter, flows are exported to the Central Governance cli directory. The files have the prefix export_flow.

If you do not use the optional format or formatfile parameter, flows are exported to JSON files. If you use it, you can specify JSON or XML as the file type.

The name parameter is optional. All flows are exported if you do not use them.


See Prerequisites for promoting flows on page 498 for more information.

flowImportImport a list of flows from a file.

4 Tools


flowImport [ -ai | -app | -dk <key> ] { -f <file name> } [ -o | -up ]

flowImport [ --allowincomplete | --importapplications | --decryptionkey <key> ]

{ --file <file name> } [ --overwrite | --importunmanagedproducts ]

The optional allowincomplete parameter enables import of flows where applications or products are missing.

The optional importapplications parameter enables import of applications.

The optional overwrite parameter enables overwriting of flows by name. Existing applications and unmanaged products are not overwritten.

The optional importunmanaged products parameter enables importing of unmanaged products1. If used, definitions of the unmanaged products in the file must also be recorded in Central Governance.

<key> - The key for decrypting passwords and private certificates and keys. Although optional, Central Governance uses a default value if you do not specify one. The default value is set in the Encryption field on the Central Governance configuration page (see Encryption on page 59).

<file name> - Path and file name of the flow to import.


See Prerequisites for promoting flows on page 498 for more information.

flowDeployDeploy flow definitions.

flowDeploy {-n <names> }

flowDeploy {--name <names> }

You must specify the names.

<names> - One or more flow names. Use commas to separate multiple names. Use an asterisk (*) as a wildcard to filter the results.

partnerExportExport a list of partners filtered by name.

You can use this command to export partners defined in Central Governance for testing and import them in a production Central Governance environment.

1Unmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that cannot register in Central Governance or third-party products.

4 Tools

When exporting partners, all related credentials and communication profiles of partners also are exported. Both communication profile types, client and server, are exported if present.

Server communication profiles are editable in partners, and client communication profiles are editable in flow protocols.

If partners contain public PGP keys, the keys also are exported.

partnerExport [-ek <key> -f <file path> -format <JSON|XML> -n <name> -s]

partnerExport [--encryptionkey <key> --file <file path> --formatfile <JSON|XML>

-- name <name> --silent]

<key> - The key for encrypting passwords and private certificates and keys. Although optional, Central Governance uses a default value if you do not specify one. The default value is set in the Encryption field on the Central Governance configuration page (see Encryption on page 59). Any value you specify must conform to the Central Governance password policy.


<name> – One or more partner names separated by commas. Use an asterisk (*) as a wildcard to

filter the results.

If you do not use the optional file parameter, partners are exported to the Central Governance cli directory. The files have the prefix export_partner.

If you do not use the optional format or formatfile parameter, partners are exported to JSON files. If you use it, you can specify JSON or XML as the file type.


partnerImportImport a list of partners from a file, including all credentials of type certificates, SSH keys, PGP keys and logins, and all communication profiles of partners. Both types of communication profile types, client and server, are imported if present.


partnerImport [ -dk <key> ] { -f <file name> } [ -o ]

partnerImport [--decryptionkey <key>] { --file <file name> } [ --overwrite ]

<key> - The key for decrypting passwords and private certificates and keys. Although optional, Central Governance uses a default value if you do not specify one. The default value is set in the Encryption field on the Central Governance configuration page (see Encryption on page 59).

<file name> - Path and file name of the partner to import.


The optional overwrite parameter enables overwriting partners by identifier.

4 Tools

Overwrite a partner used in a flow

You can use the overwrite option even if a partner is used in flows. In this case all related flows are updated, and a message is displayed in the audit for each impacted flow. Changes are applied to the partner, but you must check whether the flow is correct regarding new partner changes before deploying.

Check server communication profiles

If communication profiles are already used by flows, Central Governance checks if the partner from the import file has a server communication profile with the same name but a protocol that is different from the one it would be overwriting. In this case, no portion of this partner is imported. Any other type of update is allowed, including changing the partner name and the server communication profile parameters.

Overwrite to remove

You can remove a server communication profile that is already used by flows by importing with the overwrite option.

policyDeployDeploy policies.

policyDeploy {-n <name>} [-s]

policyDeploy {--name <name>} [--silent]

You must specify the name parameter.

<name> – One or more policy names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

s or silent – Disables confirmation prompts. No value is required.

policyExportExport a list of policies filtered by name. You can export policies defined in Central Governance for testing and import them in a production Central Governance environment.

policyExport [-f <file path> -format <JSON|XML> -n <policy name> -s]

policyExport [--file <file path> --formatfile <JSON|XML> --name <policy name> -

-silent]

<JSON|XML> is the name of the file to export. If not specified, the exported file is saved to the current directory with a name in the format export_policy_<date and time>. The extension is JSON or XML depending on the file format.

<file format> is the format of the file to export. You can specify XML or JSON. If not specified, the default is JSON.

4 Tools

<policy name> is one or more policy names. Use commas to separate multiple names. Use an asterisk (*) as a wildcard to filter the results.


If the file to export already exists, the system prompts for overwrite confirmation.

policyImportImport policies.



policyImport [-o] {-f <file name>}

policyImport [--overwrite] {--file <file name>}

The optional overwrite parameter enables overwriting existing policies.

<file name> is the path and file name of the file to import.

productListList all products registered in Central Governance. The name, status and version of products are listed.

productList [-n <name>] [-g <group>]

productList [--name <name>] [--group <group>]

<name> – One or more product names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

<group> – One or more group names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

productConfigurationDeployDeploy configurations for a registered product.

productConfigurationDeploy {-g <product group> | -n <product name>} [-norestart

-s]

productConfigurationDeploy {--group <product group> | --name <product name>} [-

-noproductrestart --silent]

You must supply the group or name parameter.

4 Tools

<product group> - One or more product groups separated by commas. Use an asterisk (*) as a wildcard to filter the results.

<product name> – One or more product names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

norestart or noproductrestart – The product is not restarted after deployment. You must restart the product later for the changes to become effective.


productStartStart a registered product (for example, Transfer CFT).

productStart {-n <name> | -g <group>}

productStart {--name <name> | --group <group>}

You must supply the name or group parameter.



productStopStop a registered product (for example, Transfer CFT).

productStop {-n <name> | -g <group>} [-s] [-mode]

productStop {--name <name> | --group <group>} [--silent] [-mode [normal | quick

| force]]





mode – Specifies the manner of stopping. To stop normally, do not specify this parameter, since normal is the default behavior.

l quick – Can be used on a "started" or "in error" system.

l force – Can only be used on an "in error" system.

4 Tools

productRestartRestart a registered product (for example, Transfer CFT).

productRestart {-n <name> | -g <group>} [-s]

productRestart {--name <name> | --group <group>} [--silent]





serviceListList all the Central Governance services. The name and status of services are listed.

serviceList

No parameters are required.

serviceStatusDisplay the current status of the specified Central Governance service.

serviceStatus (-n <name>}

serviceStatus {--name <name>}

<name> – A valid service name. Execute the serviceList command to display a list of valid service names.

serviceStartStart the specified Central Governance service.

serviceStart {-n <name>}

serviceStart {--name <name>}

<name> – A valid service name. Execute the serviceList command to display a list of valid service names.

4 Tools

serviceLogList or change the levels of events written to log files for Central Governance services. The log levels, from lowest to highest verbosity, are:

l OFF

l ERROR

l WARNING

l INFO,

l DEBUG

l ALL

Verbosity refers to the quantity of events written to log files. For example, at the DEBUG level, many more events are written to log files than when the level is set to WARNING. However, the severity of events is the opposite. Severity from highest to lowest is: ERROR, WARNING, INFO, DEBUG, ALL, OFF.

Run serviceLog command without parameters to list the current logging level of all services.

The following is the syntax for changing log levels.

serviceLog [-l <log level>] [-n <name>]

serviceLog[--level <log level>] [--name <name>]

Omit the name parameter to change the logging level of all services.

<log level> - Log level to apply.

<name> – One or more service names separated by commas. Use an asterisk (*) as a wildcard to filter the results.

If you change a service log level to a severity higher than Central Governance, the Central Governance log level changes to that level, too. If you change the log level of Central Governance, the log level of all services changes to that level, too. For example:

1. If you set Central Governance to INFO, the log level of all services becomes INFO.

2. If you set the Visibility service to the lower DEBUG level, Central Governance remains at the higher INFO level.

3. If you set the application database service to the higher WARNING level, the Central Governance level changes from INFO to WARNING.

Command usage detailsThis topic provides details about using some of the more complex CLI1 commands.

4 Tools

The usage examples in this topic are independent of each other, except when a linkage between examples is noted.

appImportYou can use this command to import to Central Governance a list of applications in a file. The file can be exported by another instance of Central Governance or generated with an external tool.

If products linked to applications are not registered in Central Governance, the import of applications succeeds, but the command output reports the products were not found.

If an application has no products when imported, Central Governance check whether there are other products on the same host that are registered in Central Governance. If products are found, they are linked to the imported application.

If an application belongs to a group that is not defined in Central Governance, the group also is imported.

The option to overwrite is not applied to applications that are used in flows in Central Governance.

Usage exampleThe file impApps.json contains definitions of the following applications.

l The application Product Catalog Application is linked to the Transfer CFT CFT_PCA on host host.product.catalog.application.

l The application Store_001 is linked to the Transfer CFT CFT_Store_001 on host host.store.001.

l The application Store_002 is linked to the Transfer CFT CFT_Store_002a on host host.store.002.

The following Transfer CFTs are registered in Central Governance:

l CFT_PCA and CFT_Store_001

l CFT_Store_002b on host.store.002

User executes the command:

appImport --file c:/imports/impApp.json

The results of the import are:

l The three applications are imported: Product Catalog Application, Store_001 and Store_002.

l The Transfer CFT CFT_Store_002a was not found, but Transfer CFT CFT_Store_002b was found on the same host, host.store.002. CFT_Store_002b is linked to the application Store_002

l In the command output , a message reports that CFT_Store_002a was not found and that CFT_Store_002b was linked to the application.


4 Tools

flowImportYou can use this command to import to Central Governance a list of flows in a file. The file can be exported by another instance of Central Governance or generated with an external tool.

You also can import the applications defined in the file.

If the participants used in flows are not found in Central Governance or cannot be imported from the file, the flow is not imported unless the allowincomplete parameter is used.

Usage examplesThe file impFlows.json contains a flow with name PL001 that has:

l As source the application, Product Catalog Application linked to Transfer CFT CFT_PCA.

l As target the application, Store_001 linked to Transfer CFT CFT_Store_001 and the application Store_002 linked to Transfer CFT CFT_Store_002.

The following Transfer CFTs are registered in Central Governance:

l CFT_PCA

l CFT_Store_001

In example 1, two optional parameters are not used in the executed command: importapplications and allowincomplete. Examples 2-4 show what happens when the parameters are used.

Example 1


flowImport --file c:/imports/impFlows.json


l The three applications are not imported.

l The flow PL001 is not imported. In the command output there is a message that applications Product Catalog Application, Store_001 and Store_002 cannot be added to the flow because they are not found in Central Governance.

Example 2. importapplications


flowImport --importapplications --file c:/imports/impFlows.json



4 Tools

l The three applications are imported. In the command output for the application Store_002 there is a message that CFT_Store_002 was not found.

l The flow PL001 is not imported. In the command output there is a message that application Store_002 cannot be added to the flow because the CFT_Store_002 was not found.

Example 3. allowincomplete


flowImport --allowincomplete --file c:/imports/impFlows.json


l The three applications are not imported. In the command output for the application Store_002 there is a message that CFT_Store_002 was not found.

l The flow PL001 is imported with status Saved and:

o Source is empty

o Target is empty

l In the command output there is a message that applications Product Catalog Application, Store_001 and Store_002 cannot be added to the flow because they are not found in Central Governance.

Example 4. allowincomplete and importapplications


flowImport --allowincomplete --importapplications --file c:/imports/

impFlows.json


l The three applications are imported. In the command output for the application Store_002 there is a message that CFT_Store_002 was not found.

l The flow PL001 is imported with status Saved and with:

o Source, the application Product Catalog Application is linked to the Transfer CFT CFT_PCA

o Target, the application Store_001 is linked to Transfer CFT CFT_Store_001 and the application Store_002 is not linked to any products

Example 5. overwrite

After running and saving Example 4, there is a new version of the export file from another instance of Central Governance. The flow PL001 in the file is changed with target linked to only application Store_001.



4 Tools

flowImport --overwrite --file c:/imports/ impFlows.json


l The three applications are not imported.

l The flow PL001 is imported and overwrites the existing flow PL001 flow with the status Saved not deployed and with:

o Source, the application Product Catalog Application is linked to Transfer CFT CFT_PCA

o Target, the application Store_001 is linked to Transfer CFT CFT_Store_001

Only the flow is overwritten in all cases. No applications are overwritten, even if you use the importapplications option in combination with overwrite mode.

partnerImportYou can use this command to import to Central Governance a list of partners in a file. The file can be exported by another instance of Central Governance or generated with an external tool.

Usage examplesThe following examples illustrate using the command.

Example 1

The file impPartners.json contains definitions of the following partners.

l The partner BreadSupplier with a server communication profile HTTP

l The partner WineSupplier with a server communication profile SFTP


partnerImport --file c:/imports/impPartners.json


l The two partners are imported and created: BreadSupplier and WineSupplier.

l Each partner has the correct server communication profiles imported, without SSL/TLS.

Example 2

The file impPartners-v2.json has a new version of partner WineSupplier, which now can also communicate with FTP over SSL/TLS.


partnerImport --file c:/imports/impPartners-v2.json -o



4 Tools

l Partner WineSupplier is updated.

l A new server communication profile FTP in SSL/TLS mode with its credential of type certificate is added to WineSupplier.

l The existing communication profile with SFTP is still there.

Example 3

The file impPartners-v3.json has a new version of partner WineSupplier, which now can communicate only with FTP over SSL/TLS.

This partner is already used by the flow with SFTP in Central Governance.


partnerImport --file c:/imports/impPartners-v3.json -o

The result of the import is the update of partner WineSupplier is not imported because the SFTP server communication is already used by a flow and cannot be removed.

policyImportYou can use this command to import a list of policies from a file. Reasons for importing policies are:

l Put policies in production after testing them in a testing or staging environment.

l Import policies already assigned to Transfer CFTs to overwrite and update their configurations.

Policies are determined to be unique by name. Transfer CFT assignments are retained, but status is affected depending on whether changes are detected:

l No changes detected. The original policy parameters have identical values as the imported policy, even if pin or lock replacements are detected. Policy status, parameters status and deploy status are not affected.

l Changes detected. Policy status becomes Saved, not deployed. The possible changes are: parameters that were originally disabled are now pinned or locked, values are updated, and parameters that were pinned or locked originally are now disabled.

Policies with incorrect values for at least one parameter are not imported.

Usage examplesThe file impPolicy.json contains four policies with the following conditions in relation to the import target environment:

l The policy POLICY1 is new.

l The policy POLICY2 already exists and has no Transfer CFTs assigned.

l The policy POLICY3 already exists, has at least one Transfer CFT assigned, and is deployed.

l The policy POLICY4 has at least one invalid parameter.


4 Tools

Example 1


policyImport --file c:/imports/impPolicy.json


l POLICY1 is imported and has the Saved status.

l The existing policies POLICY2 and POLICY3 are not imported. In the command output a message says each policy exists.

l POLICY4 is not imported. In the command output a message specifies the invalid parameters.

Example 2


policyImport –-overwrite --file c:/imports/impPolicy.json


l POLICY1 is imported and has the Saved status.

l The existing policies POLICY2 and POLICY3 are updated successfully. POLICY2 status is Saved and POLICY3 status changes to Saved, not deployed if changes are detected.

l POLICY4 is not imported. In the command output a message specifies the invalid parameters.


4 Tools

Using APIs with Central GovernanceThis section describes how to use a public REST API to automate access to a Central Governance resource. Resources are applications, application groups, products, unmanaged products, partners and flows. A sub-resource refers to, for example, a partner's client communication profile.

The embedded Central Governance API documentation is implemented using Swagger and can be accessed at the following location: https://<CG_host>:<CG_port>//Axway/CentralGovernance/default/CentralGovernance/api/v2/doc

Business use case A user, such as the digital merchandising manager in a retail company, wants to define a flow that on a daily basis updates the product list of the company's stores at many locations. Using Central Governance, the manager sets the source to the product catalog application (PCA), and the target is the stores' applications. The manager deploys the flow.

A month from now, the manager needs to add a new store; the flow has to be updated with this new application. She can define the new application and add it to the flow via an API.

Managing flows with APIsYou can use REST APIs to:

l Create, read, update, delete, list (CRUDL) operations for:

o A2A flow components such as applications, application groups, products, unmanaged products

o Partners and their sub-resources, such as client and server communication profiles

l CRUDL and deploy A2A flows

l Link existing objects, such as applications to application groups and products to applications

PrivilegesThe operations on a resource or a sub-resource can only be performed if the user has privileges on that resource. See User management > Roles and privileges on page 149 for more information.

Return codesReturn status codes include:

l Success or information codes: 200, 201, 202

l Client-error codes: 400, 403, 404, 409, 412

l Critical error code: 500


http://swagger.io/

4 Tools

Related topics

API examples on page 113

Introduction

About the Swagger documentationCentral Governance provides a set of Swagger REST APIs that you can use to perform necessary Central Governance tasks. Each available API command provides a command description that includes viable parameters. The documentation provides an example for commands that require a body, as well as a description of possible error codes.

Central Governance 1.1.1 and higher is based on Swagger v2.0. For more information, refer to swagger.io.

AudienceYou require a working knowledge of Central Governance and an understanding of basic REST API concepts to implement CG APIs. Refer to the Central Governance documentation for product details.

Get startedLog on Central Governance using the same browser that you are going to use for the API operations. You must be an authorized Central Governance user, and have the correct privileges (such as Partner manager) on the API resources to continue. See Add a user on page 145 for more information.

OperationsThis section describes the REST API operations that you can use to perform Central Governance tasks, including working with resources.

Set HEADERS

l Accept=application/json

l Content-type=application/json

GET retrieves data for a resource or a set of resources

l A resource can be identified by a business id or by a name: /api/v2/resource/businessId or /api/v2/resource?name=value

l Several resources are retrieved when filtering by name or tags: /api/v2/resource?name=%value% or /api/v2/resource?tags=%value%

l All resources are retrieved when no option is used: /api/v2/resource


http://swagger.io/

4 Tools

l If several resources are retrieved, you can opt to retrieve just the business id and the name using the _brief option: /api/v2/resource?_brief=true

POST creates a new resource

l To obtain the syntax for POST, do a GET and remove the business id

l The POST must contain a body with the mandatory fields from the UI.

o Non-mandatory fields take the UI default values if not completed. For example for creating an application group:

/api/v2/applicationgroups

{"name": "group1"}

l When creating a new flow, we recommend that you use all mandatory and non-mandatory fields returned by GET

HEAD checks if the resource, identified by business id, exists: /api/v2/resource/businessId

PUT updates a resource identified by business id

l The body is required and the syntax is obtained by doing a GET on the resource that will be updated

l The update completely overwrites the resource:

o For example, if a partner's server communication profile is not included in the PUT body, and it exists on the partner, as the result of PUT the server communication profile is deleted

DELETE removes a resource or a set of resources

l A resource can be identified by business id or by name: /api/v2/resource/businessId or /api/v2/resource?name=value

l Several resources are retrieved when filtering by name or tags: /api/v2/resource?name=%value%

l All resources are retrieved and removed if no option is used: /api/v2/resource

l Deletes several resources identified by businessId: /api/v2/resource?businessId=id1&?businessId=id2

Impact on flowsIf the delete or the update operations have an impact on flows, the same checks are performed as when you are working in the UI.

l If either the _forced option is not used or _forced=false, then the resource is not updated or removed, and there is an error stating the impact.

l If _forced=true, the resource is updated or removed, and the impact on flows is the same as if in the UI you clicked the OK button in the flow impact warning. /api/v2/resource?name=value&_forced=true

Related topics


4 Tools

API examples


4 Tools

API examplesThis page provides information about APIs with Central Governance, and examples of how you can use APIs to simplify business needs.

l About API client batch scripts on page 113

l Use the Try it out feature on page 114

l Examples of useful operations on page 114

l Partner related examples on page 117

l Create and deploy flow example on page 115

About API client batch scriptsYou can use the client URL (curl) to run API commands. For more information about curl, please visit https://curl.haxx.se/.

In order to log on, you must execute the following Access and security SSO request to generate the SSO token for further API calls:

l Request to generate the login token using curl:

curl -k -v --data

"<PassPortRequest id='0' sentAt='<currentDate>'>

<ssoLoginRequest>

<domain>CG</domain>

<username><![CDATA[<login>:<organization>]]></username>

<password><![CDATA[<password>]]></password>

</ssoLoginRequest>"

</PassPortRequest>

--header "Content-Type: text/xml" --dump-header ssoLoginToken.txt https://<CGHost>:<CGPort>/Axway/authentication

l where,

o <currentDate> is formatted as YYYY-MM-DDThh:mm:ssTZD. Example: 2016-05-09T15:30:10-00:00

o <login> is the Central Governance user for API calls

o <organization> is the Central Governance organization to which the user belongs to

o <password> is the clear text user password

o <CGHost> and <CGPort> represent the address on which Central Governance is reachable in the browser (default port is 6900)


https://curl.haxx.se/

4 Tools

l Request to get all flows using curl:

o curl -X GET -b ssoLoginToken.txt -k -v

https://<CGHost>:<CGPort>/Axway/CentralGovernance/default/CentralG

overnance/api/v2/flows

Use the Try it out featureThe Try it out feature helps you to execute API commands from within the Swagger documentation. To use, select a command from within a resource, select the options, such as _brief=true, and then scroll to the bottom of the command. You can click the Try it out button to execute the command.

Examples of useful operationsUse the following examples as a basis to test the various operations. From the listed resource, copy the text from the examples below and execute. Check the results in the Response Body, Response Code, and Response Headers.

Create an application called "Product catalog"POST /api/v2/applications

{

"name": "Product catalog",

"host": "pca.axway.int"

}

Get applications whose names contain the word "catalog"GET /api/v2/applications?name=%catalog%

Where the Product catalog application has the businessId = 98b1763e-24a1-4428-b151-c2dff6f9414b

Get Transfer CFT products that are registered in Central GovernanceGET /api/v2/products?type=”Transfer%20CFT”

l Product CFT1 has the businessId = 2f4631c2-d396-42c0-bcf2-e6ceeed63ab9

l Product CFT2 has the businessId = e70e271d-b815-4a5f-b822-6dbcd1d6e202

4 Tools

Link the product "CFT1" to the "Product catalog" application GET /api/v2/applications/98b1763e-24a1-4428-b151-c2dff6f9414b/products/2f4631c2-d396-42c0-bcf2-e6ceeed63ab9

No additional definition is required.

Create an application called "Store2" in the "Stores" group POST /api/v2/applications

{

“name”: “Store2”,

“host”: “store2host”,

“groups”:[ {“name”: “Stores”} ],

“products”:[ {"businessId": "e70e271d-b815-4a5f-b822-6dbcd1d6e202",

“name”: “CFT2”,

“type”: “Transfer CFT”} ]

}

Get the "Stores" businessIdGET /api/v2/applicationgroups?name=Stores

The application group Stores has the businessId = 7c4a1ee3-5608-421a-9b8f-d9ce78fcf98c

Create and deploy flow exampleThis example demonstrates how to create and deploy a flow with the Product catalog as the source, and the group Stores as the target.

Create a flow with no source and no targetPOST /flows

{ "name": "Product list" }

Get the "Product list" flow businessIdGET /api/v2/flows?name=Product%20list

The flow "Product list" has the businessId = 2aa63bb9-9349-4f88-876d-3f7317871c53


4 Tools

Add a source application with default source propertiesPUT /flows/2aa63bb9-9349-4f88-876d-3f7317871c53a/sources

{

"type": "APPLICATION",

"parts": [

{

"part": {

"businessId": "98b1763e-24a1-4428-b151-c2dff6f9414b",

"name": "Product catalog"

}

}

]

}

Add a target application group with default target propertiesPUT /flows/2aa63bb9-9349-4f88-876d-3f7317871c53a/targets

{

"type": "GROUP",

"parts": [

{

"part": {

"businessId": "7c4a1ee3-5608-421a-9b8f-d9ce78fcf98c",

"name": "Stores"

}

}

]

}

Link the “CFT1” product to the “Product catalog” source applicationPOST /flows/2aa63bb9-9349-4f88-876d-3f7317871c53a/sources/98b1763e-24a1-4428-b151-c2dff6f9414b/products/2f4631c2-d396-42c0-bcf2-e6ceeed63ab9


4 Tools

Set the flow protocol between source and targetPUT /flows/2aa63bb9-9349-4f88-876d-3f7317871c53a/protocol/1

{

"protocol": "PESIT",

"direction": "SENDER_PUSH_FILE",

"properties": {

"securityProfile": "NONE",

"networkProtocol": "TCP",

"defaultIdentifier": "idfProductCatalog"

}

}

Deploy the flowPOST /api/v2/flows/deploybox

[ “2aa63bb9-9349-4f88-876d-3f7317871c53” ]

Get the deployment status for each Transfer CFT in a flowGET /flows/2aa63bb9-9349-4f88-876d-3f7317871c53a/products

Partner related examples

Create a partner with an FTP server communication profilePOST /api/v2/partners

{

"name": "Partner1",

"communicationProfiles":[

{

"name": "FTP1_SCP",

"type": "SERVER",

"protocol": "FTP",

"enabled": true,


4 Tools

"enableSSL": true,

"fipsEnabled": false,

"certificateContent": "MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqhkiG9w0BBwEAAKCCAiIwggIeMIIBh6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxCzAJBgNVBAYTAmZyMQwwCgYDVQQDEwNjZXIwHhcNMTQwMjIwMTMyMDAwWhcNMjQwMjIwMTMyMDAwWjAbMQswCQYDVQQGEwJmcjEMMAoGA1UEAxMDY2VyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE49DulqZr4bz3O+EED1Db4rlQqd8x5hIxIN3q9FkuOWwBqbU30f53Uqljpm21rjzdms5pSIK8zgTqMzjo65TtfG0V50HVQhzD9lxIWLwWoUfZRW89RpwrsOyF+B0DoCpy9ysQjYaamYQOSjWYTm4CqwNpD6Pk+hkyU34r88UKwwIDAQABo3IwcDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTXSlr3YckpIqvg1yhQFVGzee1KoDALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgAHMB4GCWCGSAGG+EIBDQQRFg94Y2EgY2VydGlmaWNhdGUwDQYJKoZIhvcNAQEFBQADgYEAdPn1OSO5edBpMNP0BS8lmW2dEIQZPUlZK+ujuPobNwLy3ZATFfbM7c0tl6LXhRJCXY3Ctd4/8dNPcfSymqKyaTCxZMliCEVnNwtL5tSwiteFW7VdK4Kmf5NwC5O+pctUv9VvjKLj4mE6owhW4hsn7Cp7rbb3gyDuD93zkvhqOPAxAAAAAAAAAA==",

"certificateAlias": "certificate1.crt",

"securityModes":["EXPLICIT"],

"connectionModes":["PASSIVE"],

"hosts":["Partner1Host"],

"port": 21,

"clientAuthenticationRequired": "Yes",

"portRange":{"from": 1024, "to": 65535}

}

]

}

Update a partner PUT /api/v2/partners/54a79152-10ff-4dcc-9fa2-9a1512d84797

{

"name": "part2",

"contact":{},

"communicationProfiles":[

{

"businessId": "54a79152-10ff-4dcc-9fa2-9a1512d84797",

"name": "PeSIT1_SCP",

"type": "SERVER",


4 Tools


"enabled": true,

"enableSSL": false,



"pesitLogin": "PART1",

"hosts":["Partner1Host"],

"port": 17026,

"clientAuthenticationRequired": "Yes"

},

{

"businessId": "afa07113-1468-4052-8607-37d7ecbd5000",

"name": "PeSIT2_CCP",

"type": "CLIENT",


"enabled": true,

"enableSSL": false,



"serverCertificateVerified": false

}

]

}

Related topics

Using APIs with Central Governance on page 109

API Manager and Central Governance on page 119

API Manager and Central GovernanceThis documentation describes the interoperability between API Manager and Central Governance.


4 Tools

API Manager is a product that runs on API Gateway, providing underlying gateway capabilities. API Gateway is available as a software installation, a physical or virtual appliance, or as a managed service on Axway Cloud.

For specific information about the installation and general use of either API Manager or Central Governance, refer to the respective documentation.

Validated versionsInteroperability has been tested and validated for the following version pairs:

l Central Governance 1.1.2 and API Manager 7.5.1 and higher.

Why use the products togetherAxway API Gateway provides a mechanism for controlling access to the Central Governance APIs. This enables you to perform Central Governance operations without having to connect to the Central Governance UI, while having a comprehensive documentation on how to use the APIs. This API resource is provided in a Swagger format.

PrerequisitesThe prerequisites are as follows:

l Installed Central Governance and an existing user with appropriate rights.

l Installed API Gateway with API Manager and Policy Configuration Studio.

l Sufficient API Manager log-in credentials.

l Credentials for connecting to the PassPort embedded in Central Governance.

Axway products and all product documentation are available at support.axway.com.



4 Tools

LimitationsUsers that are created in Central Governance cannot execute APIs unless API Gateway is configured to accept them in the form of a policy. This means that each user in Central Governance that wants to execute APIs from API Gateway must have a policy configured manually in the Policy Configuration Studio, which is part of the API Gateway platform.

A separate cookie is generated for each API command. An API command execution takes around 400 milliseconds.

Implementation overviewTo enable interoperability, complete the steps in the following sections:

1. Setup the environment as described in Prerequisites on page 120.

2. Start API Gateway and API Manager and create a group.

3. Log on Central Governance and save the API Swagger JSON file.

4. Log on Central Governance's embedded PassPort, and save the CA certificate.

5. Create a policy to authenticate a selected Central Governance user.

6. Configure the API Manager.

Installed API productsFor details on installing and configuring these products, refer to:

l API Gateway Administrator Guide

l API Manager User Guide

l API Gateway Installation Guide

l API Gateway Appliances Guide

Start API Gateway 1. Start the Cassandra database: /opt/cassandra/bin/cassandra

2. If this is a new API Gateway installation, create an instance as follows:

Access the managedomain console: /opt/gateway/posix/bin/managedomain> initialize> quit

3. Start the API Gateway node manager: /opt/gateway/posix/bin/nodemanager

4. Log on the API Gateway UI: https://<API_Gateway_host>:8090

4 Tools

5. Create a group, for example group1.

a. Create a gateway in this group.

b. Start the new gateway.

Start API Manager 1. Set up the API Manager using the new group, for example group1, and the gateway created in

the previous step.

/opt/gateway/posix/bin/setup-apimanager --name <GTW_name> --group

<group_name> --portalport 8075 --trafficport 8065

2. Enter the API Gateway user and password.

3. Check that API manager started correctly:

l Access: https://<API_Gateway_host>:8075

l You can use the API manager credentials, or the default user apiadmin.

Access the Central Governance JSON fileFrom Central Governance perform the following steps.

1. Log on Central Governance.

2. Click the Help Center, and select Rest APIs Documentation.

3. In the URL, replace index.html with service.json. For example:

https://<CG_IP>:6900/Axway/CentralGovernance/default/CentralGovernance/resour

ces/cg/engine/external/documentation/restdocs/service.json

4. Save service.json.

5. In Central Governance credentials are managed by the PassPort component. You require the CA certificate to configure the API Manager access to Central Governance without logging in with a user and password.

a. Log on to PassPort http://<CG-IP>:6090

b. Select Security -> Entities.

c. Open the SSL entity and export the CA certificate.

Configure a policy to authenticate a userThis step creates a policy in the Policy Configuration Studio that uses a specific Central Governance user to generate a cookie. A cookie is generated each time an API command is executed from API Manager, and serves as a means of authentication with Central Governance.

4 Tools

Each user in Central Governance has privileges for specific operations, such as editing a flow. The API commands are successful on a resource only if the user executing the API has rights on that specific resource.

Create a project an API Gateway instance In Policy Configuration Studio create a new project from an API Gateway instance:

1. Enter a Name.

2. Optionally enter a password.

3. Session = Admin Node Manager – localhost ; Username=admin ; Password=<API_Gateway_admin_password>

4. Select:

l Group <group_name>

l Select the Gateway <GTW_name>

l Optionally enter a password

Create a policy that generates a cookieA policy is a script composed graphically in a logical diagram with building blocks. If the result of the operation in the block is successful, the script will continue on the so called success path. If It is not successful it will continue on the fail path, if that is defined.

The following example shows how to create a policy where only the success path is defined.

Go to Policies and create a new policy called <CG_policy_name>.

1. Create the starting block Configure “Scripting Language” as shown below. Provide the Central Governance user, organization, and password credentials.

If you require support for additional users, each with its own privileges, after creating the first policy you can copy and paste the first policy, edit the credentials in the second policy, and retain the other building blocks (unchanged).

4 Tools

2. Add a "Set Message" block as shown below.


4 Tools

3. Create a "Connect to URL" block and set the URL to the Central Governance. Set the method as POST.

4. Add a "Trace Filter" block.


4 Tools

5. Add a "Get Cookie" block, and select Remove all Cookie Headers from message after retrieval and Fail if cookie not found in message.


4 Tools

6. Create an "Add HTTP Header" and:

a. Set the HTTP Header Name to Cookie.

b. Set the HTTP Header Value to ppSession=$(cookie.ppSession.value).

7. Add an "Add HTTP Header{1}" block.


4 Tools

8. Add an "Add HTTP Header{2}" block.

9. Add a "Set Message{1}" block.


4 Tools

10. Select Environment Configuration > Certificate and keys. Select the Certificates tab.

11. Click Import to import CA certificate, and set the Alias = Subject.

12. Select Environment Configuration > Listeners > API Gateway. Right-click the Default Services node > Paths.

l Select Add Relative Path.

l Set When a request arrives that matches the path to /CG (the path to the Central Governance policy).

l In Path Specific Policy, select the policy created for authenticating.

13. Select Environment Configuration > Server Settings. Expand API Manager,select Request Policies, and chose the Central Governance policy to use for authenticating.

14. Press F6 to deploy the changes.

Log on API Manager 1. Enter the API Manager URL in your browser: https://<API_gateway_host>:8075

2. Enter the login details. The default user is apiadmin.

4 Tools

Configure API Manager

Import the back-end API in API ManagerPerform the following steps in API Manager:

1. Select API Registration > Backend API.

2. Click New API, and select Import Swagger API.

3. Select the Swagger json file you saved from Central Governance.

4. Click Import.

5. When the import completes, click OK.

Configure the front-end API in API ManagerPerform the following steps in API Manager.

Create a front-end instance

1. Select API Registration > Backend API.

2. Click New API, and select New API from backend API.

3. Select the existing back-end API, and confirm.

Configure the front-end instance to work with the policy

1. For the Trusted Certificates, import the CA certificate saved from Central Governance:

l Inbound=YES

l Outbound=YES

2. For the CORS Profiles, create a new Cors profile with origins=*,

Outbound

1. For the back-end service URL, replace the CgHost:CgPort with the host and port of the Central Governance installation on which API manager connects to perform the API calls.

Note The CG host should be the FQDN so that it matches the CN in the CA

2. Select Advanced.

l Request Policy = <CG_policy_name>

l Response policy = no value

l Outbound authentication profile = No authentication

Inbound

l Inbound security = Pass Through

l Resource path = https://localhost:8065/Axway/CentralGovernance/default/CentralGovernanc

4 Tools

e/

l Save the front-end instance

Create organization, user, and application in API ManagerTo create a user in API Manager, which can also access the API Portal, you must first define an organization and link it to the Central Governance json.

1. In Client Registry > Organizations > create a new organization:

Organization name =<org_name>

API Access > select CG json

2. In Client Registry > Application Developers > create a new user:

Login name = <user_login_name>

Name > <user_name>

Organization = <org_name>

Role = User

Password > Change Password

3. In Client Registry > Applications > create a new application:

Application name=<app_name>

Organization=<org_name>

API Access > select CG json

Check the front-end API settings by executing an API command 1. From the API Catalog, open the Central Governance json and check: GET api_v2_

applications_list Use the Try it out option.

2. To check if the GET was successful, enter the API Gateway URL: https://<API_gateway_host>:8090

> Traffic > Http

5 Certificates

Central Governance comes with default certificates for securing browser connections and communications with registered products. Best practice is to replace the default certificates with your own. The security service of the Central Governance Access and Security node supports CA1 services for generating custom certificates. The following topics describe the security service, CA services and methods for replacing and updating certificates.

Security serviceThe Security service of the Central Governance Access and Security node manages an internal PKI2 where SSL3 certificates are stored.

Access and Security:

l Stores the SSL certificates used between the Central Governance nodes and the user interface.

l Manages certificate authorities for certificate signing request (CSR) validation and signing as part of the product registration process.

l Performs chain building and validation for each certificate in use.

l Notifies of certificate expiration in advance so certificates can be replaced before functionality is affected.

The following describes options on menus used for security tasks in the Access and Security user interface. The menus are Security and Administration. Your user must be assigned to a specific role to perform security tasks in the UI (see Roles for managing certificates on page 135).

Security menuThe Security menu has options for all managed PKI objects.

Entities option l Lists and manages all entities, which are password-protected containers of private keys.

l The entity trust level applies to all active certificates it contains;

1A certificate authority (CA) is a trusted third party that issues digital certificates for use by other parties.2Public key infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.3Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information.


5 Certificates

Certificates option l Lists and partially manages certificates.

l Active certificates are ready for use. Non-active certificates are viewed as drafts and cannot be selected.

l A certificate is considered trusted (root of a certificate chain) if it is marked as trusted or the entity is trusted.

l Versioning is supported for automatic replacement when the principal certificate expires. Under the same alias, multiple versions can coexist.

CA Services option l Lists and manages certificate authorities, which are responsible for issuing certificates.

Certificate Signing Requests (CSR) option l Lists CSRs that can be imported or generated. CA services validate and sign CSRs.

l A certificate obtained from a CSR is meant to belong to an entity or to another CA service.

Administration menuServer Security Settings is the only applicable security option on the Administration menu. It is used for listing and delegating SSL certificates for various purposes.

If CAs change after Transfer CFT registrationAfter registering Transfer CFTs in Central Governance, changing any of the Central Governance certificate authorities requires resubmitting certificate registration:

1. Transfer CFT Copilot requests a new SSL certificate signed by the new CA1.

2. Central Governance sends the requested certificate to Copilot.

Also see CA services for more information.

Governance CAChanging the governance CA affects registered Transfer CFTs. You must import the new CA in Transfer CFT and schedule the certificate registration.



5 Certificates


Transfer CFT 3.1.2For Transfer CFT 3.1.2, stop Copilot and Transfer CFT and do the following:

Replace the PassPort CA by running the following Transfer CFT command:

PKIUTIL PKICER ID = 'PassPortCA', ROOTCID = 'PassPortCA', ITYPE = 'ROOT', INAME = '<GovernanceCACertificateFile>’, IFORM = 'DER', MODE = 'REPLACE’

Then trigger the certificate registration by resetting the cg.registration_id to -1 with the following command:

CFTUTIL UCONFSET ID=cg.registration_id, VALUE=-1

Restart Copilot.

Transfer CFT 3.1.3 and higherFor Transfer CFT 3.1.3 and higher, import the new CA by doing one of the following:

l Configure the CA by setting the CA Certificate by using the installer for Transfer CFT in configure mode. You must stop Copilot and Transfer CFT before starting the installer in configure mode. You can run the configure command in the Transfer CFT installation directory to start the installer in configure mode.

or

l If you do not want to stop Transfer CFT, use the following commands:

o PKIUTIL PKICER ID = '<CG CA new alias>', ROOTCID = '<CG CA

new alias>', ITYPE = 'ROOT', INAME =

'<GovernanceCACertificateFile>’, IFORM = 'DER', MODE =

'CREATE'

o CFTUTIL UCONFSET ID=cg.ca_cert_id, VALUE='<CG CA

alias>,<CG CA new alias>'

Then set the parameter cg.certificate.governance.renewal_datetime (format: YYYYMMDDHHMMSS + GMT) to schedule the request at first heartbeat after the specified date and time.

The heartbeat interval is specified in seconds in the cg.periodicity parameter (default value 600). For example, schedule the certificate request to start December 23, 2014, at 14:30:00 + GMT by running the following command:

CFTUTIL UCONFSET ID=cg.certificate.governance.renewal_datetime, VALUE=20141223143000

Transfer CFT becomes unreachable until the new certificate is received.

5 Certificates

Business CAIf the business CA is changed, a new business SSL certificate can be requested. The new certificate is signed by the new CA and used in secured flows.

Schedule a new certificate request starting with the time specified in the Transfer CFT parameter cg.certificate.business.renewal_datetime (format: YYYYMMDDHHMMSS + GMT).

Make sure the new business CA is known by all Transfer CFT flow partners before the certificate is renewed.

Roles for managing certificatesUsers who perform certificate management need appropriate roles for working in the Access and Security user interface. They can be associated with a system administrator role or a certificate role with narrower privileges.

Add system administrator roleUse this procedure to add a system administrator role for Access and Security. This role enables associated users to perform all functions.

1. In Central Governance, select Access > Roles to open the Roles page in Access and Security.

2. Select the PassPort role System administrator and click Copy.

3. Click Paste and type a unique name for the copied role. For example, AS system admin. Click OK to add the role.

4. Go to Assign role on page 136.

Add certificate roleUse this procedure to add a certificate role for Access and Security. This role enables associated users to perform certificate management functions.

1. In Central Governance, select Access > Roles to open the Roles page in Access and Security.

2. Click New Role to open the New Role wizard.

3. Do the following to add the role.

a. On the General Information page, type a unique name for the role. For example, AS certificate manager. Entering a description is optional. Leave Active as the status. Click Next.

b. On the Select Privileges page, select the following PassPort Available Privileges and add them to the Selected Privileges section:


5 Certificates

Manage CA ServicesManage certificates and ssh keysManage entitiesManage server settingsView domains, organizations and users

c. Click Finish to add the role.

4. Go to Assign role on page 136.

Assign roleUse this procedure to assign a role to a user in Central Governance.

1. In Central Governance, select the Access tab.

2. Select a user and click Select roles.

3. Select a role and click Apply.

If the role enables permissions for Access and Security and the user already has a UI session running for the service, the session must be refreshed or reopened for the role to become effective.

Manage invalid or expired certificatesCentral Governance features an internal mechanism that changes the status of a deployed flow if it has an expired or invalid certificate.

How it worksCentral Governance checks flows for expired certificates each day at 00:00, as well as each time Central Governance starts. If Central Governance incurs an expired certificate:

l It changes the status of deployed flows to Saved.

l Any protocol that uses the expired certificate is flagged with a Warning.

l A line is added in the audit to signal each expired certificate. There is also a line in the audit for each impacted flow.

For more information and the certificate expiration date, you can click Display details, which displays in view and edit mode next to the certificate name. If the expired certificate belongs to an SCP, there is an additional warning at the beginning at the page stating that the protocol is invalid, and that you must edit the component to which the certificate belongs.


5 Certificates

UsageIf a flow, partner, unmanaged product, or SecureTransport definition contains an expired certificate, that certificate can still be used in another component. For example, even though a certificate that you used in a client communication profile has expired, you could still use this expired certificate when creating and saving a new client communication profile.

The components that can have an expired certificate are:

l Product server communication profile

l Product client communication profile

l Partner server communication profile

l Partner client communication profile

l Unmanaged product

If a certificate that is no longer valid occurs in a component of a flow, the flow status is Saved and there is a warning to help identify the expired certificate.

Alerts for expiring certificatesThis topic describes alerts for certificates that are about to expire.

How it worksEach night at midnight, Central Governance visibility performs a check to see which certificates expire in N days, where N is a configurable value. Central Governance visibly can then send an email to the users defined in the alert email list. An alert message is sent for each individual certificate that is due to expire.

Configure There are two aspects to configuring your certificate expiration alerts.

l In the initial configuration you can set the number of days prior to expiration when you want the warning about certificate expiration. See Access and security > Notifications on page 60.

l In the Alert Rule List page > Alert Rules define:

o Certificate alias

o Number of days until expiration

o Component type and instance

o See Edit alert rule messages, recipients on page 509.


5 Certificates

Replace SSO certificateCentral Governance provides a default certificate for securing browser connections for SSO1. This certificate is signed by a default CA2. You can replace the default CA with a trusted CA, which automatically customizes the SSO certificate and all SSL certificates used by Central Governance. See CA services for information on replacing the CA.

Alternatively, you can replace only the SSO certificate with a custom certificate. The replacement must not be a self-signed certificate. HSTS3 rejects self-signed certificates. Use the following procedure to change the SSO certificate.

Prerequisites l A user needs permissions to manage certificates to replace the SSO certificate. See Roles for managing certificates on page 135 for details.

l Make sure the replacement certificate file is available on the file system. The certificate file must contain a public-private key pair.

Add entity 1. In Central Governance, select Access > Roles or Access > Privileges to open the Roles or

Privileges page in the Access and Security user interface.

2. Select Security > Entities to open the Entities page. You are going to add an entity4 for the new SSO certificate.

3. Click New Entity to open the Create Entity window. Do the following:

a. Type a unique name for the entity.

b. Select Synchrony as the domain.

c. Type a password. This must be used in future whenever you change the entity contents.

4. Click OK to add the entity.

1Single sign-on (SSO) enables a user to log on once and gain access to all products managed by the SSO system without being prompted to log on again for each product.2A certificate authority (CA) is a trusted third party that issues digital certificates for use by other parties.3HTTP Strict Transport Security (HSTS) ensures browsers connect securely to the user interface. If a user includes http:// in the URL to connect, HSTS converts it to https://.4A password-protected repository of certificates and keys.


5 Certificates

Import certificate 5. On the Entities page, click the name of the entity to open its details page.

6. In the Certificates section, click Import to open the Import Certificate window. Do the following:

a. Type the password of the entity.

b. Type an alias to identify the certificate to be imported. For example, SSO SSL cert.

c. Select the P12 file to import.

d. Type the password for the file.

e. Click OK to import.

7. Once imported, select the Active check box on the entity details page.

8. If available, import the public issuer certificate or certificate chain and trust the root. Alternately, the SSL certificate can be trusted directly, and certificate validation does not include the rest of the chain.

9. Click Save and Cancel to save and close the entity details page.

Replace certificate 10. Select Administration > Server Security Settings to open the Server Security Settings

page.

11. Scroll down the page and find Default_SSO (Entity: SSL).

12. Click Change to open the Change HTTPS Certificate wizard.

13. Select the entity where the replacement certificate is located and click Next.

14. Select the replacement certificate and click Next.

15. Type the entity password and click Finish.

Update SSO certificate before expirationYou can replace the SSO certificate before it expires by changing the governance CA. See CA services for more information.

Alternately, use the following procedure to update the SSL certificate for SSO before its expiration date.

For uninterrupted HTTPS connections, you can open the SSL entity, or the entity with the current SSL certificate, and import a version of the SSL certificate. The version becomes effective when the current SSL certificate expires.

This procedure applies not only to updating the SSO certificate before expiration, but to any certificate used for SSL communications that is stored in an entity.


5 Certificates

1. Make sure your user account has a role with privileges for managing certificates. See Roles for managing certificates on page 135.

2. In Central Governance, select Access> Roles or Access > Privileges to open the Roles or Privileges page in the Access and Security user interface.

3. Select Security > Entities to open the Entities page.

4. Open the SSL entity, or the entity with the current SSL certificate, and import or generate a version of the current SSL certificate. The password of the SSL entity is ssl.

5. Mark the certificate as Active.

If the new SSL certificate version has a different issuer or is self-signed, either its root or the certificate itself must be marked as trusted to be validated properly.

Certificates for HTTP, FTP, PeSITThis topic describes the credentials used by participants in server and client communication profiles for SSL mutual authentication in flows using HTTP, FTP and PeSIT.

To achieve mutual trust, each party must have and trust the CA1 of the other party. However, in some cases, one party might decide to trust an intermediate CA rather than the root certificate, or even directly the end-user certificate, which is not good practice.

Partners and unmanaged products provide only the public part of their certificate or key for mutual trust. When importing a new certificate, you can select one of the following options:

l Import only the root CA, which is a single certificate.

l Import the full public chain, which includes the root self-signed CA, the intermediate CAs and the end user SSL certificate.

l Import a public sub-chain, which starts with an intermediate CA followed by other intermediate CAs and the end user SSL certificate.

When Central Governance deploys configurations, the registered products must receive certificates, which include private keys, representing their own certificates to be used for SSL in flows. When importing a certificate, you must import the full chain of the SSL private certificate. However, you can import a self-signed certificate for SSL for testing purposes.

Object Has private key

File format

Middleware client communication profiles (in flows)

Yes Private chain of certificates: PKCS#12 (*.p12) password protected

Self-signed private SSL certificate: PKCS#12 (*.p12) password protected



5 Certificates


File format

Middleware server communication profiles (on the static configuration page)

Yes Private chain of certificates: PKCS#12 (*.p12) password protected

Self-signed private SSL certificate: PKCS#12 (*.p12) password protected

Partner client communication profiles (in flows)

No Single public certificate: DER (*.der, *.cer), PEM (*.pem)

Public chain of certificates: PKCS#7 (*.p7b)

Partner server communication profiles (on the partner page)

No Single public certificate (CA): DER (*.der, *.cer), PEM (*.pem)

Public chain of certificates: PKCS#7 (*p7b)

Unmanaged product PeSIT SSL certificate No Single public certificate (CA): DER (*.der, *.cer), PEM (*.pem)

Public chain of certificates: PKCS#7 (*p7b)

The following are guidelines for managing certificates.

l You can upload a new certificate or select among existing ones.

l When uploading a new certificate, you must provide an alias.

l The alias must be unique at the participant level. For instance, if certificates are uploaded for a Partner, the alias must be unique at the Partner level (no matter if it is uploaded from the Partner page or from the flow page in a client communication profile).

l If the same certificate exists and it is used by another Partner or Middleware respectively, it will be linked to the existing one while keeping the newly provided alias as a reference. In other words, two aliases can point to the same certificate content

l Private certificates always require a password. This is also mandatory in order to display the certificate information

l Certificates are imported in the Access and Security Public Key Infrastructure (PKI)

l You cannot import the same certificate both for a Partner (only the public part) and a Middleware (the private part as well). This will end up in error.

l At selection, certificates are validated for their trust and validity before returned. Selection may happen when:

o certificates are deployed during flow deployment

o certificates are viewed on the Partner/Middleware/Flow page

o Partner/Middleware is removed, so certificates are also removed along with it.


5 Certificates

l When importing a certificate or a chain of certificates, the top-most will be imported as trusted. This influences how the certificate chain is constructed. A counter-example of what should not be done is:

o Have a Partner1 with chain: CARoot -> CAInt -> Partner1.

o Have a Partner2 with chain: CARoot -> CAInt -> Partner2.

o Import on the Partner1 the chain: CARoot -> CAInt -> Partner1 => CARoot will be imported as trusted.

o Import on the Partner2 the chain: CAInt -> Partner2 or just CAInt => CAInt will be imported as trusted. This will not only impact Partner2 but also Partner1.

o Next time selection for Partner1 is done, the chain will stop at CAInt because it is the first certificate to be found as trusted, while it is recommended that the root-most be trusted.

o The recommendation in this case is:

o Either import only CARoot for both Partner1 and Partner2 (it is sufficient that the Middleware exchanging with this Partner know only the Root-most CA).

o Or, import the full chain for both Partner1 and Partner2.

l When importing a certificate, make sure it is not expired. Central Governance will reject an expired certificate.

Keys for SFTPThis topic describes the credentials used by participants in server and client communication profiles for SSH key authentication in flows using SFTP.

For keys there is no chain of certificates, but a public-private key pair. For SSH the client might ask for the server key verification based on fingerprint or key content.

When the client authenticates with a public key, the client must be provided a private key while the server must have the public key corresponding to the client's private key.

Just as for certificates, partners only deal with the public SSH keys. However, products need the private key to use for authentication as clients or the private key to serve as SSH key for the server. The private key is on the partner's side and is not managed by Central Governance.


File format

Partner server communication profiles (on the partner page)

No public key: DER (.der), PEM (*.pem)

Partner client communication profiles (in flows) No public key: PEM (*.pem)


5 Certificates


File format

Middleware server communication profiles (on the static configuration page)

Yes private key: PKCS#8 (*.p8) password protected

Middleware client communication profiles (in flows)

Yes private key: PKCS#8 (*.p8) password protected

The following are guidelines for managing keys.

l You can upload a new key or select among existing ones.

l When uploading a new key, you must provide an alias.

l The alias must be unique at the participant level. For instance, if keys are uploaded for a Partner, the alias must be unique at the Partner level (no matter if it is uploaded from the Partner page or from the flow page in a client communication profile).

l If the same key exists and it is used by another Partner or Middleware respectively, it will be linked to the existing one while keeping the newly provided alias as a reference. In other words, two aliases can point to the same key content (although functionally it should not be the case in production).

l Private keys always require a password. This is also mandatory to display the key information

l Keys are imported in the Access and Security public key infrastructure (PKI).

l You cannot import the same key both for a Partner (only the public part) and a Middleware (the private part as well). This will end up in error.


6 User management

The following topics are about managing users in Central Governance.

Managing users is limited to users who are assigned to roles with the Central Governance Manage User privilege or a user-defined privilege with similar properties. If the Access tab is not available on the top toolbar, you cannot manage users.

List usersThe User List page displays a list of all users managed by Central Governance. Once the list is displayed, you can add users and perform maintenance such as changing or removing users. This topic provides cross-references for related user-management actions.

Managing users is limited to users who are assigned to roles with the Central Governance Manage User privilege or a user-defined privilege with similar properties.

Click Access on the top toolbar to open the User List page. You can perform the following tasks.

Add user

Click Add user to add a user. See Add a user on page 145.

View user details

Click a user ID to open a page where you can review user details or edit or remove the user. See View, edit, remove a user on page 147.

Assign or unassign roles

Select one or more users and click Select roles to change assigned roles. See Roles and privileges on page 149 and Manage roles on page 152.

Unlock user

Select one or more locked users and click Unlock on the User List page. You also can click the name of a locked user on the User List page and click Unlock on the user details page. See User lockouts on page 148.

Remove

Select one or more users and click Remove to remove from Central Governance.


6 User management

Add a userUse this procedure to add a user in Central Governance. Managing users is limited to users who are assigned to roles with the Central Governance Manage User privilege or a user-defined privilege with similar properties.

Note Users are unique by organization and not globally by user ID. This means two users can have the same user ID provided they belong to different organizations.

Steps 1. Click Access on the top toolbar to open the User List page.

2. Click Add user to open the Add User page.

3. Complete at least the required fields.

You must select an organization for the user. If the organization you want is not available, cancel, add the organization and then add the user. See User organizations on page 154 for details.

Specifying an email address is optional. However, Central Governance can send notifications to the user only if you provide a valid email address. If you add an email address, Central Governance notifies the new user of the URL for the log-on page and credentials for logging on. Without an email address, you must notify the new user yourself.

You should select a role for the user. Users must be assigned to a role to enable them to perform actions. Users without roles can log on to Central Governance, but can access only the Help Center tab. See Roles and privileges on page 149 for information.

4. Click Save user to add the user.

Notifying user of new accountAfter adding a user, what happens next depends on whether you specified a valid email address for the user.

With email addressIf you specified an email address, Central Governance notifies the user of the URL for connecting to the log-on page and credentials for logging on. A randomly generated password is provided that the user must change after logging on the first time. This information is contained in two email messages to the user. The first contains the organization name and user ID. The second contains the password and the link to the Central Governance log-on page.

If the email address is valid but Central Governance cannot send messages because of an SMTP server connection error or other problem, the user is added, but the password is set to Initial01.


6 User management

If the email address is invalid, the user is not notified. The user must inform the Central Governance administrator of failure to receive credentials. The administrator must enter a correct email address for the user and inform the user of their organization. The user then must use the forgot password feature on the log-on page to receive a password.

Without email addressIf you did not specify an email address, inform the user they have been added to Central Governance and provide:

l The user ID and password Initial01. The password is valid for logging on the first time only. The system prompts the first-time user to change the password.

l The name of the organization associated with the user. The user must select this organization when logging on.

l The URL for connecting in a browser to Central Governance.

Customizing email templatesCentral Governance has email template files with content you can use as-is or customize. The templates are the models for email messages the server sends to users with valid email addresses in their Central Governance user accounts.

The template files are at <install directory>\data\mail. The following table lists the templates and their uses.

Template file Description

UserAccountCreation1_en

First message sent to new user. It contains the user's organization name and user ID.

UserAccountCreation2_en

Second message sent to new user. It contains the user's password and a link to the Central Governance log-on page.

UserAccount_Locked_en

Message informs user their account has been locked after the user exceeded the allowed number of consecutive attempts to log on with an invalid password. See User lockouts on page 148 for more information.

UserAccount_Unlocked_en

Message informs user their account has been unlocked.

UserPassword_Reset_en

Message contains a new password for a user who forgot their password. See Password recovery on page 149 for more information.

6 User management

The templates use a combination of text and variables. The variables are replaced with values before the server sends messages. For example, the variable %FirstName% is replaced with the user's first name. The variables you can use are listed and defined in the template files.

The templates contain messages in HTML and plain-text formats. This is for email clients that support plain text but not HTML. When customizing messages, make sure to make identical changes for both formats.

After editing templates, restart Central Governance for the changes to become effective.

You can customize the content of the following parts:

Section Description

subject Message subject line

content.html.body Message in HTML format

content.text.body Message in plain-text format

The default sender of the messages is [email protected], an invalid email address. You can change the sender to a different valid or invalid address. To change the address, edit the value of the mail.sender.address property in the com.axway.cmp.mail-default.cfg file at <install directory>\runtime\com.axway.nodes.ume_<UUID1>\conf.

View, edit, remove a userUse this procedure to view, edit or remove a user in Central Governance. Managing users is limited to users who are assigned to roles with the Central Governance Manage User privilege or a user-defined privilege with similar properties.

Note To add a user see Add a user on page 145.

View user 1. Click Access on the top toolbar to open the User List page.

2. Click the name of the user to open the details page for the user. You can view the user name, organization, email address, user ID, roles and address.

Edit userClick Edit to open a page for editing the user details. If you need information about changing roles, see Roles and privileges on page 149.

6 User management

A user editing their own account cannot change the organization or user ID. Only another user with user management rights can make such changes.

Remove userDo one of the following to remove a user:

l On the User List page, select one or more users and click Remove.

l On the User List page, click the name of a user to open the details page. Click Remove. Or, click Edit and then click Remove.

User lockoutsUsers who make repeated, consecutive attempts to log on with invalid passwords are blocked from logging on even with valid passwords. This occurs after users exceed the allowed limit of unsuccessful attempts. Locked-out users can log on again only after an administrator unlocks their accounts.

By default users can make three consecutive attempts to log on with invalid passwords before the lock-out engages. The number is configurable.

Lock-outs affect only users managed by Central Governance. Users on external LDAP1 identity stores are not affected.

Users with valid email addresses associated with their accounts receive messages when they are locked out. Users without email addresses do not receive notifications.

Unlock usersLock-outs do not expire. Users are locked-out until an administrator unlocks them.

Users who are locked out are identified by a lock icon on the User List page under Access > Users.

To unlock, select one or more locked users and click Unlock on the User List page. You also can click the name of a locked user on the User List page and click Unlock on the user details page.

When a user is unlocked:

l If an email address is defined for the user, the user receives a message containing a new randomly generated password. If Central Governance cannot send the user a message because of an SMTP server connection error or other problem, the user is unlocked but the password is set to Initial01.

l If an email address is not defined for the user, the user's password is reset to Initial01.

1Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.


6 User management

Configure lock-out thresholdYou can change the number of consecutive times a user can fail to log on with an invalid password before being locked out. To change the threshold, edit the value of the number.accepted.failures property in the com.axway.cmp.participant-default.cfg file at <install directory>\runtime\com.axway.nodes.ume_<UUID1>\conf.

Password recoveryCentral Governance enables users with valid email addresses who have forgotten their passwords to get new ones. This only applies to users managed by Central Governance.

A user who clicks the Forgot password link on the log-on page is prompted to select their organization and enter their user ID. After submitting, there can be different results.

l If the user has a valid email address defined in their account and is not locked out, the user receives a message containing a new randomly generated password.

l If Central Governance cannot send a message to a user with a valid email address because of an SMTP server connection error or other problems, a new password is not set.

l If the user has an invalid email address, no address or is locked out, an error message displays and a new password is not set.

l If the user is managed by an external LDAP identity store, an error message displays and a new password is not set. Central Governance cannot reset passwords of such users.

Roles and privilegesRoles and privileges grant or limit users' permissions to perform actions and ordain the areas of the user interface they can access.

RolesA role2 is based on one or more privileges, and a privilege3 is based on a resource4. There are two types of roles: predefined and user-defined. Predefined roles are available by default to assign to users. User-defined roles are custom roles that an administrator creates. Predefined roles cannot be changed or deleted, but you can copy and rename them, and the copies can be managed just like user-defined roles.

1A universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.2A collection of privileges. Roles are assigned to users and govern the products they can access and the actions they can perform.3A user right to perform an action on a resource.4A class of object in a product whose use can be authorized only through privileges associated with user roles.

6 User management

Users can be assigned to one or more roles. Typically, users with multiple roles have more privileges than users with fewer roles. However, you could build a single role that grants unlimited privileges.

Users must be assigned to a role to enable them to perform actions. Users without roles can log on to Central Governance, but can access only the Help Center tab.

Default rolesCentral Governance has default roles that grant different levels of access. Users might have full or partial access to features on the tabs enabled by their assigned roles.

A user with user management authority can assign or unassign roles when adding or editing users in the Central Governance user interface. However, you must access the Access and Security UI to view role details and add or edit roles. See Manage roles on page 152 for how to display a list of Central Governance roles and descriptions.

The following describes the default Central Governance predefined roles.

CG Admin This administrator role grants users unlimited access to all areas of the Central Governance user interface.

Access Manager l Access tab - Full access.

l Administration tab - Full access to services, but no access to deployments, audit or web dashboards.

IT Manager l Products tab - Full access.

l Alert Rules tab - Full access.

l Access tab - Full access.

l Administration tab - Full access to services, but limited access to deployments. The user can view and deploy or redeploy configurations, but not flows. The user also can view and redeploy policies. In addition, this user can run and customize the IT Manager dashboard and reports, run the Audit report and monitor product updates.

Middleware Manager l Products tab - Partial access to products and unmanaged products, and no access to policies and product updates. Role allows viewing product details and configuration, but not editing.

l Applications tab - Full access. This is the only role that gives access to the Applications tab.


6 User management

l Flows tab - Full access. This is the only role that gives access to the Flows tab, which is for managing and monitoring flows. The user can run the Flows Report.

l Alert Rules tab - Full access.

l Administration tab - No access to services and audit, but limited access to deployments. The user can deploy or redeploy flows, but not policies and configurations. In addition, this user can run and customize the Middleware Manager dashboards and reports.

Partner Manager l Applications tab - Full access.

l Partners tab - Full access.

l Access tab - Access to Organization List page. The user can view, add, edit and remove organizations.

Default roles of registered productsAxway products that register in Central Governance also can have default predefined roles. You can do the following to view details of default roles for registered products.

1. Select Access > Roles on the top toolbar in the Central Governance user interface to open the Access and Security Roles page.

2. Click Search, type the name of a product and click Go to display the roles for the product.

3. Click the name of a role to open its details page. The details include the privileges in the role.

PrivilegesPrivileges give users authorization to access and perform actions in the user interface. Privileges are assigned to roles that in turn are assigned to users.

Central Governance has a number of predefined privileges. Predefined means the privileges are available by default to assign to roles. It also means the privileges cannot be changed or deleted. You can, however, make a copy of a predefined privilege and edit the copy. See Manage privileges on page 153 for how to display a list of Central Governance privileges and descriptions.

Privileges are based on resources, and a single privilege is based on a single resource. Each resource has available actions. The privilege inherits the actions, which can be enabled or disabled individually.

For example, Central Governance has a predefined privilege named Manage User. The privilege is built on a resource named User. The User resource has the following actions: view, create, modify, delete, assign, reset. All of these actions are enabled in the predefined privilege.


6 User management

Although you cannot change the Manage User predefined privilege, you can make a copy and enable only some actions. For example, in the copy you can enable only the view action, which enables viewing users in Central Governance, but forbids all other user-management actions, including adding and deleting.

Manage rolesUse this procedure to view a list of Central Governance roles and descriptions and perform other tasks.

Note This topic is an introduction to managing roles in the Access and Security UI. For more details, select Help > Topic Help or Help > Help in the Access and Security UI.

View roles, descriptionsThere are two ways to view roles and descriptions.

Central Governance user interfaceClick Access on the top toolbar to open the User List page. Select a user and click Select roles to open a pop-up that lists available roles. Place your cursor over a role to display a description of it. You can assign or unassign roles or click Cancel when done viewing.

You can open the same pop-up listing available roles when adding or editing a user.

Access and Security user interfaceSelect Access > Roles to open the Roles page in the Access and Security UI. If the list of roles exceeds one page, use the paging controls at bottom right.

Click the Product heading to sort the list of roles by product. Move the cursor over the descriptions in the Description column to display the full descriptions of roles. Descriptions are optional and only display when available.

A blank Product field identifies a user-defined role that contains privileges for multiple products.

There are two types of roles: predefined and user-defined. Only user-defined roles can be edited or deleted. Predefined roles cannot. But you can copy a predefined role, rename it and edit the copy. The Central Governance default roles are predefined; see Default roles on page 150 for a list.

Click the name of a role to open its details page. Notice that a role can contain privileges and sub-roles.

Add, edit, delete a user-defined roleOnly user-defined roles can be added, edited or deleted in the Access and Security UI. But you can copy a predefined role, rename it and edit the copy. Select Help > Help Topic in the Access and Security UI for details about actions for managing roles.


6 User management

Click the name of a user-defined role to open its details page and perform changes.

Any role you add is a user-defined role and is added to the list of roles that can be assigned to users in Central Governance. Conversely, any user-defined role you delete is no longer available to assign. Moreover, if you delete a role that has been assigned, it is removed from the users.

For example, select the CG Admin predefined role and click Copy and then Paste. Enter a name when prompted for the copied role (for example, CG Admin Copy). This copied role is now a user-defined role. Return to the Central Governance UI and click Access on the top toolbar. Select any user and click Select roles. Notice the CG Admin Copy role is listed as an available role to assign.

Manage privilegesUse this procedure to view a list of Central Governance privileges and descriptions and perform other tasks in the Access and Security user interface.

Note This topic is an introduction to managing privileges in the Access and Security UI. For more details, select Help > Topic Help or Help > Help in the Access and Security UI.

Select Access > Privileges to open the Privileges page in the Access and Security UI. If the list of privileges exceeds one page, use the paging controls at bottom right.

View privileges, descriptionsClick the Product heading to sort the list of privileges by product. You can identify the privileges for Central Governance or any product by the Product column.

There are two types of privileges: predefined and user-defined. Predefined privileges are available by default. User-defined privileges are added by users.

Most predefined privileges have descriptions. However descriptions are not required, and some predefined and user-defined privileges might not have descriptions.

By default Central Governance has only predefined privileges. You can view details of predefined privileges, but you cannot edit or delete them.

Click the name of a privilege to open its details page. The name of the resource on which the privilege is based is displayed in the Resource field. The available actions for the privilege are displayed below the resource name.

Add, edit, delete a user-defined privilegeA privilege created by a user is a user-defined privilege. Only user-defined privileges can be edited. But you can copy a predefined privilege, rename it and edit the copy, which becomes a user-defined privilege. The Type column identifies privileges as predefined or user-defined. Select Help > Help Topic for details about adding a user-defined privilege.

Click the name of a privilege to open its details page. Select Help > Help Topic for details about the changes you can make to user-defined privileges.

If you delete a user-defined privilege that has been added to a role, it is removed from the role.


6 User management

About the Default UserCentral Governance has a single Default User with privileges to log on to the user interface when the system is started the first time. This user can add other users.

The user ID of the Default User is [email protected]. The initial password is Initial01, but must be changed when the user logs on the first time. The user has the Access Manager role, which grants privileges for managing users on the Access tab in the user interface.

The Default User can be edited just like any other user. You can change its name, user ID, roles, and so on. However, there is a safeguard for restoring the user to its original configuration should the need arise. For details see the repair parameter in cgcmd command on page 84.

Password policyUsers managed by Central Governance are subject to its password policy1.

New users are given a temporary password. Central Governance forces users to change it the first time they log on. Thereafter, passwords do not expire.

Each password must have:

l 8 characters minimum

l At least 1 lower-case letter

l At least 1 upper-case letter

l At least 1 numeric character

l Not be equal to user ID

l Not be equal to initial password

In addition, passwords are case sensitive and can be any combination of:

l Upper- and lower-case alpha characters

l Numeric characters

l Special characters

User organizationsAn organization is an object containing users who are managed by the same identity store2.

Each user must be associated with an organization. The default in Central Governance is to assign users to Org. This organization uses the Central Governance internal identity store.

1Rules and conditions for valid passwords, such as character length, case requirements and validity periods.2A central repository for managing user identity information, such as roles, privileges and groups. There are two types: internal and external.


6 User management

An organization must have a unique name and be associated with the internal identity store or an external identity store on an LDAP1 server. Optionally, an organization can have a description and an address and phone number.

Note Users are unique by organization and not globally by user ID. This means two users can have the same user ID provided they belong to different organizations.

Manage organizationsUse the following procedures to manage organizations.

If you use an external identity storeIf you associate an organization with an external identity store and are mapping roles between Central Governance and the external LDAP server:

l Central Governance adjusts when an LDAP server has pagination enabled for roles. Central Governance can page through all pages and select all roles as needed. For example, if the LDAP server has 1,000 roles per page, Central Governance iterates through all pages.

l When Central Governance encounters an LDAP server with more than 100,000 roles, it returns an error message and does not display any of the LDAP roles in its user interface. This requires adjusting the filter in the LDAP server to return fewer roles.

View list of organizationsSelect Access > Organizations to open the Organization List page. The page lists all organizations, their identity stores and number of users associated with the organizations.

You can:

l Click the name of an organization to view or edit its details.

l Add or remove an organization.

Add organizationWhen adding an organization, you must associate it with the internal Central Governance identity store or an external identity store on an LDAP server. Using the internal identity store means Central Governance manages users and their roles and credentials. Using an external identity store means users are managed by an LDAP server.

To associate an organization with an external identity store, you first must add the identity store in the user interface. See Use Identity Store List page on page 170 for details.

1Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.


6 User management

1. Select Access > Organizations > Add organization to open the Add Organization page.

2. Complete at least the required fields.

If you select the internal identity store, no other action is required except to save the organization.

If you select an external identity store, you must map internal Central Governance user roles with roles on the LDAP server. Click Map roles to open the Role Mapping page. The top left of the page lists the available internal roles. The bottom half of the page lists the available roles on the LDAP sever.

Select an internal role and the available external roles you want to map to it. Use the add and remove buttons to map or unmap. Click Apply when done.

3. Click Save organization to add it.

If you associated the organization with an external identity store and mapped internal and external roles, the LDAP users can log on with their LDAP credentials to Central Governance. See Log on as LDAP user on page 176 for more information.

View, edit organization 1. Select Access > Organizations to open the Organization List page.

2. Click the name of an organization to view its details. If the organization is associated with an external identity store, click View role mapping to review mapping of internal and external roles. Move the cursor to the top right of the Role Mapping page and click X to close it.

3. Click Edit on the details page.

4. Enter changes as needed. If the organization is associated with an external identity store, you can change identity stores or role mapping.

You cannot change the identity store of Org, but you can change other details (description, address). Org uses the Central Governance internal identity store.

5. Click Save changes.

Remove organizationDo one of the following to remove an organization:

l Select Access > Organizations to open the Organization List page, select one or more organizations and click Remove.

l Select Access > Organizations to open the Organization List page, click the name of an organization to open its details page and click Remove.

If any users are associated with the removed organization, those users also are removed.

You cannot remove the default Org organization.


7 Fine-grained access control

Central Governance supports fine-grained access control (FGAC) to manage instances of objects specified users can view or change in the Central Governance user interface or when using CLI1. Central Governance supports FGAC for:

l Applications, application groups, products, product groups and flows

l Dashboards and reports generated by the Visibility service

You can set up FGAC-enabled privileges in the Access and Security UI. Once created, you also use the Access and Security UI to assign the privileges to roles. Lastly, you assign the roles to users in the Central Governance UI.

The following are examples where FGAC might be useful:

l Differentiate between file transfers that are managed externally and internally.

l Differentiate access to managed file transfers by region or business unit.

l Give access to application groups to specific users. For example, if you have group A and group B, you can grant specific users access to group A and other specific users access to group B.

Objects, resources and actions for FGACThe following table describes:

l The Central Governance objects you can manage with FGAC.

l The technical name of the resources to use in privileges for enforcing FGAC.

l The name of the product that owns the resource. The Visibility service is based on the Sentinel product, which is the name used in the Access and Security user interface.

l The resource properties that can be set as conditions for using FGAC privileges.

l The actions each resource supports. You can enable one or more actions per resource.

Object Resource Resource owner

Resource property

Resource property description

Resource actions

Application Application Central Governance

Name Application name

View, create, modify, delete




Object Resource Resource owner

Resource property

Resource property description

Resource actions

Application group

Application Group

Central Governance

Name Application group name


Flow Flow Central Governance

Name Flow name View, create, modify, delete, deploy

Product Product Central Governance

Name Product name

Logs, stop, start, delete, modify, view

Product group

Product Group

Central Governance

Name Product group name

Start, logs, stop, delete, modify, view, create

Dashboards HTML Dashboard

Sentinel Name Dashboard name

Only the view action is used. The view design and manage actions are not used.

Reports HTML Report

Sentinel Name Report name View

The resource actions have the following meanings for supported actions on objects:

l View is permission to view objects.

l Create is permission to add objects.

l Modify is permission to edit objects.

l Delete is permission to remove objects.

l Logs is permission to view product logs.

l Start is permission to start products.

l Stop is permission to stop products.

l Deploy is permission to deploy flows to registered products.

Here's how you can view resources for products in the Access and Security UI. In the Central Governance UI, select Access > Roles or Access > Privileges to open the Access and Security UI. Then select Administration > Products to open the Access and Security Products page. Click the name of a product to open its details page. Click the Resources tab to view the resources for the product. Click the name of a resource to view details about it.



FGAC-enabled predefined privilegesThe Central Governance Access and Security service has the following predefined privileges that are based on resources that support FGAC. You cannot edit conditions of predefined privileges. But you can make copies of the predefined privileges, which makes the copies user-defined privileges, and then customize actions and set the name property in the privilege condition editor. The name property is the key to FGAC support.

You also can create your own user-defined privileges based on FGAC-enabled resources. You can only enable FGAC for user-defined privileges and not predefined privileges.

Predefined privilege Privilege owner

Resource Enabled actions

Administrate Product Central Governance

Product Logs, stop, start, delete, modify, view

IT Manager - Execute reports in Web Dashboards

Sentinel HTML Report

View

IT Manager - Execute dashboards in Web Dashboards

Sentinel HTML Dashboard

View

Manage Application Central Governance

Application View, create, modify, delete

Manage Application Group Central Governance

Application Group


Manage Flow Central Governance

Flow View, create, modify, delete, deploy

Manage Product Group Central Governance

Product Group

Logs, stop, start, delete, modify, view

Middleware Manager - Execute dashboards in Web Dashboards

Sentinel HTML Dashboard

View

Middleware Manager - Execute reports in Web Dashboards

Sentinel HTML Report

View

View Application Central Governance

Application View

View Application Group Central Governance

Application Group

View



Predefined privilege Privilege owner

Resource Enabled actions

View Flow Central Governance

Flow View

View product Central Governance

Product View

The name condition for the Application resource applies to individual applications, but the name condition for the Application Group resource applies to all applications within the group. For efficiency, you could group applications and then have a single Application Group privilege. The specified name condition in the privilege would apply to all applications within the group.

Steps to enable FGACUse the Access and Security service user interface to manage FGAC privileges and associated roles. In the Central Governance UI, select Access > Privileges to open the Access and Security Privileges page.

The following are guidelines for enabling FGAC.

1. Create a user-defined privilege that is based on a FGAC resource. See Objects, resources and actions for FGAC on page 157.

2. When adding or editing a user-defined privilege, use the condition editor to set a value or property for the name resource property.

3. Once the privilege is configured, associate it to one or more roles.

l For users managed by an LDAP identity store, map custom roles to external LDAP role definitions (user groups or roles) in the external organization.

l For users managed by Central Governance, assign the privilege to one or more user-defined roles.

See the Access and Security help for details about managing privileges and roles. In the Access and Security UI, select Help > Help and see the following topics:

l Access menu > User privileges

l Access menu > User roles

The Central Governance documentation also has topics about roles and privileges managed in the Access and Security UI. See Roles and privileges on page 149.



Guidelines for creating FGAC privilegesThe following tables provide guidelines for creating user-defined privileges that are FGAC1 enabled.

Any FGAC-enabled objectThe following table provides guidelines for creating user-defined privileges for any FGAC-enabled object. See Objects, resources and actions for FGAC on page 157 for the names of FGAC-enabled objects and their related resources.

If you want to

You need a privilege with A user role with the privilege can

Create objects

View and Create actions enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

View and create objects.

Edit objects

View and Modify actions enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

View and edit objects.

Remove objects

View and Delete actions enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

View and remove objects.

View objects

View action enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

View lists of objects and object details.

Product, Product Group, Product Configuration and Update Package resourcesThe following tables provide guidelines for creating user-defined FGAC-enabled privileges with the following resources:

l Product

l Product Group

l Product Configuration

l Update Package

Product and Product Group are FGAC-enabled resources, but Product Configuration and Update Package are not. The latter two resources can be added to privileges in roles that also have privileges based on FGAC-enabled resources.

1Fine-grained access control (FGAC) is a way to manage users' access to objects or capacity to perform actions. For example, you could enable some users to view specific objects in the user interface, but prohibit other users from viewing the same objects.



Product resource

If you want to


Edit products

View and Modify actions enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

View and edit products. Also applies to using the productList CLI command.

Remove products

View and Delete actions enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

View and remove products. Also applies to using the productList CLI command.

Start products

View and Start actions enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

View and start products. Also applies to using the productStart and productList CLI commands.

Stop products

View and Stop actions enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

View and stop products. Also applies to using the productStop and productList CLI commands.

View products

View action enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

View lists of products and product details. Also applies to using the productList CLI1 command.

Product Group resource

If you want to


Edit products in a product group

View and Modify actions enabled for the Product Group resource and FGAC filter conditions set on the name property in the privilege.

View and edit products in product groups. Also applies to using the productList CLI command on product group members.

Remove products in a product group

View and Delete actions enabled for the Product Group resource and FGAC filter conditions set on the name property in the privilege.

View and remove products. Also applies to using the productList CLI command on product group members.




If you want to


Start products in a product group

View and Start actions enabled for the Product Group resource and FGAC filter conditions set on the name property in the privilege.

View and start products in product groups. Also applies to using the productStart and productList CLI commands on product group members.

Also can restart products if the role also has stop product group privilege.

Stop products in a product group

View and Stop actions enabled for the Product Group resource and FGAC filter conditions set on the name property in the privilege.

View and stop products in product groups. Also applies to using the productStop and productList CLI commands on product group members.

View products in a product group

View action enabled for the Product Group resource and FGAC filter conditions set on the name property in the privilege.

View lists of products in product groups. Also applies to using the productList CLI1 command on product group members.

Product Configuration resource

If you want to

You need a role with A user with the role can

Deploy product configurations

Privilege 1: View action enabled for the Product or Product Group resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: View and Deploy actions enabled for the Product Configuration resource.

View and deploy configurations and view deployments on products or product group members. Also applies to using the productList CLI command.




If you want to


Edit product configurations


Privilege 2: View and Modify actions enabled for the Product Configuration resource.

View and edit configurations and view deployments of products or product group members. Also applies to using the productList CLI command.

View product configurations and deployments


Privilege 2: View action enabled for the Product Configuration resource.

View configurations and deployments of products or product group members. Also applies to using the productList CLI command.

Update Package resource

If you want to


Update a product


Privilege 2: View and Deploy actions enabled for the Update Package resource.

or

Privilege 1: View action enabled for the Product resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: Manage Update Package predefined privilege.

Deploy updates on products or product group members. Also applies to using the productList CLI command.

Application and Application Group resourcesThe following tables provide guidelines for creating user-defined FGAC-enabled privileges with the Application and Application Group resources.



Application resourceFor all of the following options, permissions for application groups supersede permissions for applications.

If you want to

You need a privilege with Comment

Edit applications

View and Modify actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

Permissions for application groups supersede permissions for applications.

Group applications in application groups

Privilege 1: View action enabled for the Application resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: View , Create and Modify actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.


Link products to applications

View action enabled for the Application resource and FGAC filter conditions set on the name property in the privilege.

If the user has rights to view an application, the user can link it to every product even without rights on products.

Remove applications

View and Delete actions enabled for the Application resource and FGAC filter conditions set on the name property in the privilege.


View applications and their details

View action enabled for the Application resource and FGAC filter conditions set on the name property in the privilege.




Application Group resource

If you want to You need a privilege with A user role with the privilege can

Create application groups

View and Create actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

Create application groups that met FGAC conditions.

Create application groups and add applications to the groups

View , Create and Modify actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

In the grouping action, for example, add an application group and link an application to the group.

Edit application groups

View and Modify actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

View application members and their details and edit them.

Remove application groups

View and Delete actions enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

View application members and their details and remove application groups.

View applications as members of an application group and view the application group and its details

View action enabled for the Application Group resource and FGAC filter conditions set on the name property in the privilege.

View applications as members of application groups and application details. If the user has rights on all application groups, the user can view all applications belonging to groups.

Flow resourceThe following table provides guidelines for creating user-defined FGAC-enabled privileges with the Flow resource.



If you want to

You need a privilege with A user with the privilege can

Create flows

Privilege 1: View and Create actions enabled for the Flow resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: View action enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

Create flows that use objects — applications, application groups, partners, unmanaged products, products — when the user has view rights on the respective objects.

Deploy flows

View and Deploy actions enabled for the Flow resource and FGAC filter conditions set on the name property in the privilege.

View and deploy allowed flows and view flow deployments.

Edit flows

Privilege 1: View and Modify actions enabled for the Flow resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: View action enabled for the object's resource and FGAC filter conditions set on the name property in the privilege.

For sources and targets, edit flows when the user has view rights on applications, application groups, partners and unmanaged products.

For relays, edit flows when the user has view rights on products and unmanaged products.

The user can edit flows without rights on objects provided the user does not change the objects in flows. A user without rights on an object cannot edit an object.

Remove flows

View and Delete actions enabled for the Flow resource and FGAC filter conditions set on the name property in the privilege.

Remove the allowed flows.

View flows and their details

View action enabled for the Flow resource and FGAC filter conditions set on the name property in the privilege.

View details of flows and view flow deployments.

HTMLDashboard and HTMLReport resourcesThe following table provides guidelines for creating user-defined FGAC-enabled privileges with the HTMLDashboard and HTMLReport resources.



If you want to

You need a role with

Comment

View web dashboards

Privilege 1: View action enabled for the HTMLDashboard resource and FGAC filter conditions set on the name property in the privilege.

Privilege 2: View action enabled for the HTMLReport resource and FGAC filter conditions set on the name property in the privilege.

Privilege 3: Manage Web dashboards, access, reports and database Sentinel predefined privilege.

User needs privileges on all used subcomponents of dashboards (that is, HTMLReport). The Manage Web dashboards, access, reports and database predefined privilege gives permission to access dashboards in the Central Governance user interface. Without the privilege the user can access web dashboards directly with a URL or has dashboard rights.

Design web dashboardsA user with a role with the following Sentinel predefined privileges can design dashboards:

l Manage Web dashboards, access, reports and database

l Manage dashboards in Web Dashboards

The Manage Web dashboards, access, reports and database predefined privilege gives permission to access dashboards in the Central Governance user interface. Without the privilege the user can access web dashboards directly with a URL or has dashboard rights.


8 Identity stores

Central Governance supports internal and external identity stores. There is one internal identity store1. You can set up multiple external identity stores on LDAP2 servers.

All users are associated with an organization, and each organization is associated with an identity store. Multiple organizations can be associated with the same identity store.

Internal and external identity storesThe internal identity store is the default mode for user identification. It uses the Central Governance Access and Security service as the authentication source. To use this mode, select the internal identity store option when adding an organization. Set up and manage users within the Central Governance user interface and associate the users with an organization that uses the internal identity store.

When you use an external identity store for an organization, you must set up and manage users externally and not within the Central Governance user interface. However, you must map roles between Central Governance and the external system.

LDAP identity storeTo use LDAP authentication, you must have a running LDAP server and the knowledge to configure the server and create and manage users, passwords, roles and groups.

The Central Governance password policy3 does not apply to the externally managed users on the LDAP server. Also, you cannot change passwords of external users from within Central Governance.

You can use any LDAP V3 compliant server. Set up users, roles and groups on the LDAP server instance. For example, you could add entities with the following names:

l User: CGuser

l Role: CGrole

l Group: CGgroup

1A central repository for managing user identity information, such as roles, privileges and groups. There are two types: internal and external.2Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.3Rules and conditions for valid passwords, such as character length, case requirements and validity periods.


8 Identity stores

Use Identity Store List pageUse the Identity Store List page to add, view, edit or remove an external identity store. Select Access > Identity stores to open the page.

Add identity store

Click Add identity store to open the Add Identity Store page. Complete the configuration and click Save identity store when done. See LDAP identity store fields on page 170 for descriptions of the fields.

View identity store

Click the name of an identity store to open its details page.

Edit identity store

Click the name of an identity store to open its details page, and then click Edit. Click Save changes after editing fields. See LDAP identity store fields on page 170 for descriptions of the fields.

Remove identity store

Do one of the following to remove an identity store:

l Select one or more identity stores on the Identity Store List page and click Remove.

l Click the name of an identity store to open its details page, and then click Remove.

l Click the name of an identity store to open its details page, and then click Edit and Remove.

LDAP identity store fieldsThe following are the fields for configuring an LDAP1 identity store2 in Central Governance.

Refer to these fields when managing identity stores. See Use Identity Store List page on page 170.

Name

Name of the identity store. This can be any unique name you want.

Description

Optionally, a description of the identity store.

1Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.2A central repository for managing user identity information, such as roles, privileges and groups. There are two types: internal and external.


8 Identity stores

Connection

ServerHost(s)

Fully qualified domain name or IP address of the computer running the LDAP server. You may specify multiple hosts. If the first host is unreachable, PassPort tries to connect to the next host in the list, and so on.

Port

Port the server listens on for connections.

Encryption mode

Security level to use for the connection between Central Governance and the LDAP server. Options are:

None - Clear communication

StartTLS - Transport Layer Security (TLS1) secured connection

Certificate

Click Browse to select a public-key certificate file in the format DER or PEM or a public certificate chain file in the format P7B (PKCS#7). A certificate is required when StartTLS encryption is selected, representing the certificate authority of the LDAP server. When a certificate is selected, click Display to show certificate details.

AuthenticationLogin

User ID for logging on to the LDAP server to retrieve user roles and user groups. This data enables the administrator to map roles and groups between Central Governance and the LDAP server.

Password

Password for logging on to the LDAP server.

Authentication Mode

Authentication mode for logging on to the LDAP server.

Simple - Use the user's relative distinguished name (RDN) to authenticate

1Transport Layer Security (TLS) is an encryption protocol that ensures communication security over the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS.


8 Identity stores

Advanced settingsConnection timeout

Timeout limit in seconds for the LDAP connection.

Number of retries

Number of times Central Governance attempts to re-connect after the connection fails.

Enable connection pooling

Enables connection pooling for user login and filter searches.

Click Check connection to verify whether the values are valid for the LDAP server. If the connection fails, Central Governance displays failure reasons returned by the LDAP server.

LDAP treeActive directory

Indicates whether the LDAP server is a Windows Active Directory implementation. Active Directory enables users to log on with the notation user@domain. If this is an Active Directory and the login does not include the @ character, Central Governance adds @domain to the login.

If you specify the server is Active Directory, you optionally can provide the value for the domain in the following field.

Active directory domain

For Active Directory LDAP servers, the domain to be added to the user login if the domain is absent.

This field is optional when Active Directory is enabled. If you leave the field blank, nothing is appended to the user name.

Base DN

The base Distinguished Name (DN) to authenticate on the connected LDAP server. The top level of the LDAP directory tree is the base DN.The base DN defines which node of the LDAP tree to use as the root node. Example: ou=system

Prefix

Prefix to add to the user login for connection to the LDAP server. Example: cn=username.

Suffix

Suffix to add after the user login to the LDAP server. Example: ,ou=users

Prefix and suffix are optional. If you provide both, Central Governance can use the values to derive a full user DN based on the SubjectDN X500principal:

prefix + user login + suffix + baseDN


8 Identity stores

This allows users to enter only their user name at login.

AuthorizationThe values of the following fields specify the LDAP search queries, telling Central Governance how to retrieve objects from the LDAP structure.

Central Governance uses LDAP queries at run-time to populate fields in the mapping wizard table, and also to evaluate login requests.

To complete these fields it is important to carefully define which LDAP object class controls your access control.

Query syntax must match the target LDAP structure, and use the same object class names as used on the server. Default values that appear in the fields reflect standard naming conventions. If your LDAP server structure includes non-standard naming, you must indicate the customized names in these fields.

Cache timeout

Indicates how long in hours the response to an LDAP query is considered valid.

User DN

Returns the user searched DN from the LDAP server. If this filter is not set, the user searched DN is replaced by the user Full DN. In other filters this will be the userSearchedDN.

Role list

Returns all roles on the LDAP server.

Filtered roles

Returns roles matching the specified filter on the LDAP server.

User roles

Returns all roles of a user on the LDAP server.

Group roles

Returns all roles of a group on the LDAP server.

User groups

Returns all groups of a user on the LDAP server.

Mapping role attribute

Attribute for identifying roles in mapping process.

User mappingSelect a user object class and map values of user attributes available on the LDAP server.


8 Identity stores

User Filter

Returns all users in a domain on the LDAP server.

First name attribute

Value to filter for a specific user first name.

Last name attribute

Value to filter for a specific user last name.

Email attribute

Value to filter for a specific user email address.

Example LDAP setup for ADThis example provides LDAP identity store default values for any Microsoft Windows Active Directory (AD) having out-of-the-box configuration.

AD is the Microsoft implementation of a directory service. The AD is used to authenticate and authorize all users in a Windows domain-type network.

ConnectionHost(s)

<ldap.company>.com

Port

389

Login

<user email>

Password

<user password>

LDAP treeActive directory

Yes

Active directory domain

<company>.com

8 Identity stores

Base DN

DC=company,DC=com

AuthorizationCache timeout

12

User DN

(&(objectClass=organizationalPerson)(sAMAccountName=:userLogin:))

Optionally, you can append the string with (!(userAccountControl= <code>))) to deny access to users who have been disabled. In the following example, 514 is the code for a disabled account:

(&(objectClass=organizationalPerson)(sAMAccountName=:userLogin:)(!(userAccountControl=514)))

A list of codes for disabled users is at the following URL:

http://www.netvision.com/ad_useraccountcontrol.php

Role list

(objectClass=group)

Filtered roles

(&(objectClass=group)(cn=:filter:))

User roles

(&(objectClass=group)(member=:userSearchedDN:))

Group roles

(&(objectClass=group)(memberOf=:groupFullDN:))

User groups

(&(objectClass=group)(member=:userFullDN:))

Mapping role attribute

cn

User mappingUser filter

(objectClass=organizationalPerson)


http://www.netvision.com/ad_useraccountcontrol.php

8 Identity stores

First name attribute

givenName

Last name attribute

sn

Email

mail

Log on as LDAP userA user managed on an LDAP1 server in an external identity store2 uses this procedure to log on to Central Governance.

Prerequisites l An external identity store has been added. See Use Identity Store List page on page 170.

l The identity store is associated with an organization and external and internal roles are mapped. See Add organization on page 155.

l The user knows their LDAP user ID and password and the name of the Central Governance organization associated with the identity store.

l The user knows the URL for connecting to the Central Governance log-on page in a browser.

Steps 1. Open the Central Governance log on page in a browser.

2. On the log-on page, select your organization from the drop-down list and enter your LDAP user ID and password.

3. Click Sign in to log on.

Once logged on, the actions the user can perform depends on the mapping of internal to external roles within the user's organization.

1Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.2A central repository for managing user identity information, such as roles, privileges and groups. There are two types: internal and external.


9 Product registration

The following topics are about registering products for Central Governance to manage.

Central Governance must be installed and running before products can register and be managed.

This version of Central Governance is compatible with Transfer CFT versions 3.1.2 and higher, SecureTransport 5.3.1 and higher, and Axway Gateway 6.17.1 and higher.

Transfer CFT registrationThe following topics describe the tasks to register Transfer CFT in Central Governance.

The parameters for connecting Transfer CFT and Central Governance are specified during installation of Transfer CFT. After installation, the Transfer CFT Copilot is started, and Copilot connects to Central Governance to begin the registration process. Only Copilot, and not Transfer CFT server, must be started to begin the registration process.

The following graphic illustrates the Transfer CFT registration process with Central Governance.



Use the numbers in the graphic to correlate with the text describing each phase.

As noted in 4. Transfer CFT configuration updated on page 179, Central Governance pushes configurations to Transfer CFTs upon registering. By default Central Governance sets Transfer CFTs to use the Visibility service within Central Governance. If you want Transfer CFTs to use Axway Sentinel instead, see Use local settings for Sentinel on page 181 for details.

1. Registration requestCopilot must be started to begin the registration process. Transfer CFT also can be started, but this is optional for registration. Copilot makes a simple-authentication connection to Central Governance.

A registration request is sent that contains:

l Information about Transfer CFT, including its instance name, host, port, operating system and version.

l The Central Governance shared secret. The shared secret, obtained from the Central Governance administrator, is set in Transfer CFT when Transfer CFT is installed.

l Certificate signing requests (CSRs) for Central Governance to process, and the names of the certificate authority (CA) services that process the CSRs.

Products must use the Central Governance shared secret to register successfully. The shared secret was set during initial configuration of Central Governance, immediately after it was installed but before the server was started the first time.

2. Certificates for Transfer CFTThe following describes the certificates Central Governance sends to Transfer CFT, depending on your choice of certificate authorities.

Default CAsWhen the default CAs are used, the Central Governance Access and Security service creates a security entity1 for Transfer CFT. It uses as the entity name the concatenation of the Transfer CFT InstanceId and InstanceGroup, which both were set during installation of Transfer CFT.

Central Governance then generates a signed business certificate to be used for securing file transfers between the registering Transfer CFT and all other Transfer CFTs. The Transfer CFT name is used to identify the business certificate. The business certificate authority is the internal CA that generates and signs the certificate, which is known as the PassPort CA in the Access and Security service.

Along with the business certificate, Central Governance generates and sends a governance certificate to Copilot. The governance certificate is used to secure communications between Central Governance and Transfer CFT and its Copilot. The governance certificate authority is the CA that generates this certificate, which is known as PassPort Product CA in the Access and Security service.

1A password-protected repository of certificates and keys.



Custom CAsYou can customize the business and governance CAs on the Central Governance configuration page. See Access and security on page 58 for details.

Before Transfer CFT is registered in Central Governance, the custom governance CA must be known and trusted by the registering Transfer CFT.

Customizing the business CA affects the secured transfers between the registering Transfer CFT and other Transfer CFTs. All other Transfer CFTs must know and trust the new business CA.

3. Mutually authenticated connectionOnce Copilot has the certificates, it connects to Central Governance on the secured communications port using the Central Governance certificate.

All heartbeat connections between Copilot and Central Governance are mutually authenticated on the same port. Only Copilot sends heartbeats during registration.

Every time Copilot starts it checks the validity of the certificates. A renewal request is scheduled when a certificate has expired or is about to. The Transfer CFT parameter cg.renewal_period, with a default value of 60 days, is used to identify certificates about to expire.

For certificates about to expire, renewals are through the mutually authenticated connection. However, if the certificate used for mutually authenticated connections has expired, the simple authentication connection is used. Before Transfer CFT receives a new certificate, the product status is Unreachable in the Central Governance user interface.

4. Transfer CFT configuration updatedCompleting the registration process, Central Governance gets the current configuration of Transfer CFT and changes it.

l Transfer CFT is configured to use the Central Governance Access and Security service for access management.

l Transfer CFT is configured to use the Central Governance Visibility service for transfer monitoring. For Transfer CFT 3.2.2 and higher, a secured connection is used.

These changes create two security profiles (CFTSSL) on the Transfer CFT. The profiles are named SSL_DEFAULT; one profile is of type client and one is of type server. Their SSL version is TLSV1COMP. The configured cipher list is CIPHLIST= ('53','47') for Transfer CFT 3.1.2 and 3.1.3. The values represent the following cipher suites:

The values represent the following cipher suites:

l 47: TLS_RSA_WITH_AES_128_CBC_SHA



For Transfer CFT 3.2.2 and higher, the configured cipher list is CIPHLIST= ('49200', '49199', '49192', '49191', '157', '156', '61', '60', '53', '47'). The values represent the following cipher suites:

l 49200: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

l 49199: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

l 49192: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

l 49191: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

l 157: TLS_RSA_WITH_AES_256_GCM_SHA384

l 156: TLS_RSA_WITH_AES_128_GCM_SHA256

l 61: TLS_RSA_WITH_AES_256_CBC_SHA256

l 60: TLS_RSA_WITH_AES_128_CBC_SHA256



The client and server security profiles must be mutually authenticated. However, by default, a registered Transfer CFT does not have a protocol with a security profile. You must edit the Transfer CFT configuration to support protocols with mutual authentication.

Central Governance sends the updated configuration to Transfer CFT. The following are the Transfer CFT parameters updated in this process.

Parameter Value

am.passport.cg.organization Org

am.passport.domain CG

am.passport.hostname <Central Governance host name >

am.passport.instance_id $(cft.instance_group).$(cft.instance_id)

am.passport.port 6666

am.passport.use_ssl Yes

am.passport.userctrl.check_permissions_on_transfer_execution

No

am.type passport

cft.purge.rt 10D

cft.purge.rx 10D

Parameter Value

cft.purge.st 10D

cft.purge.sx 10D

cft.server.bandwitdth.cos 4

cft.server.bandwitdth.cos.0.max_rate_in -1

cft.server.bandwitdth.cos.0.max_rate_out -1

cft.server.bandwitdth.cos.1.weight_in 80

cft.server.bandwitdth.cos.1.weight_out 80





cft.server.bandwitdth.enable No

cg.mutual_auth_port <secured communications port>

copilot.misc.createprocessasuser No

pki.type cft

sentinel.trkipaddr <Central Governance host name >

sentinel.trkipport 1305

sentinel.xfb.enable Yes

sentinel.xfb.use_ssl Yes

Use local settings for Sentinel When Transfer CFTs register, the default is for Central Governance to configure Transfer CFTs to use the Visibility service within Central Governance. Outside of Central Governance, the Visibility service is Axway Sentinel. There might be occasions when Transfer CFTs are using Sentinel and must continue using it after registering with Central Governance. In these cases you can disable Central Governance from overwriting existing configurations in Transfer CFTs for using Sentinel.

Set the following Central Governance property to false before registering Transfer CFTs:

setSentinelAtRegistration=true

The property is in the com.axway.cmp.cgcft-default.cfg file at <install directory\runtime\com.axway.nodes.ume_<UUID1>. Restart Central Governance for the change to become effective.

The following are the Sentinel properties in Transfer CFTs whose values are untouched when the registration property in Central Governance is disabled.

l sentinel.trkipport

l sentinel.trkipaddr

l sentinel.xfb.enable

l sentinel.xfb.use_ssl

Registration approvalYou can configure Central Governance to require approval when Transfer CFT 1.1.2 or higher attempts to register. Transfer CFT 3.1.3 and lower register automatically, as these versions do not support the registration approval feature.

Configure registration approvalYou can enable registration approval from the Central Governance configure on page 85 mode. See Configuration and startup on page 52 for details.

Approve a registration 1. Start the Transfer CFT Copilot. In the Central Governance Product list page, the Transfer

CFT status becomes Ready to register.

2. Access the Transfer CFT details page and click Approve registration. The user must have MODIFY rights on the product resource to approve the registration.

Note An approval type registration may take longer than a registration without approval for Transfer CFT.

Reject a Transfer CFT registration You can reject a Transfer CFT that is in the Ready to register status by removing it from Central Governance and then stopping Copilot. It is strongly recommended that you wait for at least 1 minute before stopping Copilot.


Rejecting a registration sets the Transfer CFT cg.enable parameter to No. To re-register Transfer CFT:

1. Run the following command to set the parameter to Yes:

CFTUTIL UCONFSET ID=cg.enable, VALUE=Yes

2. Restart Copilot to begin the registration process.

Registration resultsRegistration is successful when one of the following statuses is reported on the Central Governance Product List page:

l Started. Registration succeeded, and Transfer CFT is running.

l Stopped. Registration succeeded, and Transfer CFT is not running.

If a problem occurs during registration, Transfer CFT is registered with an error. See Transfer CFT registration troubleshooting on page 185 for information on registration errors.

Assign a policy during registrationIn addition to the changes in the preceding table, Transfer CFT becomes linked to the policy configured in the Transfer CFTcg.configuration_policy parameter. If the policy does not exist in Central Governance at registration, no operation is performed even if the policy is created after registration.

The policy configuration might overwrite the default parameters Central Governance updates. For instance, if the policy contains access management set to None, Transfer CFT is configured to use None rather than the Central GovernanceAccess and Security service.

See Manage policies on page 274 for information about adding policies for Transfer CFTs in Central Governance.

Change CAs after Transfer CFT registrationAfter registering Transfer CFTs in Central Governance, changing any of the Central Governance certificate authorities requires resubmitting certificate registration:

1. Transfer CFT Copilot requests a new SSL certificate signed by the new CA1.

2. Central Governance sends the requested certificate to Copilot.

Also see CA services for more information.



Governance CAChanging the governance CA affects registered Transfer CFTs. You must import the new CA in Transfer CFT and schedule the certificate registration.


Transfer CFT 3.1.2For Transfer CFT 3.1.2, stop Copilot and Transfer CFT and do the following:

Replace the PassPort CA by running the following Transfer CFT command:

PKIUTIL PKICER ID = 'PassPortCA', ROOTCID = 'PassPortCA', ITYPE = 'ROOT', INAME = '<GovernanceCACertificateFile>’, IFORM = 'DER', MODE = 'REPLACE’

Then trigger the certificate registration by resetting the cg.registration_id to -1 with the following command:


Restart Copilot.

Transfer CFT 3.1.3 and higherFor Transfer CFT 3.1.3 and higher, import the new CA by doing one of the following:

l Configure the CA by setting the CA Certificate by using the installer for Transfer CFT in configure mode. You must stop Copilot and Transfer CFT before starting the installer in configure mode. You can run the configure command in the Transfer CFT installation directory to start the installer in configure mode.

or

l If you do not want to stop Transfer CFT, use the following commands:

o PKIUTIL PKICER ID = '<CG CA new alias>', ROOTCID = '<CG CA

new alias>', ITYPE = 'ROOT', INAME =

'<GovernanceCACertificateFile>’, IFORM = 'DER', MODE =

'CREATE'

o CFTUTIL UCONFSET ID=cg.ca_cert_id, VALUE='<CG CA

alias>,<CG CA new alias>'

Then set the parameter cg.certificate.governance.renewal_datetime (format: YYYYMMDDHHMMSS + GMT) to schedule the request at first heartbeat after the specified date and time.


The heartbeat interval is specified in seconds in the cg.periodicity parameter (default value 600). For example, schedule the certificate request to start December 23, 2014, at 14:30:00 + GMT by running the following command:

CFTUTIL UCONFSET ID=cg.certificate.governance.renewal_datetime, VALUE=20141223143000

Transfer CFT becomes unreachable until the new certificate is received.

Business CAIf the business CA is changed, a new business SSL certificate can be requested. The new certificate is signed by the new CA and used in secured flows.

Schedule a new certificate request starting with the time specified in the Transfer CFT parameter cg.certificate.business.renewal_datetime (format: YYYYMMDDHHMMSS + GMT).

Make sure the new business CA is known by all Transfer CFT flow partners before the certificate is renewed.

Transfer CFT registration troubleshootingThe following are guidelines for troubleshooting Transfer CFT registration.

Transfer CFT does not display in UITransfer CFT has registered and is running, but is not listed in the Central Governance user interface. To ensure that Transfer CFT has registered properly:

l Verify Central Governance is fully started. See Status of Central Governance and services on page 47.

l Verify the Central Governance IP address or FQDN1 you entered in Transfer CFT.

l On the computer running Transfer CFT, verify Central Governance is reachable at the IP address or FQDN specified in the Transfer CFT configuration.

l Check the Central Governance logs. If the Transfer CFT does not appear, typically the Transfer CFT was unable to contact Central Governance.

Transfer CFT registered in error following a startTransfer CFT is started and has a "registered in error" status:


l Check the Central Governance logs for additional information.

1fully qualified domain name


l Check whether the shared secret provided by the Central Governance administrator matches the shared secret Transfer CFT submitted when registering.

l Check whether the governance certificate authority exists in the Transfer CFT PKI. See CA services for more information.

l Check whether Transfer CFT has the maximum allowed number of CRONTABs1 within an active configuration (CFTPARM2). Central Governance creates and deploys a dedicated CRONTAB named CGCRONTAB during registration and attaches it to the active configuration for use in CRONJOBs. Reduce CRONTABs to less than 32 in the Transfer CFT configuration to allow the CGCRONTAB creation.

l If the Transfer CFT parameter cg.configuration_policy is set and the policy exists in

Central Governance, check whether the policy deployment status is in error.

If registration approval fails...If you did not wait 1 minute for the registration approval and it fails, perform the following steps to re-register the Transfer CFT.

1. Start Copilot.

2. Access the UCONF cg.enable parameter and check that it is set to Yes.

3. If it is set to No, change to Yes and restart Copilot

If registration fails... 1. Stop Transfer CFT and its Copilot.

2. Remove Transfer CFT from Central Governance. See Remove products on page 212.

3. Check the registration settings in Transfer CFT for accuracy. Check that:

cg.registration_id = -1

cg.port = <Central Governance registration port>

See Check registration settings on page 186 for details.

4. Restart Copilot to start the registration process.

Check registration settingsUse one of the following methods to check the registration settings in Transfer CFT.

Method 1

Run the following command to display a list of properties and values for Central Governance:

CFTUTIL LISTUCONF ID=cg*

1In Transfer CFT, a CRONTAB is a parameter that represents a file or list of files containing the scheduled jobs.2An object or command for general Transfer CFT environment parameters.

Check the values and change if needed. For example, if the registration ID is not -1, change the value with the command:


Check the Transfer CFT PKI and add the custom governance CA if missing:

PKIUTIL PKICER ID = '<CG CA alias>', ROOTCID = '<CG CA alias>', ITYPE = 'ROOT', INAME = '<GovernanceCACertificateFile>’, IFORM = 'DER', MODE = 'REPLACE'

Method 2

In the Copilot user interface, go the UCONF table, search for the Central Governance settings, and check the registration ID and port. Change the values if needed.

If the governance CA was changed in Central Governance, go to the Public Key Infrastructure table and check whether the new CA exists. Import it if needed.

SecureTransport registrationThe following topics describe what happens when SecureTransport registers in Central Governance and the prerequisites and process for registering.

Unique and duplicate server communication profilesBefore registering you should understand how unique and duplicate server communication profiles are determined when SecureTransport has SecureTransport Edge servers deployed within its infrastructure.

One or more SecureTransport Edge servers can be grouped in a network zone in SecureTransport. An edge can belong to one or more network zones. During Central Governance registration, for each network zone, protocol servers activated on each edge are imported as server communication profiles. If multiple edges in the same network zone have the same protocol server activated with the same configuration, a single server communication profile is declared for all edges. In this case the Edges field of the server communication profile lists the edge server titles as declared in the SecureTransport server.

A server communication profile is considered a duplicate when the following configuration is identical:

l The exchange protocol

l The exchange port

l Whether SSL/TLS is enabled, and if enabled:

o The client authentication mode

o The certificate used to secure the connection is the same in terms of content


l FIPS1 transfer mode

If any of these settings differs, separate server communication profiles are imported in the static configuration of SecureTransport. However, server communication profiles can be identical across network zones, in which case they are imported separately in each network zone.

See SecureTransport network zones on page 250 for more information.

PeSIT servicesIf PeSIT services are activated on SecureTransport, client communication profiles — corresponding to each SecureTransport server communication profile — are created in Central Governance during registration. The following information is retrieved from the server communication profiles:

l The network protocol.

l The PeSIT login which, as for the server communication profile, represents the SecureTransport product name.

l If SSL is activated, the SSL certificate to be used when SecureTransport is client. The certificate must have both server and client authentication key usage extensions to be usable as both the client and server certificate.

l FIPS mode.

If there is no server communication profile created in the private network zone during registration, no client communication profile is created.

The generated client communication profiles can be used in flows. However, you can create other client communication profiles. See PeSIT client communication profile on page 364.

PrerequisitesBefore registering SecureTransport, make sure the configuration is correct for transferring files via preferred protocols. This includes services, ports, SSL certificates for services and protocol-specific configuration.

After registering, if you need to change the SecureTransport configuration, change it first on SecureTransport and then make parallel changes for the SecureTransport in the Central Governance user interface.

Central Governance and SecureTransport must be configured and running for SecureTransport to register successfully. The SecureTransport Transaction Manager must be running; SecureTransport Edge, if installed, must be configured correctly.

See the SecureTransport user documentation for more information about configuring SecureTransport properly for file transfers.

1Federal Information Processing Standards (FIPS) have been developed by the U.S. government. FIPS describes document processing, cryptographic algorithms and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with the agencies. Your user license for this software supports FIPS-compliant implementations of certain cryptographic algorithms or IAIK implementations of those algorithms. Also see IAIK in the glossary. For more information about FIPS, see http://www.itl.nist.gov/fipspubs/.



The following steps must be completed in the SecureTransport administration user interface.

FirewallIn order to register multiple SecureTransports with Central Governance, where each ST uses a different network, the SecureTransports networks must be able to communicate with one another. If they cannot communicate, SecureTransport registrations fail after the first ST registration.

Network zonesNetwork zones and streaming configuration between the SecureTransport server and edges must be defined in SecureTransport Administration before starting the registration process. In Central Governance the list of edge node addresses is set in the Hosts field of the network zone. The FQDN1 is set by default to the first edge node address. Registration fails when the definition of a network zone is invalid on SecureTransport.

Administrator account 1. Make sure the SecureTransport administrator can log on using client certificates.

a. In Setup > Admin Settings, set client certificates to optional.

b. Accept certificates issued by any trusted issuer.

2. Make sure you have an administrator user with a Master Administrator role in Accounts > Administrators.

See Registering SecureTransport in Central Governance in the SecureTransport Administrator Guide.

Static configurationStatic configuration must be setup and started on SecureTransport. Central Governance retrieves it in the registration process.

1. Configure, enable and start the server protocols to be exposed in Central Governance at Operations > Server Control.

2. Specify the Client Certificate Authentication and SSL Encryption. Determine whether client certificate authentication is optional or mandatory depending on your security policy.

l For both SecureTransport 5.3.1 and 5.3.3 these settings are available at Access > Secure Socket Layer.

l For SecureTransport 5.3.5 you can set the SSL Encryption in Access > Secure Socket Layer and the Client Certificate Authentication in Authentication > Login settings once you enable the use of a certificate in the end-user log-in options.

3. If applicable, configure the SSL certificates for use by server protocols supporting a secure connections. Generate or import certificates referenced in the SSL Key Alias fields.




4. Central Governance retrieves the static configuration for FTPS during the registration process. Set the Base Port, Number of Ports and Port End under FTP Passive Mode at Setup > FTP Settings in SecureTransport.

Central Governance configuration in SecureTransportThe parameters for connecting SecureTransport and Central Governance are specified on the Central Governance page at Setup > Central Governance in the SecureTransport administration user interface. The Central Governance administrator must provide many of the field values to the SecureTransport administrator. Many of the values are set on the configuration page in Central Governance. The SecureTransport fields are:

Host

Must contain the same IP address or FQDN1 used on the configuration page in Central Governance. Registration fails unless the same value is used on both sides.

Port

Port of the Central Governance agent as entered in the Agent section on the configuration page in Central Governance. The default port is 5701.

Name

Name of the Central Governance agent as entered in the Agent section on the configuration page in Central Governance.

Shared Secret

The shared secret set up on the configuration page in Central Governance for products to use during registration.

Product Identifier

Central Governance uses this value to uniquely identify the instance or cluster of SecureTransport being registered.

Administrator Name

The name of the administrator user account for Central Governance to use for logging on to the SecureTransport Administration Tool.

Local Bind Address

The IP address or FQDN of the computer running SecureTransport.

Local Bind Port

The port used by the Central Governance agent to listen for connections.

Account Home Folder Prefix

Base home folder for accounts created by Central Governance.




Real User (Windows only)

If the the account home folder prefix is on a shared network; specify a real user who has access to it. You must specify the real user in a password vault file.

For more information, see the "Add a user to a password vault" topic in the SecureTransport Administrator Guide.

UID (Unix and Linux only)

UID1 for accounts created by Central Governance.

GID

GID2 for accounts created by Central Governance.

Failed login attempts before account is locked

The number of times a user can attempt to log on with invalid credentials before being locked out. This field is optional.

Expire password on account creation

When enabled users must change their passwords after logging on the first time.

For more information see the Central Governance configuration topic in the SecureTransport Administrator Guide for the configuration to complete in SecureTransport.

Registration processThe following graphic illustrates the SecureTransport registration process with Central Governance. The process begins when the Central Governance configuration is saved in SecureTransport. The graphic shows what happens next.

1A user ID (UID) is a unique positive integer assigned by a Unix-like operating system to each user. Each user is identified to the system by its UID, and user names are generally used only as an interface for humans.2group ID



Use the numbers in the graphic to correlate with the text describing each phase.

1. Auto-discovery registrationThe SecureTransport agent connects over a pre-shared channel to the agent in Central Governance. The registration request includes the name, host name, operating system and version of the SecureTransport.


2. Certificate exchangeThe Central Governance governance certificate authority generates and sends to SecureTransport an SSL certificate for securing connections between the two products. To establish mutual authentication, Central Governance also sends the governance certificate authority as a trusted authority. These enables the SecureTransport administrator user to have a secure connection.

Once SecureTransport has the certificates, it connects to Central Governance on the secured communications port using the Central Governance certificate.


All data connections between SecureTransport and Central Governance are mutually authenticated on the same port, via SecureTransport RESTful1 APIs. For instance, Central Governance pushes flow configurations over the mutually authenticated channel using the HTTP SET method of the RESTful APIs. Deployment of flows by Central Governance to SecureTransport succeeds even if the SecureTransport Agent is unavailable.

When this certificate expires, Central Governance renews it and sends it to SecureTransport.

3. SecureTransport static configurationCentral Governance receives the current configuration of SecureTransport. This includes:

l Server communication profiles corresponding to the activated and running protocol servers on SecureTransport.

l Network zone definition and server communication profiles corresponding to the activated and running protocol servers on SecureTransport Edge servers, if any.

l Certificates for the SSL certificates used by the servers supporting secured connections. Only the public key of the SSL certificate is retrieved along with the chain of certificate authorities.

4. Visibility configurationCentral Governance configures SecureTransport to use its Visibility service, which is an embedded instance of Axway Sentinel. The following SecureTransport properties are changed during registration.

Sentinel

Property Value

Host <Central Governance host name>

Port Visibility port (default 1305)

1RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE) web browsers use to retrieve web pages and to send data to remote servers. Representational State Transfer (REST) interfaces usually involve collections of resources with identifiers. For example, /people/paul, which can be operated upon using standard verbs, such as DELETE /people/paul.


Overflow file

Property Value

Name sentinel-overflow.db

Path var/run/

Size 5 MB

Warning threshold 90

The following properties are not changed:

l Send Heartbeat to Axway Sentinel Every

l Events (Available Event States, Event States to Send)

l When Overflow File Exceeds Maximum Size.

Registration approvalYou can configure Central Governance to require approval when SecureTransport 5.3.3 or higher attempts to register.

Configure registration approvalYou can enable registration approval using the configure on page 85 mode. See Configuration and startup on page 52 for details.

Approve a registration 1. Configure SecureTransport to register with Central Governance. In the Central

GovernanceProduct list page, the SecureTransport status becomes Ready to register.

2. Access the Transfer CFT details page and click Approve registration. The user must have appropriate privileges to approve the registration.

Reject a SecureTransport registration You can reject a SecureTransport that is in the Ready to register status by removing it from Central Governance.


Registration approval resultsRegistration is successful when SecureTransport is reported as Started on the Central GovernanceProduct List page:

If a problem occurs during registration, Transfer CFT is registered with an error. See SecureTransport registration troubleshooting on page 196 for information on registration errors.

Registration resultsRegistration is successful when the SecureTransport status is Started on the Central Governance Product List page.

SecureTransport creates the following configurations for use in Central Governance:

l CentralGovernanceApplication - An application of type AdvancedRouting to be used in all subscriptions.

l CentralGovernanceRouteTemplate – A route package template to be used for all routes of AdvanceRouting type.

See the advanced routing topic in the SecureTransport Administrator Guide for more information.

If after registering the product does not appear on the Product List page or has a registered in error status, see SecureTransport registration troubleshooting on page 196.

Status monitoringCentral Governance monitors the status of registered SecureTransports through their agents. SecureTransport has a status of started in Central Governance when the SecureTransport agent communicates successfully with the Central Governance agent. Even if SecureTransport is not running, the status is started in Central Governance as long the agents on both sides can communicate. If communication between agents breaks, the status of SecureTransport is unreachable on the Product List page in Central Governance.

Detect updated versionWhen SecureTransport is updated outside of Central Governance, Central Governance automatically detects the new version when SecureTransport is started.

Limitation

Prior to starting an upgrade from SecureTransport, copy the cgmonitor.sh script to <ST_install_directory>/central-governance/scripts and use createSecureTransport.umas as a parameter to run the script.

cgmonitor.sh

#!/bin/bash

#run script as: cgmonitor.sh <SecureTransport install directory>/central-governance/scripts/createSecureTransport.umas

#example: cgmonitor.sh /opt/TMWD/SecureTransport/central-governance/scripts/createSecureTransport.umas

FILE=$1

while [ ! -f $FILE ];

do

echo -n "."

sleep 2

done

echo

echo "File $FILE appeared. Deleting."

rm $FILE

Remove and re-registerThe best practice for removing a registered SecureTransport is to first make sure the SecureTransport status is not in unreachable status in Central Governance. Once you remove the product, the Central Governance configuration in SecureTransport becomes disabled. You then can enable the configuration in SecureTransport to re-register the product.

See Remove products on page 212 for information about removing registered products from Central Governance.

SecureTransport registration troubleshootingThe following are guidelines for troubleshooting SecureTransport registration.

SecureTransport does not display in UISecureTransport has registered and is running, but is not listed in the Central Governance user interface. To ensure the product has registered properly:


l Verify the Central Governance host matches in SecureTransport. If Central Governance uses an IP address as its host value, use the IP address in SecureTransport. If Central Governance uses an FQDN1 as its host value, use the FQDN in SecureTransport.

l On the computer running SecureTransport, verify Central Governance is reachable at the IP address or FQDN specified in SecureTransport.

l Check the Central Governance logs. If the SecureTransport does not appear, typically it was unable to contact Central Governance. This can occur when:

o The Central Governance shared secret is incorrect in SecureTransport. Check the SecureTransport logs for a shared secret error.

o The administrator account does not exist in SecureTransport or has an incorrect level of access.

o The administrator account cannot connect using the certificate. The following option must be enabled in SecureTransport: Enable administrator login using client certificate.

SecureTransport registered in errorSecureTransport is started and has a "registered in error" status:



l Review the error message, which displays as a tooltip in Central Governance, for the cause. Often it is an issue in retrieving configuration. For example, if the SecureTransport Transaction Manager is stopped, Central Governance cannot retrieve configuration.

Next stepsIf registration fails:

1. Remove SecureTransport from Central Governance by going to the Product List page and removing it.

2. Fix the cause of the failed registration.

3. Enable Central Governance configuration in SecureTransport to start the registration process again.

Gateway registrationThe following topics describe the tasks to register Gateway in Central Governance.



PrerequisitesCentral Governance manages Gateway 6.17.1 and higher. Central Governance connectivity is setup option during the Gateway installations or through Installer configure mode in the dedicated Central Governance dialogs.


Network zonesYou must configure Gateway's network zones before starting the registration process. A network zone corresponds to a Secure Relay instance. Configure and set the Secure Relay access policy for each protocol accordingly in Gateway prior to registering the Gateway in Central Governance.

Registration processGateway is ready to register with Central Governance:

l When you install Gateway and you select the option to activate Central Governance at the end of the installation process.

l When you select the option to activate Central Governance after upgrading Gateway at the end of the reconfiguration process.

To register Gateway in Central Governance do one of the following depending on the Gateway status:

l If the Gateway agent is stopped, start the agent from the <Gateway install directory>/run_time/agent folder using the startup command. This also automatically initiates the registration command.

o UNIX: startup.sh

o Windows: startup.bat

l If the Gateway agent is already started, from <Gateway install directory>/run_time/agent folder run the following:

o UNIX: register.sh

o Windows: register.bat

Note To check if Gateway agent is running call the status.sh/status.bat script from <Gateway>/run_time/agent folder. Remember that after the Gateway installation operation completes, the agent is down.

See the Gateway Installation Guide for details on registering Gateway with Central Governance.


The following diagram illustrates the Gateway registration process with Central Governance.

1. Auto-discovery registrationThe Gateway agent connects over a pre-shared channel to the agent in Central Governance. The registration request includes the name, host name, operating system and version of Gateway.


Note When the certificate expires, Central Governance renews it and sends it to Gateway.

2. Static Gateway configurationThe following describes how the static configuration is imported when you register Gateway. See the Gateway user documentation for more details about the Gateway configuration.

PeSIT, FTP, HTTPA PeSIT, FTP, or HTTP server communication profile is created in Central Governance for each complete PeSIT, FTP, or HTTP configuration declared in the Gateway server's static configuration. In addition, all of the server’s public certificates from a complete configuration are imported to Central Governance, including certificate chains when necessary.

A complete PeSIT, FTP, or HTTP configuration in Gateway server contains:

l PeSIT, FTP, or HTTP port declared in Gateway static configuration (required).

l Network profile objects created for each PeSIT port declared in the static configuration (required).

l TLS profile object referring a server certificate and linked to a network profile object (optional).

l Server certificate or certificate chain referred by the TLS profile object (optional).


A complete PeSIT, FTP, or HTTP configuration is one of the following:

l PeSIT, FTP, or HTTP port in static configuration and attached network profile object

l PeSIT, FTP, or HTTP port in static configuration and attached network profile object and TLS profile object referred by the network profile and TLS certificate or complete certificate chain referred by the TLS profile

Incomplete PeSIT, FTP, or HTTP configurations on the Gateway server are not imported to Central Governance. Moreover, the port configuration is overwritten with the Central Governance definition, which consequently removes incomplete entries.

SFTPAn SFTP server communication profile is created in Central Governance for each complete SFTP configuration declared in the Gateway server. In addition, the public parts of the server private keys are also imported in Central Governance.

A complete SFTP configuration in Gateway server contains:

l An SFTP port declared in Gateway static configuration.

l Network profiles created for each SFTP port declared in the static configuration.

l SSH profile objects referring server private keys created and linked to network profiles.

l Server private keys referred by the SSH profiles imported in the Gateway server.

Incomplete SFTP configurations in Gateway server are not imported to Central Governance. Moreover, the port configuration is overwritten with the Central Governance definition, which consequently removes incomplete entries.

3. Visibility configurationCentral Governance configures Gateway to use its Visibility service, which is an embedded instance of Axway Sentinel. The following Gateway properties are modified during registration.

Sentinel

Property Value

Host <Central Governance host name>

Port Visibility port (default 1305)

The following properties are not changed:

l Log filter

l Transfer filter giving level of events sent to Sentinel

Registration approvalYou can configure Central Governance to require approval when a product attempts to register. In this case, the product status in the Product list is set to Ready to register. A user with the appropriate privileges can approve the registration from the Product details page.

Note The registration approval option is not available for all versions of all supported products.

Registration resultsRegistration is successful when one of the following statuses is reported on the Central Governance Product List page:

l Started — Registration succeeded and Gateway is running

l Stopped — Registration succeeded and Gateway is not running

Note The Gateway access management settings are not changed during the registration process.

If a problem occurs during registration, Gateway is registered with an error. See Gateway registration troubleshooting on page 202 for information on registration errors.

Status monitoringCentral Governance monitors the status of registered Gateways. Gateway server status can be seen in Central Governance when the Gateway agent communicates successfully with the Central Governance agent. If communication between agents breaks, the status of Gateway is unreachable on the Product List page in Central Governance.

Remove and re-registerThe best practice for removing a registered Gateway is to first make sure the Gateway status is not in unreachable status in Central Governance. You can then start the Gateway registration by executing the command:

Windows

<Gateway install directory>/runtime/agent/register.bat

Unix

<Gateway install directory>/runtime/agent/register.sh

See Remove products on page 212 for information about removing registered products from Central Governance.

Note The Gateway agent must already be running in order to run the register.bat/register.sh script. If the agent is stopped and Gateway is not registered in Central Governance, starting the agent automatically initiates the registration process.

Gateway registration troubleshootingThe following are guidelines for troubleshooting Gateway registration.

Gateway does not display in UIGateway has registered and is running, but is not listed in the Central Governance user interface. To ensure that Gateway has registered properly:


l Verify the Central Governance IP address or FQDN1 you entered in Gateway.

l On the computer running Gateway, verify Central Governance is reachable at the IP address or FQDN specified in Gateway.

l Check the Central Governance logs. If the Gateway does not appear, typically it was unable to contact Central Governance. This can occur when the Central Governance shared secret is incorrect in Gateway.

l Check the Gateway logs for a shared secret error.

l Check the following Gateway logs for generic errors:

o <Gateway install directory>/run_time/agent/logs/uma.log

o <Gateway install directory>/run_time/agent/runtime/%node%/uma/logs/provider.log

o <Gateway install directory>/Gateway/run_time/agent/startup.log

Gateway registered in errorGateway is started and has a registered in error status:



l Check whether the shared secret provided by the Central Governance administrator matches the shared secret Gateway submitted when registering.

l Review the error message, which displays as a tooltip in Central Governance, for the cause. Often it is an issue in retrieving configuration.

Next stepsIf registration fails:

1. Remove Gateway from Central Governance on the Product List page.

2. Fix the cause of the failed registration.

3. Manually start the Gateway registration by executing the command:

Windows

<Gateway install directory>/runtime/agent/register.bat

Unix

<Gateway install directory>\runtime\agent\register.sh

Note The Gateway agent must be running to execute the register script. To check the agent status execute the command:

Windows

<Gateway install directory>/runtime/agent/status.bat

Unix

<Gateway install directory>\runtime\agent\status.sh

10 Product updates

Central Governance can apply updates remotely to products that have been registered successfully. Updates are files containing service packs, patches and version upgrades for products.

In this version of Central Governance, single instances of Transfer CFTs 3.1.3 and later are supported for updating remotely. The Transfer CFTs can be running on supported operating systems except z/OS1 and IBM i2.

You cannot use the product update user interface to remotely update Transfer CFTs running in clusters of multiple nodes.

Update summary and workflowThe following summarizes the product update process and provides the workflow for updating products. A system engineer or technician responsible for installing, configuring and maintaining Central Governance can update products.

SummaryCentral Governance maintains a repository to store uploaded update files at:

[install directory]\runtime\com.axway.nodes.ume_[variable]\data\updateRepository

Access the repository only through the user interface. Do not access the directory.

Central Governance manages the updating process from start to finish. Once you select an update and the products to apply it, Central Governance sends the update to the products, which shut down, start their local installers in update mode, apply the update, and restart.

The Product List page lists all products registered in Central Governance. The Version column reports the versions of the products. After applying updates, values in the column change to reflect that service packs, patches or version upgrades have been installed.

You cannot uninstall updates remotely; you must uninstall at the product level. You also cannot remove update files from the Central Governance update repository.

1z/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390.2IBM i is an EBCDIC-based operating system that runs on IBM Power Systems and on IBM PureSystems. The name, introduced in 2008, is the current evolution of the operating system. IBM i, formerly named i5/OS, originally was named OS/400 when introduced with the AS/400 computer system in 1988.


10 Product updates

Workflow 1. Download an update file from the Axway Support support website at

https://support.axway.com. Save the file in a file system Central Governance can access.

2. Select Products > Updates in the Central Governance user interface. Upload the file to the update repository. See Upload and view updates on page 205 for details.

3. On the Product List page, click an update to apply it to one or more products. See Apply an update to a product on page 205 for details.

Manage product updatesUse the following procedures to manage product updates on the Update List page. You can:

l View a list of uploaded update files

l Upload update files downloaded from Axway Support

l Apply updates to products

Note You require appropriate rights to View, Upload, and Remove updates.

PrerequisitesYou must download service packs, patches or version upgrade files for products from the Axway Support support website before you can upload files to the Central Governance update repository. Files you want to add to the repository must be on a file system accessible to Central Governance.

Upload and view updates 1. Select Products > Updates to open the Update List page. The page lists all updates in the

Central Governance repository.

2. Click Upload file and select the file you want to upload to the repository. Central Governance displays a message to confirm a successful upload.

Repeat the steps to upload more updates.

Apply an update to a product 1. Select Products > Updates to open the Update List page. The page lists all updates in the

Central Governance update repository.

2. Click the name of an update to open a details page. Review the information to confirm you want to apply the update to products.



10 Product updates

3. In that same Update details page, click Update products, in the right pane, to open the Update Products dialog. The dialog lists eligible products to apply the update.

4. Select one or more products and click Update products. Central Governance displays a success or failure status.

5. Once you have applied updates to products, you can do the following to monitor progress or confirm changes:

l Select Administration > Deployments > Updates and review the Status, Target and Item columns. Place the cursor over the status message to display the sequence of the update process.

l Select Products on the toolbar and review the Version column for the products.

A status of Updated on the Deployment List page means the update succeeded.

If an update failed, see the next topic for guidelines to resolve.

Remove an update from the list 1. Select Products > Updates to open the Update List page. This page lists all of the updates in

the Central Governance repository.

2. Select the update files in the repository that you want to remove. You may remove one or several update files.

3. Click the Remove button. Central Governance displays a message to confirm the action.

4. Click to confirm the removal, or Cancel to stop the remove process.

Note The Remove button does not display if you do not have Delete privileges.

Troubleshoot product updatesOnce you launch an update, Central Governance tries to apply it to the selected products. Go to Administration > Deployments > Updates to view update statuses. Updated indicates an update was applied successfully. Updated in error and Uploaded in error indicate updates failed to install.

An update failure can be due to any number of conditions on the product server. Select the failed update on the Updates tab of the Deployment List page and click Retry. If the update fails again, troubleshoot the issue on the computer where the product is installed. Check the local installer and product logs for failure clues. If necessary, apply the update to the product locally.

Once the product has been updated successfully by retrying in Central Governance or resolving locally, check the Product List page to confirm the correct version is installed.


11 Product operations

The Product List page enables you to view and perform actions on registered products. The page shows all products or only those meeting your filter criteria. You can click the name of a product to display its details page and to view or change the configuration of a product.

Product statuses and operationsYou can view the status of registered products and perform operations on them on the Product List page.

StatusesThe following statuses are displayed. Some special statuses apply only to products running in a cluster of multiple nodes.

Status Product Description

Registering l Transfer CFT

l SecureTransport

l Gateway

Displayed when the system is registering with Central Governance.

Registered in error

l Transfer CFT

l SecureTransport

l Gateway

Displayed when the system failed to register with Central Governance.

Ready to register

l Transfer CFT

l SecureTransport

l Gateway

Displayed when the product connects to Central Governance for the first time and Registration approval is enabled. The product must be approved from the product detail page before the registration process starts.

In progress l Transfer CFT Product cluster only: At least one node is starting and one node is stopping.



Status Product Description

Started l Transfer CFT

l SecureTransport

l Gateway

Displayed when the system has started successfully.

If a product cluster: All nodes are started.

Starting l Transfer CFT

l Gateway

Displayed from the time a start command occurs to the time the system returns a status, or until a timeout.

If a product cluster: At least one node is starting.

Partially started

l Transfer CFT Product cluster only: At least one node is stopped and at least one node is started.

Stopped l Transfer CFT

l Gateway

Displayed when the system has stopped successfully.

If a product cluster: Indicates all nodes are stopped.

Stopped in error

l Transfer CFT

l Gateway

Displayed for a system in an abnormal state when it failed to stop or crashed. This status is always associated with an error message.

If a product cluster: At least one node is stopped in error.

Stopping l Transfer CFT

l Gateway

Displayed from the time a stop command occurs to the time the system returns a status, or until a timeout.

If a product cluster: At least one node is stopping.

Unreachable l Transfer CFT

l SecureTransport

l Gateway

Displayed when Central Governance cannot get the status of the system. This can occur if network issues prevent communication. This status is always associated with an error message.

OperationsYou can perform the following operations on products The user interface only allows you to perform operations compatible with the product status.

Note Central Governance cannot start or stop registered SecureTransports.

Operation Description

Start Starts the product.

Stop Stops the product normally. A normal stop waits for transfers to complete and then stops the product.



Operation Description

Quick stop A quick stop places all transfers in progress in ready status and then stops the product. Transfers resume when the product is restarted.

Force stop A force stop aborts the transfers in progress and then stops the product. When the system is restarted, pending transfers are resumed, but aborted transfers remain aborted.

Restart Restarts a product that is started.

Remove Removes a product from Central Governance. This can be performed on a system that is in any state, except registering. It removes all information related to the system from Central Governance, but has no effect on the system's status.

Transfer CFT status monitoringCentral Governance monitors the status of registered Transfer CFTs through heartbeats.

Transfer CFT and its Copilot send heartbeats via the persistent mutually authenticated connection with Central Governance. The default interval for both to send heartbeats is every 10 minutes.

Transfer CFT has a status of unreachable in the Central Governance user interface when:

l Neither Transfer CFT or its Copilot have sent heartbeats for longer than the specified interval.

or

l Transfer CFT sends a heartbeat that reports a stopped status for its Copilot.

SecureTransport status monitoringCentral Governance monitors the status of registered SecureTransports by monitoring the agents of the products.

Gateway status monitoringCentral Governance monitors the status of registered Gateways by having the agent monitor the product.

Gateway supports active/passive cluster. In this context only the agent of the active Gateway is monitored.



Start and stop productsUse the following procedures to start and stop products on the Product List page. Click Products on the top toolbar to open the page.

Start products 1. Select the products to start.

2. Click Start. When started successfully, the Status column displays Started.

Stop products 1. Select the products to stop.

2. Click Stop. When stopped, the Status column displays Stopped.

View or edit product detailsThe product details page has more information for the product than the Product List page. If the details page has a Nodes section, the product is running in a cluster of multiple nodes.

On the details page you can perform start and stop operations on the product, or click Edit to change details. For example, you can edit:

l The groups1 associated with the product. You can add multiple products to the same group for mass operations or for fine-grained access control. See Groups on page 282 for more information.

l Contact information.

l Other details, such as adding tags2, which are useful when performing a search.

The details page has links to:

l Edit the product configuration.

l Approve a registration (depending on the CG configuration).

l Remove the product from Central Governance. See Remove products on page 212.

For Transfer CFT on the details page you can also:

l Review the product log. See Product logs on page 211.

l Manage Transfer CFT legacy flows. See Transfer CFT legacy flows on page 457.

1Groups enable you to organize and manage related products.2Keywords for classifying objects like applications, products, flows, partners.



Product logsUse logs to monitor usage or diagnose problems for registered products. You can view the log for only one product at a time.

l See the Transfer CFT error messages documentation for the messages Transfer CFT generates and corrective actions when applicable.

l Refer to the Messages and codes section in the Gateway 6.17 User Guide, available at support.axway.com, for the messages Gateway generates and associated explanations and actions.

View log 1. Click the name of a product on the Product List page to open its details page.

2. Click Logs on the right side of the page.

The log page is displayed where you can:

l Click Refresh anytime to update the log entries.

l Sort the entries by newest or oldest.

l Filter the entries, saving filters for future use.

The following describes the log table columns.

Date/time


Level

Level of the log entry. Levels, from highest to lowest verbosity, are INFO, WARNING, ERROR, FATAL.

Code

Code associated with the log message.

Message

Actual log message.

Filter logYou can filter a log by one or multiple conditions. The filters you add are saved until deleted or the browser cache is cleared. You can, for example, filter by level, leave the page and return, and the displayed log entries are filtered by level.

Click Filter and select a filter type to add. You can add multiple filters.


https://docs.axway.com/u/documentation/redirect.htm?help=cft_ug&version=3.2.2&cshid=MAPID_error_messages



Date/time

You can filter log entries by age in hours or generated within a date range.

Level

You can filter log entries by severity. This filtering provides cumulative verbosity. If you filter by Info level, Info messages and all message levels above the Info level are displayed. If you filter by Fatal level, only fatal log entries are displayed.

Pattern

You can filter log entries by full or partial codes or messages or both. This filtering is case sensitive.

Added filters are displayed at the top of the page. Click a filter to change it. Click the appropriate X icon to delete a single filter or to clear all filters.

Remove productsRemoving products means the systems no longer are registered in Central Governance and managed by it.

GuidelinesRemoving a product can affect flows. Before removing, check for defined flows that use the product. See General concepts about flows on page 295.

Transfer CFT Confirm that Transfer CFT and its Copilot are stopped. Both must be stopped before removing Transfer CFT from Central Governance. You can stop Transfer CFT from Central Governance, but you must stop Copilot separately. See Start and stop products on page 210.

SecureTransport The best practice for removing a registered SecureTransport is to first make sure the SecureTransport status is not in unreachable status in Central Governance. Once you remove the product, the Central Governance configuration in SecureTransport becomes disabled. You then can enable the configuration in SecureTransport to re-register the product.

GatewayBefore removing a Gateway, make sure that the registered Gateway is not in the unreachable status in Central Governance.



After removing the Gateway, the static configuration and flow configuration deployed on that instance of Gateway remain active. Removal does not affect its performance. However, all future changes must be performed on Gateway.

Steps 1. Select the Products tab.

2. Select the product to remove.

3. Click Remove.

If the removed product is used in flows, a confirmation message is displayed. If you confirm the removal, the product is removed from the flows in Central Governance, and the status of the flows is recalculated. You must redeploy the flows manually.


12 Transfer CFT configuration

The following topics describe configuring Transfer CFTs managed by Central Governance.

When Transfer CFT registers with Central Governance, it has a default configuration that enables it to operate without changes. However, your needs might require changing the default settings. Central Governance uses the Copilot WebService to deploy configuration changes to Transfer CFT.

Change configurationUse this procedure to change, save and deploy a configuration for Transfer CFT.

1. Select the Products tab to view available products.

2. Click the product name to open its details page. On this page you can click Edit and change details about the product, including groups tags, description and contact information. However, you must go to the next step to change the product configuration.

3. Click Configuration to open the Configuration page and click Edit to open edit mode.

4. In the sub-menu panel on the left, select the configuration section to edit.

5. Change the configuration as needed.

6. Click Save.

If you modify this Transfer CFT configuration setting and it is used in a flow, a warning message indicates that the modification has an impact on one or more flows. If you confirm the configuration change, the affected flows are recalculated to reflect the new status. See Configuration change management.

7. Click Deploy when you are ready to push the configuration change to Transfer CFT. Then click a deployment option. You can:

l Deploy configuration to deploy the configuration and restart the Transfer CFT for the changes to become effective on it.

l Deploy, no restart to deploy the configuration, but not restart Transfer CFT. You must restart the product later for the changes to become effective. After the configuration is deployed, the status message at the top of the Configuration page reminds that restarting is required. A restart reminder also is displayed for the product in the Configurations list on the Deployment List page at Administration > Deployments.



You can use this option on Transfer CFTs running on z/OS1 and IBM i2 computers when copilot.misc.cftstart.enable is set to false to disable Copilot

operations such as start and stop.

8. If you selected the Deploy, no restart option, go to the Product List page and restart the product when you are ready. Select Products on the top toolbar to open the page.

Configuration change managementCentral Governance implements a series of configuration-change checks that display messages if certain changes occur in a configuration that is used in a flow. The following actions impact related flows:

l Removing

o Protocol

o Network protocol

l Disabling

o Protocol

o Network protocol

l Modifying

o Protocol

o Protocol port

o FIPS

o PeSIT password

When removing a protocol or network, a warning message is triggered immediately if there is an impact on a flow. Otherwise, the notification occurs when you click to save the configuration.

NoteYou cannot use a non-deployed configuration in a flow. By extension, if you update a configuration (e.g., you change the port of a protocol in an existing configuration), the moment the configuration passes through the “Saved” state, it is removed from the flow and the flow itself changes to "Saved". Even if you immediately deploy the updated configuration, you will need to manually reload the configuration on the flow.




Configuration dictionaryThis section describes how you can configure Transfer CFT UCONF parameters that do not appear elsewhere in the Transfer CFT Configuration page.

Note This features is available for use with Transfer CFT 3.1.3 and higher.

OverviewWhen you modify and deploy changes in the Configuration Dictionary, Central Governance pushes the changes to the selected Transfer CFT.

FieldsThe Configuration Dictionary section displays the following fields when enabled.

l Enable: Specifies whether to enable the Configuration Dictionary.

l Filter: Filter by text entered in this field.

l Parameters:

o Deployment Status: Shows the parameter's deployment status.

o Name: Transfer CFT's name for the parameter.

o Type: Data type of the parameter.

o Value: Value of the parameter. Click RESET, displayed next to the parameter's editable field, to reset the default value.

The following parameters are not available for configuration:

l Certain parameters relating to Central Governance settings

l Parameters that have a UCONF flag value of: READ_ONLY, RUNTIME, EXPERIMENTAL, or OBSOLETE

Network configurationThis section describes how to manage Transfer CFT network resources.

OverviewThe network definition includes internal options for controlling connections, network environment settings, and general environment settings. When applicable, there are examples and tips that describe the effect on performance, the behavior for failed transfers, details about host name resolution, and so on.


Fields A network definition is comprised of the following fields. These are set by default, but can be changed.

ProtocolsProtocols are the access points to Transfer CFTs from the network. There is at least one protocol per Transfer CFT.

Only one interface can be managed in Central Governance.

For each network protocol, two protocol sections can be defined: one without security and one using the business certificate generated upon registration (SSL_DEFAULT). For each protocol section, a protocol object of type PeSIT is created on Transfer CFT; the ID is the concatenation of the network protocol identifier followed by _<Security level>. The security level is 1 when no security is used and 2 for SSL_DEFAULT. For instance, a protocol ID is UDT1_PESIT2 for a protocol relying on UDT network protocol and using the SSL_DEFAULT security profile.

Interface

Indicates the entity type through which connections can be established.

l Any: Receive incoming calls on all available addresses.

l Any IPv4 | Any IPv6: Use one of these options to define interfaces that can accept requests directed exclusively to all existing IPv4 addresses or IPv6 addresses, respectively.

l Address: The address value allows you to define a specific address for Transfer CFT communication. For example, if your host has several IP addresses, you may want to reserve a specific address for the Transfer CFT. To do this select Address, and then enter the address to use for communication. You can enter an IP address or a host name, which is mapped to the designated IP address. Once set, Transfer CFT only accepts requests intended for the defined address.

Protocol

Indicates whether the displayed network protocol is active.

An interface can be linked to up to three network protocol definitions, one for each of the following types: TCP1, pTCP2 and UDT3. Two of these, pTCP and UDT, are used specifically for file transfer acceleration (see About transfer acceleration on page 222).

Note Acceleration is supported on all Transfer CFT platforms except z/OS or IBM i.

1The Transmission Control Protocol (TCP), one of the core protocols of the Internet protocol suite (IP), is often called TCP/IP. TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer.2The parallel Transmission Control Protocol (pTCP) is an end-to-end transport layer protocol that supports striped connections.3The UDP-based Data Transfer Protocol (UDT) is a high performance data transfer protocol designed for transferring large volumetric data sets over high-speed wide-area networks.


To add a network protocol, click Add network protocol and select the type.

To disable a network protocol without losing the defined values, deselect the check-box that precedes the network protocol type (TCP, pTCP or UDT). Disabling deactivates that particular network type, but stores the values for future use.

You must link at least one network protocol to the interface to establish basic network communication.

To remove a network protocol, click X in the right margin.

NoteIf you modify this Transfer CFT configuration setting and it is used in a flow, a warning message indicates that the modification has an impact on one or more flows. If you confirm the configuration change, the affected flows are recalculated to reflect the new status. See Configuration change management.

Ports out

Define up to 16 comma-separated port ranges that can be used by Transfer CFT for outgoing calls, for example "5000-6000, 7251-8000". If you leave the field blank, the default value is used.

The possible impact on flows is detailed in Configuration change management on page 373.

Connections (conn.)

Indicates the maximum number of simultaneous connections that Transfer CFT can establish on a given network resource.

PeSIT / SSL

List of available security profiles or no security.

Port in

Indicates the local port for Transfer CFT.

This setting defines the ports where Transfer CFT is listening for connections, and is a mandatory parameter in Central Governance.


PeSIT password

Represents the password used in all flows where the current Transfer CFT is used and the exchange protocol is PeSIT. The default value is the one generated by Central Governance during flow deployment. The parameter accepts an empty value.

This setting must be deployed in order to be taken into account by flows in which the Transfer CFT is used.




GeneralMaximum simultaneous transfers

Indicates the maximum number of simultaneous connections Transfer CFT can have for a network resource.

You can use this parameter to optimize Transfer CFT bandwidth usage. For example, if Transfer CFT is being used as a relay or central connecting point, then you may want to set this parameter to a high value. Raising this value increases the CPU processing, disk I/O, and bandwidth consumption on the host machine, so check that the host machine has the necessary hardware capability.

Using a low value when Transfer CFT is acting as a relay can cause bottlenecks in the flow's execution. If Transfer CFT receives more transfer requests than authorized by this parameter value, the transfers are listed as described in Transfer list on page 237. These transfers are then acted on according to their priority, or when resources become available.

Additional conditions:

l The license for Transfer CFT might impose restrictions that lower the configurable value.

l The number of incoming and outgoing transfers is also defined at the transfer point level.

Disconnect timeout

Indicates the wait timeout for either a response to the protocol connection request, or to the transfer point connection, before disconnecting.

This parameter represents the timeout when waiting for a protocol request, which can be a connection or an interruption request.

At the protocol level, a connection request refers to the physical connection with the transfer point host. Once established, the transfer point Transfer CFT may not be responding. This could be due to the fact that the transfer point application is busy or has encountered an error.

An interruption request occurs if one of the Transfer CFT transfer points, for example CFT1, needs to interrupt the communication in response to a user action. The transfer point CFT1 can then use the time defined in the Disconnect timeout parameter for the network connection break. After this period of time, the originator of the abort request, CFT2, will initiate a network disconnect request.

If your Transfer CFT frequently communicates with transfer points that are slow to respond, for example due to heavy usage, you may want to increase the disconnect timeout value. Or, you may want to use a higher disconnect timeout value to allow abort requests from



Transfer CFT to have enough time to be correctly processed at the transfer point. Alternately, if you interact with highly responsive transfer points, you can use a lower value. In most cases, the default value of 60 seconds is sufficient.

Attempts to restart transfer

Indicates the maximum number of times Transfer CFT attempts to restart a transfer.

This requester mode parameter indicates the maximum number of attempts for a transfer. An attempt begins at the moment the physical connection is established with the remote site.

You can tune this value in combination with the Disconnect timeout parameter. For example, you can set a low disconnect timeout, but define a certain number of retries if the transfer cannot be performed. See PeSIT Tuning on page 221.

IPv6 mode

Indicates the IPv6 resolution for hostnames when Transfer CFT is acting as a client, server, both, or none.

This setting defines how Transfer CFT manages Internet addresses and hostname resolution, and is operating system dependent.

l Client: The host name used by Transfer CFT to connect to a host may refer to an IPv4 or an IPv6 address or a list of addresses of either type. If a name simultaneously refers to two different addresses, Transfer CFT will connect to the one available on the remote end.

l Server: The host name used by Transfer CFT to listen for incoming connections can refer to both types of addresses or to a list of addresses of either type. If the name resolution request returns a list of addresses Transfer CFT listens for the first entry in the list. The order of returned addresses is not necessarily in any particular order, and is operating system dependent.

l None: Because enabling IPv6 use for applications may have adverse effects if improperly configured, support for IPv6 is disabled by default. In this case, hostnames that are defined in the Transfer CFT configuration files are resolved only for IPv4 addresses. That said, you can directly enter IPv6 addresses in Transfer CFT configuration files, as the IPv6 mode parameter applies exclusively to hostname resolution.

We recommend None when unsure whether your operating system is set up for IPv6.

The operating system must support IPv4 and IPv6 (if used) addressing as defined in the POSIX Protocol Independent API specifications.

Keep alive between transfers

The client and server timeout settings represent separate idle connection parameters when Transfer CFT is acting as a client or a server.

Client

Interval in seconds to maintain an active session between transfer activity on the client.



Server

Interval in seconds to maintain an active session between transfer activity on the server.

pTCP See About transfer acceleration on page 222 for information about using pTCP.

Number of parallel connections

Indicates the number of simultaneous connections that can occur in parallel.

Packet size

Indicates the pTCP packet size in bytes.

Buffer size

Indicates the internal acceleration buffer size in megabytes. This value should be greater than the number of connections multiplied by packet size. The stored buffer size value should be rounded to at most 3 decimal places, with no trailing zeros.

For example, for 16 connections and 4000 bytes the value would be 0.062 MB, if you round up to the nearest 0.001 MB.

UDT There is one UDT instance per Transfer CFT.

See About transfer acceleration on page 222 for information about using UDT.

Buffer size

Indicates the internal acceleration buffer size.

PeSIT TuningThere is one PeSIT tuning instance per Transfer CFT.

Compression

Defines the use of file compression for Transfer CFT. Files can be compressed to reduce the size of the data that is transferred.

l Yes: Authorizes use of compression for sending or receiving a file, which is then negotiated between the source and target. This implies the source and target use the same type of compression. Selecting compression indicates one or multiple types of PeSIT compression are used, which might include horizontal or vertical compression or both.

With horizontal compression, data are compressed horizontally to identical consecutive characters in the same row.



With vertical compression, data are compressed vertically to identical consecutive characters in the same column.

With both, data are compressed horizontally and vertically.

l No: Do not use PeSIT file compression.

Consider using compression when the files are highly compressible, or if the network has an especially low bandwidth. Note that using compression leads to high CPU consumption.

Inactivity timeout

The network monitoring timeout, in seconds, excluding the protocol connection/disconnection break phase. The value 0 indicates an infinite amount of time.

For example, transfer points CFT1 and CFT2 are connected and multiple parallel transfers are occurring. If one transfer point, the local transfer point CFT1, does not receive an acknowledgement by the time indicated in the Inactivity timeout, it interrupts the connection with a diagnostic code indicating that the timeout was exceeded. This could be caused, for example, by high activity on the remote CFT2 transfer point.

You may want to adjust this parameter if you have a session that is open for an extended period of time.

The Inactivity timeout refers to the file protocol data connection that occurs after a PeSIT connection. This is not to be confused with the Disconnect timeout, which is a request during the actual PeSIT session.

Acknowledgement window size

Maximum number of synchronization points, without waiting for a response, that are authorized by the source/target. This value may be negotiated between Transfer CFTs or applications during the during connection phase.

The value 0 indicates that the synchronization point option is not used. The value 1 defines half-duplex transfers.

Data transferred between sync points

Indicate then internal size of data to transfer, in kilobytes, between two synchronization points. This value is negotiated with the transfer point timing. The value 0 indicates that there are no synchronization points.

About transfer accelerationTransfer acceleration is a feature of Transfer CFT that enables significantly faster transfer rates for large-file transfers, traveling long distances over high bandwidth networks.

Two technologies are used to optimize transfer acceleration:

l UDT: UDT is a transport protocol that Transfer CFT can use over high-speed networks. UDT uses UDP (User Datagram Protocol), a lower transport layer, for transferring bulk data.

l pTCP: Parallel TCP is an end-to-end transport layer protocol that offers increased performance by using multiple paths, or striped connections, to optimize connections.



Transfer acceleration is not supported on Transfer CFTs running on z/OS and IBM i computers.

You can use pTCP to overcome TCP/IP limitations on high bandwidth, high latency networks, and to improve end-to-end network performance. While TCP/IP extensions can be used to overcome the standard 64KB window limitation, the result is unevenly distributed. Additionally, traditional TCP/IP does not manage packet loss well.

Note pTCP can be implemented in a simple or multi-node architecture.

To decide if you would benefit from using pTCP, multiply your current bandwidth by latency to calculate your existing BDP. The maximum theoretical gain is BDP/64KB. Implementing transfer acceleration is of interest when the BDP is greater than 512KB.

The license key must include the transfer acceleration option.

Bandwidth allocationThis section describes bandwidth allocation configuration.

OverviewYou can use the bandwidth allocation fields to manage data rates and the network bandwidth used for incoming and outgoing data in your flows.

See Transfer CFT bandwidth allocation on page 337 for more details.

Fields The user interface indicates default values.

Enable

Enables or disables bandwidth allocation.

Global data rates

Specifies limits on the rates of incoming and outgoing data.

l Unlimited specifies there is no maximum rate for inbound or outbound communications.

l Limited allows setting maximums, in kilobytes per second, for the rates of incoming and outgoing data.

Priority

Additionally, you can specify the priority percentages for the high, medium and low service classes. The system rounds the total of percentages to 100. The system also sorts the percentages to ensure high has the highest percentage and low has the lowest percentage.



A service class defines network session parameters that control rate, borrowing and bandwidth pending the class. A service class percentage can be zero, but not less than zero. The default percentages for the service classes are high 80, medium 15 and low 5.

Transfer processingA transfer is a set of processes that result in the exchange of data between systems, where one system is the source and the other is the target. This type of data exchange between applications is a flow.

OverviewIn Central Governance, you can create and deploy flows, which are triggered at the system level.

Transfer CFT provides a complete processing workflow that includes transfer processing, pre- and post-processing scripts, error scripts, and acknowledgment script execution. For more information on defining these in your flow, see Source processing scripts on page 436 and Target processing scripts on page 452.

The transfer processing configuration fields help to define transfer operations. The following fields include information on the user executing the transfer, sending groups of files, running scripts during the flow, and other general processing options.

Multiple steps are required to define a flow. For more information, see:

l Composition, deployment, execution on page 295

l Flow lifecycle on page 298

l General concepts about flows on page 295


User for file access

Account used to read/write the files to be transferred.

l Transfer CFT system account - To read and write files, the Transfer CFT uses the same system account that launched the Transfer CFT.

l USERID variable - The user is set at runtime when performing a transfer. For example, the user is the one defined in the CFTUTIL utility SEND or RECV command. On the sender side, the system user who initiates the SEND is used to execute the end-of-transfer procedure by default. On the receiver side, the USERID is specified in the corresponding CFTRECV object. This gives the user referenced by the user ID the rights to execute end-of-transfer procedures.



If you elect USERID variable, you must define rights for the account on the Transfer CFT. To enable system users in Unix or Linux, use the CFTSU process and give special rights to the CFTSU executable. Log on as root and execute the following commands:

l chown root:root $CFTDIRINSTALL/bin/CFTSU

l chmod u+s $CFTDIRINSTALL/bin/CFTSU

User for script execution

Transfer CFT can execute scripts as the system user or on behalf of another user as defined by the USERID option.

This field is not supported on Transfer CFTs running on z/OS computers.

l Transfer CFT system account - Transfer CFT executes the script as the system user.

l USERID variable - Transfer CFT executes the script on behalf of another defined user, other than the system user.

For an unknown flow

Action to take when the flow is unknown.

Use the system default - The transfer is performed using the default flow identifier.

Reject request - No transfer occurs when the flow is unknown and an error code and message is returned in response to the CFTUTIL utility SEND and RECV commands.

Transmit files individually

Indicates whether the transmission of a group of files is done individually, file by file, or grouped when possible.

The method for transmitting the group of files depends on the operating systems of the Transfer CFTs involved in the flow, and their configurations.

l When necessary - When the source and target systems have the same operating system, you can send multiple files as an archive file.

l Always - Select this option when you are certain that the operating systems are different. In this case, the transfer always sends files individually for each file in the group. Note that when using the Always option, Transfer CFT transmits files individually even if the operating systems are the same.

See Transferring groups of files on page 325.

Select Always if uncertain about the transfer point platform. For example, a Windows system archives a group of files as a ZIP file, but a receiving UNIX transfer point expects the TAR file format. In this case, an error occurs on both sides.

When requesting all files

Action to perform if any one of the transfers fails.



Defines the desired behavior when a Transfer CFT requests all available files from another Transfer CFT.

l Stop on error - The file reception stops at the first error. For example, if there are 10 files to send and an error occurs while transferring the third file in the group, then the remaining files (4 through 10 in our example) are not transferred.

l Continue - When using this option, Transfer CFT continues with the request for the remaining files (4 through 10 in our example) even though it did not receive the third file.

When file exists

TargetDefines the target retry characteristics for the file renaming functionality when the file exists.

l Retry frequency - Delay in seconds between two retries to rename the file. If the file is not successfully renamed after the first delay, the time doubles for the next retry period.

l Maximum number of retries - Maximum number of retries.

Configure default scriptsThe following describes the types of processing scripts you can specify on the source and target.

When configuring default scripts you can specify an existing script on the Transfer CFT or upload a new script to it.

If you upload a script file, it is available on the Transfer CFT after the configuration is deployed successfully on it. The script is uploaded with the default path:

$(cft.runtime_dir)/conf/ws_upload

The new file overwrites an existing file if present.

Select None if a processing script is not needed.

SourceYou can specify for the transfer source:

l Post-processing script to run after a file is sent.

l Acknowledgment script to run after an acknowledgment is received for a sent file.

l Error script to run after an error occurs when sending a file.

l No script for one or more categories.

For more information, see Transfer CFT source fields in flows on page 423.



TargetYou can specify for the transfer target:

l Post-processing script to run after a file is received.

l Error script to run after an error occurs while a file is received on the target.

l No script for one or more categories.

For more information on defining targets, see Transfer CFT target fields in flows on page 442.

Folder monitoringTransfer CFT can monitor directories for files to transfer. You can specify the directories to monitor and set up conditions for identifying the files to transfer. Transfer CFT checks at intervals for transfer candidates in specified directories. You can define conditions for triggering SEND commands for qualifying files.

OverviewYou can specify directories for Transfer CFT to monitor for files to transfer. Files that meet specified conditions are submitted, or consumed, for transfer. Monitoring of a directory can include or exclude its sub-directories.

Transfer CFT tracks the size and date and time of the last change for each monitored file. If the state does not change within a specified interval, the file can be submitted for transfer.

A monitored directory is the scan directory or scan_dir. For each scan_dir there must be another directory for Transfer CFT to record the state data of each file. This directory is the work directory or work_dir.

For a submitted file, Transfer CFT issues a CFTUTIL SEND command with the flow and partner parameters (IDF and PART, respectively). After the command executes, the file is:

l Moved to a work_dir when Method = Move. A file can be renamed when moved.

or

l Kept in the monitored scan_dir when Method = File. The file is tracked as submitted through a MET file written to the scan_dir. Files can be resubmitted when changed.

See Move and File examples on page 230.

Work_dir and scan_dir cannot refer to the same directory.

Fields Enable

Specifies whether to enable directory monitoring.


You can specify one or multiple directories to monitor. Click Add folder monitoring to specify another directory. You can click the X icon to delete the configuration for an added folder.

Folder name

A friendly name for the directory to monitor. Only Central Governance uses this name; it is not deployed to Transfer CFT. Instead, Central Governance deploys folder monitoring indexes to Transfer CFT.

For example, the following monitored directories are defined in Central Governance: Folder A, Folder B, Folder C. Central Governance deploys the following parameters to Transfer CFT:

l folder_monitoring.enable = Yes

l folder_monitoring.folders = 1,2,3

l folder_monitoring.folders.1.<parameter_name>, where

<parameter_name> corresponds to parameters from Folder A


<parameter_name> corresponds to parameters from Folder B


<parameter_name> corresponds to parameters from Folder C

DirectoriesDirectory to scan

Path and name of the root directory to monitor. In Transfer CFT this is the scan_dir. The directory must exist before the configuration is effective on Transfer CFT.

Directory where files are tracked

Path and name of the directory where files are moved after being transferred or where meta-data tracking files are created for transferred files. In Transfer CFT this is the work_dir. Transfer CFT creates this directory on first use if it does not exist.

Transfer parametersFlow identifier

Identifier of the flow used in the transfer. The flow identifier must exist on Transfer CFT when files are submitted.

l Custom indicates a fixed flow identifier to use for all SEND commands.

l First sub-folder indicates the flow identifier is the name of the first directory sub-level in the directory to scan.


l Second sub-folder indicates the flow identifier is the name of the second directory sub-level in the directory to scan.

Partner

Partner who receives the file. The partner must exist on Transfer CFT when files are submitted.

l Custom indicates a fixed partner name to use for all SEND commands.

l First sub-folder indicates the partner name is the name of the first directory sub-level in the directory to scan.

l Second sub-folder indicates the partner name is the name of the second directory sub-level in the directory to scan.

ScanningScan sub-directories

Indicates whether to only scan the specified directory or also its sub-directories.

Number of files to scan

Maximum number of files to scan for submission per scanning interval.

l Unlimited indicates there is no limit on the number of files to scan.

l Limited indicates there is a maximum number of files to scan that you specify in the provided field.

Time between scans

Seconds between scans.

SubmissionTime before scanned files are submitted

Files that have not changed during this interval can be submitted. This prevents submitting files before they have been written fully to the monitored directory.

Method

Specifies handling of submitted files.

l Move indicates files are moved to a work directory (work_dir).

l File indicates files are kept in the scan directory (scan_dir) and tracked with a state file. Transfer CFT creates the *.met state file in the work directory.

You must not delete the file while folder monitoring is enabled.

Append timestamp to submitted files

When Method = Move, indicates whether to append the date and time to the moved file.



Resubmit changed files

When Method = File, indicates whether files kept in the scan directory can be resubmitted if they have changed.

File filtersInclude file template

Only files matching the specified pattern are monitored. For example, define *.txt to send only files with a TXT extension.

Exclude file template

Files matching this pattern are excluded. For example, use *old* to exclude files with old in the file names.

The cumulative effect of the two filtering examples is only TXT files without old in file names are submitted for transfer. For instance, invoice.txt is sent, but invoice-old.txt is ignored.

Minimum size

Minimum size of files that can be submitted.

l Unlimited indicates there is no minimum size for files.

l Limited indicates there is a minimum size for files that you specify in bytes in the provided field.

Maximum size

Maximum size of files that can be submitted.

l Unlimited indicates there is no maximum size for files.

l Limited indicates there is a maximum size for files that you specify in bytes in the provided field.

Move and File examplesThe following examples demonstrate folder monitoring when the selected method is Move or File.

Move

Field Value

Folder name Folder A

Directory to scan /dir_c/scan



Field Value

Directory where files are tracked /dir_c/work

Flow identifier (custom) FlowSendTextFiles

Partner (custom) MyPartner

Scan sub-directories Yes

Number of files to scan 2

Time between scans 60 seconds

Time before scanned files are submitted 5 seconds

Method Move

Append timestamp to submitted files Yes

Include file template *.txt

Exclude file template *old*

Minimum size 1 KB

Maximum size 100 KB

Given the directory and file structure as input:

/dir_c/scan/f1.txt 10KB

/dir_c/scan/f2.txt 10KB

/dir_c/scan/f1-old.txt 10KB

/dir_c/scan/f2-old.txt 10KB

/dir_c/scan/subfolder/f3.txt 50KB

/dir_c/scan/subfolder/f4.txt 150KB

Every 60 seconds, a maximum of 2 files are scanned. Submitted files are moved to /dir_c/work after being renamed.

First scan

CFTUTIL SEND part=MyPartner, idf=FlowSendTextFiles, fname=/dir_c/work/f1.20140515120155.txt

CFTUTIL SEND part=MyPartner, idf=FlowSendTextFiles, fname=/dir_c/work/f2.20140515120155.txt

/dir_c/work/f1.20140515120155.txt



/dir_c/work/f2.20140515120155.txt

Second scan

CFTUTIL SEND part=MyPartner, idf=FlowSendTextFiles, fname=/dir c/work/subfolder/f3.20140515120255.txt

/dir_c/work/subfolder/f3.20140515120255.txt

File

Field Value

Folder name Folder B

Directory to scan /dir_c/scan

Directory where files are tracked /dir_c/work

Flow identifier Second sub-folder

Partner First sub-folder

Method File

Given the directory and file structure as input:

/dir_c/scan/newyork/idf1/f1.txt

/dir_c/scan/newyork/idf2/f2.txt

/dir_c/scan/paris/idf3/f3.txt

/dir_c/scan/paris/idf3/f4.txt

The following SEND commands are issued:

CFTUTIL SEND part=newyork, idf=fl1, fname=/dir_c/scan/newyork/idf1/f1.txt

CFTUTIL SEND part=newyork, idf=fl2, fname=/dir_c/scan/newyork/idf2/f2.txt

CFTUTIL SEND part=paris, idf=fl3, fname=/dir_c/scan/paris/idf3/f3.txt

CFTUTIL SEND part=paris, idf=fl3, fname=/dir_c/scan/paris/idf3/f4.txt

Sent files are kept in the scan directory tree, and *.met files are created in the work directory for tracking purposes, following the same directory tree pattern:

/dir_c/work/newyork/idf1/f1.txt.met



/dir_c/work/newyork/idf2/f2.txt.met

/dir_c/work/paris/idf3/f3.txt.met

/dir_c/work/paris/idf3/f4.txt.met

CRONJOBsCRONJOBs in Transfer CFT are scheduled jobs for performing functions such as periodically scanning a directory for files to transfer, maintenance tasks and other operations.

OverviewThe CRONJOB definition includes execution scheduling and upload of the job to Transfer CFT. All CRONJOBs that Central Governance manages are attached automatically to the active CFTPARM1 via a dedicated CRONTAB named CGCRONTAB created at product registration.

Transfer CFT supports CRONJOBs on all supported operating systems.

The user interface for CRONJOBs within the Transfer CFT configuration page enables you to add, edit and remove CRONJOBs.

FieldsName

A unique name for the CRONJOB on the Transfer CFT.

Status

Indicates whether the CRONJOB is active or inactive.

Description

A description of the CRONJOB.

File

Indicates whether to use an existing file or upload a new file.

File name

If an existing file, the path to the file.

Choose file

If uploading a file, select the file to upload.

1An object or command for general Transfer CFT environment parameters.



Schedule

Defines when to run the CRONJOB. See CRONJOB schedule syntax on page 234 for the schedule rules.

User ID

Identifies the user of the job.

Additional information

The PARM1 to use in the job execution.

CRONJOB schedule syntaxThe following tables describe Transfer CFT CRONJOB time syntax and symbolic variables. See the script execution scheduling topic in the Transfer CFT user guide for more information.

See CRONJOBs on page 233 for configuring CRONJOBs in the Central Governance user interface.

Time syntaxTime syntax is case sensitive | a, b, c are integers

Rule Syntax Alternate syntax

time time_element; time

time_element

time_element seconds= content

minutes= content

hours= content

monthdays= content

weekdays= content

months= content

s= content

m= content

h= content

D= content

W= content

M= content

content content_elt, content

content_elt

content_elt a

content_set / c

z/OS (MVS) specific syntax

1A user parameter or parameter file in Transfer CFT.


Rule Syntax Alternate syntax

content_set [a:b] [a:b]

[a:]

[:b]

*

<a:b>

<a:>

<:b>

Time syntax examples

If you use this syntax

The job is executed

m=30 Once an hour at minute 30

m=1,5,40 3 times an hour for minutes 1, 5, and 40

m=[30:40]/2 Every 2 minutes, of every hour, between the minutes 30 and 40, this means on the minute for 30, 32, 34, 36, 38, 40

m=[:40] Every minute until, and including, the minute 40

m=[30:] Every minute starting at and including the minute 30

h=6;m=30 Every day at 06:30:00

D=1;h=15;m=30 Every first day of the month, at 15:30:00

D=*/2;h=6 Every 2 days at 06:00:00, day 1, day 3, day 5...day 31. Due to the fact that all months do not have 31 days, the following month the job will be performed 2 days from the 31st, that means on day 2, then day 4, day 6, and so on.

D=[1:7],W=0;h=4

Every first Sunday of the month at 04:00:00

D=-1;h=6 Every last day of the month at 06:00:00

D=[-7:-1];W=3;h=6

Every last Wednesday of the month at 06:00:00

W=0 Every Sunday at 00:00:00

W=1 Every Monday at 00:00:00

M=1 Every January, the first at 00:00:00


CRONJOB symbolic variables

Symbolic variable Corresponding substituted value

&CFTEVENT Fixed name=CRONJOB

&CFTNAME The PART value in the command CFTPARM

&SYSDATE System date

&SYSTIME System time

&SYSDAY Day of the week

&NSUB Counter for all the Cronjob procedures launched

&ID Cronjob Identifier

&CRONTAB Crontab value

&USERID User identifier indicated in CFTCRON command

&COMMENT Comment value indicated in CFTCRON command

&PARM Parm value indicated in CFTCRON command

&SCOUNT Counter for the Cronjob procedures launched for a specific Identifier

Transfer request modeTransfer request mode lets you configure the communications medium used by Transfer CFT when applications connect to it.

OverviewMedium refers to any data support or local communications means used by Transfer CFT. This includes media accessed by Transfer CFT server and utility and media used by interactive functions or programming interfaces. Communications can be asynchronous or synchronous.

Central Governance manages only the first Transfer CFT configuration for each mode.

When you change and deploy changes in the transfer request mode configuration, Central Governance pushes the changes to the selected Transfer CFT and removes any extra communications configurations.



Asynchronous communications are based on a file where commands are stored. Transfer CFT scans the file at specified intervals. This mode is recommended if Transfer CFT might be inactive periodically.

Synchronous communications, based on TCP medium, are possible only when Transfer CFT is running. Only clients on the Transfer CFT local host can establish connections.

Asynchronous communications is the default. If you enable both asynchronous and synchronous communications, Transfer CFT always uses asynchronous. Synchronous communications are used only when set explicitly.


AsynchronousTime between scans

The interval in seconds that Transfer CFT scans the communications file.

SynchronousThe following fields are displayed when synchronous is enabled.

Host

Transfer CFT listening host.

Port

Transfer CFT listening port.

Maximum connections

Maximum allowed number of open connections.

Secured connections

Specifies whether to use the secured version of the request/reply protocol.

Session timeout

Time in seconds before a channel opened by a client is available.

Transfer listThis section describes how to customize and manage a transfer list.



OverviewTransfer lists provide a way to view all transfers in a list format. Each day as you perform transfers, the transfer list records this activity, along with data that is associated with each transfer.

By default the transfer list is purged each day, though this value is customizable. Additionally, you can define retention periods, delete files once the list exceeds a certain size, purge the transfer list at certain times of the day, and so on.


Transfer ListNumber of entries in memory

Maximum number of entries in the memory buffer.

Update during transfer

Indicates whether you can update the transfer list while a transfer is occurring.

Sync points between updates

Number of synchronization points that occur during a transfer before updating the transfer list, where 1 indicates constant updates. This field is displayed only when Update during transfer is enabled.

Synchronize list file when written

Indicates whether to force the transfer list file to synchronize when Transfer CFT processes write to this list.

Entry RetentionYou can define the transfer list purge settings. Additionally, you can refine the transfer list according to whether the transfer was a send or receive, successful or incomplete.

Tip Define retention periods that are balanced between the transfer list size and the time during which you want to be able to act on transfers.

Purge

Indicates whether Transfer CFT should periodically remove older entries in the transfer list.

Interval between purges

Frequency, in days, hours or minutes, to purge the transfer list.



Purge at startup

Indicates whether Transfer CFT should purge the transfer list at start up. The transfer list grows indefinitely when manual purge is selected and startup purge is disabled.

Purge increment ___ entries per step

Indicates how many transfers to delete from the transfer list file per step.

Keep aborted transfers

Indicates whether Transfer CFT should keep aborted transfers or delete them without waiting for a purge.

Retention periodThis subsection defines the period to keep a transfer in the transfer list before purging, according to its transfer direction and status.

Completed incoming transfers before purge

Number of days, hours or minutes after which the entries of incoming transfers that were successfully executed are automatically purged.

Incomplete incoming transfers before purge

Number of days, hours or minutes after which the entries of uncompleted incoming transfers are automatically purged.

Completed outgoing transfers before purge

Number of days, hours or minutes after which the entries of outgoing transfers that were successfully executed are automatically purged.

Incomplete outgoing transfers before purge

Number of days, hours or minutes after which the entries of uncompleted outgoing transfers are automatically purged.

Access and securityThis section describes access management and security configuration for Transfer CFT.

l Access management refers to the policy that allows users to perform actions on Transfer CFT.

l Security is an option to elect FIPS for Transfer CFT.

Access management optionsThe following are the available access types and descriptions.



Central GovernanceCentral Governance administrates access management. Only Central Governance users in an organization with appropriate Transfer CFT privileges can perform operations directly on Transfer CFT, through Copilot or CFTUTIL commands. Additionally, users defined as superusers are not asked for permissions checks for actions performed with CFTUTIL commands.

Transfer CFT uses a built-in cache that allows CFTUTIL users and users authenticated by Copilot to continue being authorized even when Central Governance is unavailable. The authorization-persistent cache on Transfer CFT is updated after access management configuration is changed in Central Governance, meaning, for example, updates occur after a user is created or a user's role assignment is changed. It can take up to 10 minutes before the cache is updated as specified by the Transfer CFT parameter am.passport.persistency.check_interval. This parameter, which has a default value of 600 seconds, represents the interval between two checks of access management updates.

The user and password for logging on are not stored in the cache, which means you cannot connect to Copilot when Central Governance is down.

Transfer CFT internalThis is an out-of-the-box access management based on predefined roles and privileges and a group database. Groups and their members are defined in this supplied database. There are two available databases:

l Operating system group database

l xfbadm database (UNIX and Linux only). Use the xfbadmusr and xfbadmgrp utils to manage users, groups and user assignment to groups.

The pre-defined roles are:

l Administrator: Provides full user access

l Application: Allows applications to request transfers and view the catalog

l Designer: Allows you to manage application flows

l Helpdesk: Enables you to view the catalog and log

l Partner Manager: Allows you to manage partners

The system or xfbadm groups are mapped to the predefined roles, so users inherit the privileges.

NoneUser authorization is based on local users defined in your operating system.




Access ManagementAccess type

Type of access management to use in Transfer CFT. See Access management options on page 239.

The next field, Create process as user, applies to all access types. Check the fields for your selected access type:

l Access type is Central Governance on page 242

l Access type is Transfer CFT internal on page 243

Create process as user

Specifies whether the user who logs on to Copilot server must have system administrator rights.

When set to No, Central Governance controls user authentication.

When set to Yes, the system on which Transfer CFT is installed controls user authentication. When using Central Governance access management type, this allows system users that are declared as superusers to authenticate even when Central Governance is unavailable. All other users must be known on both the system and Central Governance.

To enable this, the user who is logging on to Copilot must have read-write rights for the Transfer CFT installation directory.

This parameter is not available for Transfer CFT on z/OS (MVS).

Additional configuration is required for system user access.

Define user rights on Windows

Some user rights must be assigned to the user who launched the Transfer CFT GUI server to permit other Windows users to log on. This is true except for the local system account when working in the service mode. The user rights to assign are:

l Adjust memory quotas for a process

l Impersonate a client after authentication (only on Windows 2008)

l Replace a process level token

l Create a token object

To define user rights:

1. In a command window, enter lusrmgr.msc to open the system users list. Check available users.

2. In a command window, enter secpol.msc to open the Local Security Policy window.

3. Select Security Settings > Local Policies > User Rights Assignment.

4. Double-click the required right.


5. Click Add user or group and define.

6. Close and re-open the Windows session for the changes to become effective.

If using Central Governance access management type, the user who wants to log on the Transfer CFT Copilot must exist both in the Windows system and Central Governance. The Windows system performs the user authentication and Central Governance checks the authorization.

Define user rights on Unix or Linux

To enable system users in Unix or Linux, use the CFTSU process and give special rights to the CFTSU executable. Copy the cftsu file outside of the home directory and point to the new path.

1. Log on as root.

2. Copy the file to the new location.

cp $CFTINSTALLDIR/bin/cftsu <new_folder>/cftsu

3. Change the owner of the file.

chown root:root <new_folder>/cftsu

chmod u+s <new_folder>/cftsu

4. Use CFTUTIL to set the new folder path.

uconfset id=copilot.unix.cftsu.fname, value=<new_folder>/cftsu

Access type is Central GovernanceThe following fields apply when Central Governance is the access type.

Organization

Central Governance organization for Transfer CFT users. Only users who belong to the selected organization can perform actions on Transfer CFT according to their assigned rights.

Superuser

User IDs of users who have unlimited privileges for Transfer CFT for configuration and transfer execution. These are users who can use Transfer CFT when Central Governance is unavailable using the CFTUTIL command.

These are not necessarily users set up within Central Governance, for instance when using CFTUTIL. However, if you log on with a superuser to Copilot, the user must exist in Central Governance for credential check.

For Unix and Windows the superuser is the user that installs Transfer CFT.

Check permission for transfer execution

Check whether the user has permissions to execute transfers.


When set to No a system user is authorized to perform transfers using CFTUTIL even if the user is not declared in Central Governance.

When set to Yes a system user is authorized to perform transfers using CFTUTIL only if the user is declared in Central Governance.

Access type is Transfer CFT internalThe following fields apply when Transfer CFT internal is the access type.

Group database

Type of database where group members are defined:

l System is the OS group database (UNIX/Linux, Windows).

l xfbadm is the xfbadmgrp database (UNIX/Linux only).

This field is not supported on Transfer CFTs running on z/OS1 and IBM i2 computers.

Admin

Users in these groups can perform all administrative tasks.

Application

User applications from these groups can send transfers.

Designer

Users in these groups can manage flows.

Helpdesk

Users in these groups can view logs, transfers and configuration.

PartnerManager

Users in these groups can add and manage partners.

SecurityMinimum TLS version

Specify the minimum SSL/TLS version to be used by Transfer CFT in secured flows.

TLS cipher suites

Select the TLS cipher suites list for Transfer CFT to use in secured flows.




FIPS

Activates FIPS1 security. FIPS is supported on all Transfer CFT platforms except HP Nonstop.

If you modify this Transfer CFT configuration setting and it is used in a flow, a warning message indicates that the modification has an impact on one or more flows. If you confirm the configuration change, the affected flows are recalculated to reflect the new status. See Configuration change management.

If you activate or deactivate the FIPS level and the product is used in flows, when saving the configuration a warning message indicates that the modification has an impact on one or more flows. If you confirm the modification, the flows are then recalculated to reflect the new status following this change.

VisibilityThe Transfer CFT visibility feature in Central Governance enables you to view and react accordingly to transfer-related events that occur in your system. Central Governance provides a set of graphical displays that you can use to generate business and technical views of transfer processes.

Using the information provided by Central Governance, you can interpret and react to event-related information. For example, a Middleware Manager can use the monitoring interface to be alerted to and act on a flow that is in error.

OverviewWhen you modify and deploy changes in the visibility configuration, Central Governance pushes the changes to the selected Transfer CFT.

How it worksTransfer CFT has a native agent that generates messages containing event processing data. The agent sends the messages, according to the configuration definitions, to the monitoring environment. Central Governance extracts this event tracking data and displays it at Flows > Flows Report in the Central Governance user interface.

1Federal Information Processing Standards (FIPS) have been developed by the U.S. government. FIPS describes document processing, cryptographic algorithms and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with the agencies. Your user license for this software supports FIPS-compliant implementations of certain cryptographic algorithms or IAIK implementations of those algorithms. Also see IAIK in the glossary. For more information about FIPS, see http://www.itl.nist.gov/fipspubs/.



Main and backup serversYour configuration can use either a single main server, where all of the transfer events data is stored, or you can incorporate a backup server in your system. The backup server in Central Governance switches to the secondary server should the primary server fail. Note that the backup server functions exclusively as a failover server, and does not replicate the information on the primary server.

About the internal serverAn internal visibility server is embedded in the Central Governance system. You can choose to use this server as your main monitoring server, or as the backup server.

About the external serverThe external server is not part of the Central Governance system. However, this server may be hosted on the same machine, or separately from Central Governance or your Transfer CFT.

About buffersThere is one buffer per Transfer CFT. This buffer is used to store events when the visibility server is not available. You can define that Transfer CFT stop when the buffer reaches threshold, as described in the Parameters section below.


Enable

Indicates the use of Transfer CFT transfer event tracking, which includes flow monitoring and log file information.

Disabling this option means that not only is there no Transfer CFT event tracking, but also that both the main and backup server options are disabled.

ServersEnable SSL/TLS

Specify if the connection to the monitoring server is secured.

Main server

Indicates the primary monitoring server. Select Internal to use Central Governance or External to use an external server for visibility.



If you select the External server option, you are prompted to enter the host and port for the server.

l Host: Host name or IP address of the main monitoring server.

l Port: Port for the main monitoring server.

Backup server

Indicates the use of a backup server for monitoring events if the main server is down. This server is used only if the main server is unavailable.

Select Internal to use Central Governance or External to use an external server for visibility. None indicates there is no backup server.

If you select the External server option, you are prompted to enter the host and port for the server.

l Host: Host name or IP address of the backup visibility server.

l Port: Port for the backup visibility server.

Note If you select Internal as the main server, you cannot select it as the backup server.

Certificate

If Enable SSL/TLS is set to Yes, and the Main or the Backup server is External, you must browse a certificate and set the certificate alias.

Click Browse to select a public-key certificate file in the DER or PEM format, or a public certificate chain file in the P7B (PKCS#7) format. A certificate is required to authenticate the Visibility server. When a certificate is selected, click Display to show certificate details. Specify an alias for the certificate.

EventsTransfer steps reported

Indicates the Transfer CFT events to send to the Central Governance monitoring.

l All: Transfer CFT sends monitoring events each time a transfer enters a new step, such as ready, on hold, transferred, and so on. Additionally Transfer CFT sends an event at each sync point, as well as at the frequency defined in the parameter Transfer status frequency.

l First and last: Transfer CFT sends events to the Central Governance monitoring when a new transfer request is made and when this transfer is completed, either successfully or in error. When this option is selected, no events are sent for any of the intermediate steps. When you select this setting, the Transfer status frequency parameter is disabled.

l None: No transfer events are sent to the Central Governance monitoring, and the Transfer status frequency parameter is disabled.



Note You must set Transfer steps reported to ALL to enable the Delete, End, Ack, and Nack command options in the Visibility dashboards. See Flow and transfer monitoring on page 72 for details.

Transfer status frequency

Indicate how often Transfer CFT sends events to the monitoring server.

The parameter defines the time value to use when the Transfer steps reported option when it is set to All. The value set here defines how often Transfer CFT sends events related to an ongoing transfer, and includes updated information such as the amount of data transferred, the percentage of completion, and so on.

Minimum log level

Minimum severity level of the messages to display.

For example, if you select Warning, Error and Fatal messages also are displayed.

Buffer capacity

Maximum number of messages in the monitoring buffer.

When buffer is full

Indicates the action when the buffer is full.

l Drop new messages: All messages that exceed the buffer capacity are lost.

l Shut down: When the buffer is full, Transfer CFT shuts down and cannot continue to perform transfers. This requires user intervention to correct the issue and restart Transfer CFT. Use of this option might cause an interruption in your production environment, notably if you have an extended period of unavailability.

LoggingThis section describes how to modify the Transfer CFT log file properties.

OverviewThe Transfer CFT log tracks and lists messages and codes related to transfer operations. This information can be used for troubleshooting and monitoring session activity. You can modify the default log values to, for example, use a more precise timestamp, rotate log files at certain times each day, or change the default number of entries in the log file.



Fields Use the following fields to set the Transfer CFT log properties. The user interface indicates default values.

Entry size

Size in bytes of each entry in the log file. Typically, the default value is adequate.

Timestamp precision

Indicates the preciseness of the time displayed in the log, in seconds, 10 milliseconds, or 100 milliseconds.

File RotationNumber of files in rotation

Number of log files used in the rotation process.

This field is not supported on Transfer CFTs running on z/OS and IBM i computers.

Daily rotation time

Time of day the log file rotates. Additionally, you can rotate the file depending on the size.

Rotate based on size

Indicates whether log files are rotated based on size.

Every _ KB

If files are rotated based on size, indicates the size to trigger the rotation.

Rotate on stop

Indicates whether log files are rotated when Transfer CFT stops.

Log formatThe default log layout for Transfer CFT includes the following standard entry categories.

Date/time


Level

Level of the log entry. Levels, from highest to lowest verbosity, are INFO, WARNING, ERROR, FATAL.



Code

Code associated with the log message.

Message

Actual log message.


13 SecureTransport configuration

The following topics describe configuring SecureTransports managed by Central Governance.

When SecureTransport registers with Central Governance, it has a default configuration that enables it to operate without changes. However, your needs might require changing the default settings.

You can edit the SecureTransport server configuration to use it in flows. However, you cannot deploy the configuration from Central Governance. When you change the SecureTransport configuration in the Central Governance user interface, you also must change the configuration in SecureTransport before using the SecureTransport in flows where it acts as a server.

When SecureTransport connects to a PeSIT server, it resolves server host names to IP addresses and uses the first resolved address to connect to a remote site. SecureTransport checks whether IPv61 is enabled on the computer. If enabled, it returns an IPv6 address. If not, it returns an IPv42 address. If the resolution of host name is IPv6 mode, the other product also must support IPv6 mode. For example, when SecureTransport tries to communicate with Transfer CFT on an IPv6 address, IPv6 mode must be enabled on Transfer CFT. See Network configuration on page 216.

SecureTransport network zonesThe following topics describe network zones and server communication profiles and provide steps to add, view, edit and remove them in the Central Governance user interface.

OverviewA network zone represents a logical group of one or more SecureTransport servers or edges and can be:

l The private network zone that specifies the static configuration running on the SecureTransport server.

l The DMZ3 or network zone that identifies the logical group of SecureTransport edges and the static configuration running on the edges.

1Internet Protocol version 6 (IPv6) is a set of specifications from the Internet Engineering Task Force (IETF) that's essentially an upgrade of IP version 4 (IPv4).2Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet, and was the first version deployed for production in the ARPANET in 1983. It still routes most Internet traffic today, despite the ongoing deployment of a successor protocol, IPv6.3A demilitarized zone (DMZ) or perimeter network is a physical or logical subnetwork that contains and exposes an organization's external-facing services to a larger and untrusted network, usually the Internet. A DMZ adds an additional layer of security to an organization's local area network (LAN). An external network node only has direct access to equipment in the DMZ, rather than any other part of the network.



Although there can be multiple network zones, there can be only one private network zone per SecureTransport.

Within a network zone are server communication profiles. A profile has the technical details for a client to connect to the SecureTransport server via a specified protocol. A network zone can have multiple communication profiles. Minimally, SecureTransport must have at least one profile to transfer files as defined in flows configured in Central Governance and deployed to the product.

A communication profile requires a unique name. This is the name you can select when defining a protocol in a flow.

The protocol is fixed and cannot be changed once the server communication profile is defined.

Server communication profiles belong to a specific network zone, according to whether they represent a service running on SecureTransport server in the private network zone or SecureTransport Edge in the DMZ.

See the SecureTransport Administrator Guide for more information about SecureTransport server and edges.

Manage network zones and communication profilesThe following topics describe actions you can perform on network zones and server communication profiles in the Central Governance user interface.

Add network zone or communication profile 1. Open the SecureTransport configuration page in edit mode. See Change SecureTransport

configuration on page 252 for details.

2. Scroll to the bottom of the page and click Add network zone. Or, select a network zone and click Add communication profile.

3. Complete at least the required fields. Add at least one server communication profile. See Network zone and server communication profile fields on page 252 for descriptions of the fields.

4. Click Save.

View, edit network zone or communication profile 1. Open the SecureTransport configuration page in view or edit mode. See Change

SecureTransport configuration on page 252 for details.

2. If editing, change the configuration as needed. See Network zone and server communication profile fields on page 252 for descriptions of the fields.

3. Click Save.



Remove network zone or communication profileRemoving a network zone removes all the server communication profiles within it. You cannot remove the private network because it represents the SecureTransport server default network zone.

1. Open the SecureTransport configuration page in edit mode. See Change SecureTransport configuration on page 252 for details.

2. Locate the network zone or communication profile to remove and click the X on the right side of the page.

3. Click Save.

Change SecureTransport configurationUse this procedure to change and save a SecureTransport configuration.




4. Select a network zone to edit. Or, scroll to the bottom and click to add a communication profile or network zone. See SecureTransport network zones on page 250 for more information.

5. Change the configuration as needed.

6. Click Save.

Network zone and server communication profile fields

The following are the fields and descriptions for SecureTransport network zones and server communication profiles. You use these fields when adding or editing these objects in the Central Governance user interface. See Change SecureTransport configuration on page 252 or SecureTransport network zones on page 250 for how to access the fields.

Network zone fieldsName

The unique identifier of the network zone. The name is configurable only for zones in the DMZ. The first network zone is always the private zone and cannot be renamed.



Host

The list of SecureTransport servers or edge hosts represented by the host name or IP address.

FQDN

The fully qualified domain name or IP address used by partners and applications to connect to SecureTransport. In a cluster environment, it represents the address of the load balancer, which is the entry point for the SecureTransport environment.

Server communication profile fieldsName

The name of the server communication profile.

Protocol

The protocol for the server communication profile.

Edges

Comma-separated list of active SecureTransport Edge servers in the server communication profile. This field is displayed only for network zones in the DMZ1 and not for the private network zone.

The following are the server communication profile fields by protocol.

PeSITPort

Port on which the server listens for connection requests.

Network protocol

Indicates the network protocol.

l TCP - The Transmission Control Protocol (TCP), one of the core protocols of the Internet protocol suite (IP), is often called TCP/IP. TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer.

l pTCP - The parallel Transmission Control Protocol (pTCP) is an end-to-end transport layer protocol that supports striped connections.

1A demilitarized zone (DMZ) or perimeter network is a physical or logical subnetwork that contains and exposes an organization's external-facing services to a larger and untrusted network, usually the Internet. A DMZ adds an additional layer of security to an organization's local area network (LAN). An external network node only has direct access to equipment in the DMZ, rather than any other part of the network.



PeSIT login

User name for connecting to the server.


Password for connecting to the server.

Enable SSL/TLS

Indicates whether the connection is secured via SSL1 or TLS2.

Client authentication required

If SSL/TLS is enabled, indicates whether to use the client's public key certificate to authenticate the client to the server.

Yes means the server and the client must be authenticated.

No means only the server must be authenticated.

Optional means the server and the client must be authenticated but both SSL and non-SSL connections are enabled. If the client requests SSL but the client certificate verification fails, the client is allowed to log in with a user name and password.

Private certificate

If SSL/TLS is enabled, upload a file containing the server's private key certificate or reuse an existing certificate. For a new certificate, get the certificate file from the server administrator. Supported file types are P12 and PFX.

For a new certificate, specify an alias for it. This enables you to use the same certificate in multiple profiles. The certificate alias must be unique at the product configuration level.

The user interface warns you if you try to add a duplicate alias.

For details see Certificates for HTTP, FTP, PeSIT on page 140.

Enable FIPS transfer mode

When SSL/TLS is enabled, indicates whether Federal Information Processing Standards (FIPS) is enabled for transfers. When enabled, the sender and the receiver must use FIPS-compliant ciphers and ciphers suites. Transfers fail if the sender and receiver do not provide them.

SFTPPort


1Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information.2Transport Layer Security (TLS) is an encryption protocol that ensures communication security over the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS.



Client authentication

Indicates the method for authenticating clients to the server.

l Password - The user name and password for connecting to the server is used to authenticate the client.

l Public key - The client's public key is used to authenticate to the server.

l Password or public key - The public key or password can be used by clients to authenticate to the server.

Server encryption

Upload a file containing the private key or select an existing key. SecureTransport uses this key to encrypt the SSH-FTP channel.

For a new key, specify an alias for it. This enables you to use the same certificate in multiple profiles.

The user interface warns if you try to add a duplicate alias. Aliases are unique by the objects related to them. For example, an alias for a partner certificate must be unique for a specific partner, but the same alias could be used for another partner.



FTPSecureTransport supports explicit security only. This is why there is no security setting in the user interface. With explicit security, the initial connection is unencrypted. To establish the secure link, explicit security requires the FTP client to issue a specific command to the FTP server after establishing a connection. The default FTP server port is used.

Port


Passive port range

SecureTransport has activated both active and passive mode. For the passive mode, specify the range of ports for the server to listen for connections.

Enable SSL/TLS










Private certificate







HTTPPort


Enable SSL/TLS










Private certificate








14 Gateway configuration

The following topics describe configuring Gateway managed by Central Governance.


Change Gateway configurationUse this procedure to add, change, save and deploy server communication profiles1 for Gateway.




4. Select a profile to edit. See Server communication profile fields for more information.

You can delete a profile only if it is not used in flows. You also can add a profile for a specific protocol. To add a PeSIT2 profile, click the add link below the PeSIT section. To add an SFTP3 profile, click the add link below the protocol section.

5. Click Save.

6. Click Deploy when you are ready to push the configuration change to the product.

You can select:

Deploy configuration to deploy the configuration and restart Gateway for the changes to become effective on it.

Deploy, no restart to deploy the configuration, but not restart Gateway. You must restart the product later for the changes to become effective. After the configuration is deployed, the status message at the top of the Configuration page reminds you that a restart is required. A restart reminder also is displayed for the product in the

1Server communication profiles contain details for a client to transfer data via a protocol to the sender or receiver that acts as a server. The sender acts as a server when it publishes files for the receiver. The receiver acts as a server when it receives files pushed by the sender.2PeSIT is an open file transfer protocol often associated with Axway. PeSIT stands for Protocol d’Echanges pour un Systeme Interbancaire de Telecompensation. It was designed as a specialized replacement for FTP to support European interbank transactions in the mid-1980s.3SSH File Transfer Protocol (SFTP) is a network protocol for file transfer and manipulation functionality over any reliable data stream.



Configurations list on the Deployment List page from Administration > Deployments.

7. If you selected the Deploy, no restart option, go to the Product List page and restart the product when you are ready. Select Products on the top toolbar to open the page.

Deployment conflict management When conflicts occur at flow or configuration deployment, Central Governance displays messages prompting you to confirm or cancel deployment actions.

If you confirm, Central Governance deploys the flow or configuration, which implies an update of the current Central Governance configuration properties even if some existing flows or legacy flow will be broken. If you do not confirm, the deploy action is canceled.

There are 3 types of conflicts at deployment:

l between Central Governance flows

l between Central Governance flows and legacy objects

l between product configuration and legacy objects

Central Governance flows conflictsThere may be cases in which a flow deployment breaks flows that are already deployed due to object sharing conflicts. If this occurs, you can either continue the deployment or cancel the deploy operation.

There is one exception that avoids the situation in which the product configuration is broken due to a flow deployment: when private keys or private certificates are used in Server Communication Profiles and are uploaded on flow definition under different alias. In this case, the deployment operation fails in error.

Conflicts with legacy objectsYou can use an established procedure to migrate Gateway legacy flows to the Central Governance flows flow-management process.

During the transition to flow management with Central Governance, there can be a period in which Gateway and Central Governance flow objects overlaps. Because Central Governance validates the uniqueness of objects present on Gateway, at flow or configuration deployments, a warning is displayed by Central Governance if objects already exists.

Conflict detection with legacy objects happens during the deployment operation, but it is based on the list of objects present on the product when Gateways register with Central Governance. If new objects are created in Gateway post registration, and conflicts are detected at CG flow or configuration deployments with these objects, the deployments end in error.



If several conflicts categories are detected during flow deployment, only a single message is displayed with an option to continue the deployment confirming the deployment for all conflicts.

Server communication profile fieldsThis page describes Gateway server communication profile fields, used when adding or editing profiles in the Central Governance user interface. See Change Gateway configuration for how to access the fields.

Name

The name of the profile. The name cannot be changed once the profile has been added.

Note If the registered Gateway is a node in an active/passive cluster, then Cluster Virtual Host is available as a global parameter. The initial value is set during Gateway installation in cluster mode, but you can updated this field if needed.

The following are the fields by protocol.

PeSITNetwork zones

Indicates whether the specified port opens on the computer running Secure Relay or Gateway. The value depends on the Secure Relay access policy that was set on Gateway, for the protocol, prior to Gateway registering with Central Governance.

You can set to Yes or No depending on if Secure Relay is used or not. If the policy is:

l Secure Relay is not used: then the field value is No. You cannot modify this value.

l Through Secure Relay only: then the field value is Yes. You cannot modify this value.

l Through Secure Relay or directly: then you can set the value to either Yes or No.

Host

If Network zones is Yes, the Host field lists the IP addresses of all Secure Relays declared in Gateway. You cannot change these values.

If Network zones is No, the Host field lists the IP addresses or host names of all network interfaces available in Gateway.

If ALL INTERFACES is selected, Gateway opens the specified port on all available network interfaces.

In the Custom value field, you can enter a new host name or IP address.



Note If a profile is used in flows and you change this field, the status of the affected flows becomes Saved, not deployed.

Port

The port on which the server listens for connection requests.

l If the profile uses Network zones, Gateway opens this port on all Secure Relays declared in its configuration.

l If the profile does not use Network zones, Gateway opens this port on the host specified in the Host field.

l If ALL INTERFACES is selected in the Host field, Gateway opens this port on all available network interfaces.

l If a profile is used in flows and you change this field, the status of the affected flows becomes Saved, not deployed.

Load balancer parameters

Indicates whether the incoming connection(s) go through a load balancer before reaching Gateway or Secure Relay.

l Select Yes when using a load balancer.

l Select No when not using a load balancer.

Public host

This field is available only when the Load balancer option is set to Yes.

Host name or IP address of the load balancer.

Public port


Port on which the load balancer listens for incoming connection requests.

PeSIT login

The identity Gateway presents to the client when the server communication profile is used in flows. Typically, a login is required when PeSIT acknowledgments are enabled.

You cannot change the login value after creating the profile.


The password Gateway presents to the client. A password might be required when acknowledgment is enabled in flows.

Enable SSL/TLS

Indicates whether the connection is secured via SSL Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information. or TLS Transport Layer Security (TLS) is an encryption protocol that ensures communication security over



the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS..





Optional means the server and the client must be authenticated, but both SSL and non-SSL connections are enabled. If the client requests SSL but the client certificate verification fails, the client is allowed to log in with a user name and password.

Private certificate


For a new certificate, specify an alias for it. This enables you to use the same certificate in multiple profiles. The certificate content and alias must be unique at the product configuration level.

The user interface warns if you try to add a duplicate alias.

For details see Certificates for HTTP, FTP, PeSIT.

SFTPNetwork zones

Indicates whether the specified port has been opened on the computer running Secure Relay or Gateway. The value depends on the Secure Relay access policy set on Gateway for the protocol when Gateway was registered with Central Governance. Set the value to Yes or No depending on if Secure Relay is or is not used.

l If the policy was set to Secure Relay is not used, the field value is No. You cannot change this value.

l If the policy was set to Through Secure Relay only, the field value is Yes. You cannot changed this value.

l If the policy was set to Through Secure Relay or directly, the field value is Yes or No.

Host

If network zones is Yes, the Host field lists the IP addresses of all Secure Relays declared in Gateway. You cannot change these values.



If network zones is No, the Host field lists the IP addresses or host names of all network interfaces available in Gateway.


Use the Custom value option to enter a host name or IP address that is not listed.

If a profile is used in flows and you change this field, the status of the affected flows becomes Saved, not deployed.

Port


l If the profile uses network zones, Gateway opens this port on all Secure Relays declared in its configuration.

l If the profile does not use network zones, Gateway opens this port on the host specified in the Host field.


If a profile is used in flows and you change this field, the status of the affected flows becomes Saved, not deployed.



Yes means that a load balancer is used.

No means that a load balancer is not used.

Public host

Field available only if the Load balancer parameters is set to Yes.


Public port

Field available only if the Load balancer parameters is set to Yes.



Indicates the method the server uses to authenticate clients.

l Password: Server requests a user name and password from the client to authenticate it.

l Public key: Server requests client's public key to authenticate it.

l Password or public key: Server checks for the client’s public key. If not provided, it requests a user name and password to authenticate the client.



You cannot change the client authentication setting once the profile is used in a flow.

Server encryption

Upload a file containing the private key or select an existing key. Gateway uses this key to encrypt the SSH-FTP channel.

For a new key, specify an alias for it. This enables you to use the same certificate in multiple profiles. The alias must be unique at the product configuration level.

The user interface warns if you try to add a duplicate alias. Aliases are unique by the objects related to them. For example, an alias for a private key to upload on a Gateway server instance must be unique for that Gateway instance in Central Governance, but the same alias could be used when uploading new keys for another Gateway instance.

When deploying the configuration, the new private key is imported in Gateway. If a key with the same alias and fingerprint already exists in Gateway, the deployment continues.

FTPNetwork zones






Host






Port












Public host



Public port



Limit passive port range

Specify whether to limit the range of ports for data connections in server passive mode that is attached to a session established on the server listen port.

Yes: You must explicitly set the lower and the upper limits.

No: The maximum port range is used.

From

If the option to limit the passive port range is enabled, set the minimum port value. The default value is 1024.

To

If the option to limit the passive port range is enabled, set the maximum port value. The default value is 65535.

Enable SSL/TLS

Indicates whether the connection is secured via SSL Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information. or TLS Transport Layer Security (TLS) is an encryption protocol that ensures communication security over



the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS..






Security mode

Configure Gateway to handle the security for the incoming connections.

Explicit: The connection occurs on a secure port and the control session opens directly in TLS.

Implicit: The connection occurs on an unencrypted port and decision to launch the SSL/TLS layer is negotiated once the session is established.

Private certificate




HTTPNetwork zones








Host






Port










Public host



Public port





Enable SSL/TLS

Indicates whether the connection is secured via SSL Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information. or TLS Transport Layer Security (TLS) is an encryption protocol that ensures communication security over the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS..






Private certificate




Gateway active/passive cluster Axway Gateway supports active/passive clusters. In this context, Central Governance manages only the active Gateway.

Installation

When installing a cluster environment that is managed by Central Governance, you must set the cluster virtual host. This setting represents the address visible to external partners. Note that in a governance context, the Gateway configuration is shared among all nodes.

Registration

Once Gateway is registered in Central Governance, the Host column of the Product list displays the cluster virtual host.

Configuration



If needed, you can change the value of the cluster virtual host that was set during installation. Please note that you can have a network zone and/or load balancer in front of the cluster.

Flow definitionDepending on the environment architecture, a flow definition has the following entries available in the Server Communication Profiles section:

Cluster environment

Load balancer

Network zone

Server communication profile(s)

Enabled in Server Communication Profile


Exposed in the flow definition

Starting with the SCP defined in the product configuration

Yes No No l SCP exposing the cluster virtual host

Yes Yes No l SCP exposing the cluster virtual host

l SCP exposing the load balancer host



Cluster environment

Load balancer

Network zone

Server communication profile(s)



Exposed in the flow definition

Starting with the SCP defined in the product configuration

Yes Yes Yes 1. If the Secure Relay access policy in Gateway is Through Secure Relay only at registration, flows have:

l SCPs exposing the network zone hosts


2. If the Secure Relay access policy in Gateway is Through Secure Relay and directly at registration, flows have:



l SCP exposing the cluster virtual host

Yes No Yes 1. If in Gateway the Secure Relay access policy is ‘through Secure Relay only’ at registration, in flows have:


2. If in Gateway the Secure Relay access policy is ‘through Secure Relay and directly’ at registration, in flows have:


l SCP exposing the cluster virtual host


15 Policies

A policy represents common configuration settings for multiple Transfer CFTs. You can simultaneously deploy the same configuration changes to all Transfer CFTs assigned to a policy. For example, if multiple Transfer CFTs use parallel TCP (pTCP), you can create a policy with this configuration and deploy it to the Transfer CFTs.

The Policy List page lets you add and manage the configuration policies defined in Central Governance. You can see the list of policies and the number of Transfer CFTs assigned to them. The page also reports the status of the policy, which indicates where the policy is in its lifecycle. In addition, you can add, deploy and remove policies.

Policy lifecycleVarious statuses are displayed during phases of a policy lifecycle. When a policy is first created, the status is displayed on the Policy List and policy detail pages. Once you start to deploy the policy, the statuses also are displayed on the Deployment List page.

PhasesThis topic describes each phase in a policy lifecycle and the effect of the phase on the configuration of Transfer CFT.

The date format has two variants. All of the examples use the current day message format.

l <Status> at <time> today when today.

l <Status> on <date>when not today.

CreationAdd a policy that contains the configuration values you want to deploy. The status of the policy is Saved at <time> today.

AssignmentAssign, or link, the policy to individual Transfer CFTs. See Status changes on page 272 for information about the statuses that can be displayed during this phase.

l When a policy is assigned, the configuration of each Transfer CFT is saved in Central Governance with the values defined in the policy. The policy status is Saved, not deployed or Deployed to <n> of <n>.

15 Policies

l When an existing policy is updated and saved, the configuration of each Transfer CFT assigned to the policy is automatically updated locally with the changes. This means that the change was made only in Central Governance, and not on the Transfer CFT.

l When a policy is unlinked, the Transfer CFT configuration retains the changes that were applied when the policy was assigned.

DeploymentDeployment pushes the saved changes to each Transfer CFT assigned to the policy. During and after deployment, status messages report the success or failure of deploying to the Transfer CFTs. For example:

l Deploying since <time> today (2 in progress) indicates the policy is being deployed to two Transfer CFTs.

l Deployed at <time> today (2 deployed) indicates the policy was deployed successfully to the two Transfer CFTs assigned to the policy.

l Deployed at <time> today (1 deployed, 2 in error) indicates the policy was deployed successfully to one Transfer CFT but failed to deploy to two other Transfer CFTs.

You can get more information about policy deployments statuses by selecting Administration> Deployments and clicking In error or Policies.

ModificationEdit the policy and save it. See Status changes on page 272 for information about the statuses that can be displayed during this phase.

RemovalRemove the policy from Central Governance.

l When a policy that was deployed is removed, the configuration changes that were applied to the Transfer CFT remains unchanged.

l When a policy that was only assigned, but not deployed, is removed, the configuration of the Transfer CFT in Central Governance is that of the policy. Since the policy was never deployed, there are no changes to the actual Transfer CFT configuration.

Status changesThe policy status changes when you perform an action on a policy. The following table illustrates how the policy status is affected when a user assigns, unassigns or edits a policy after its creation. All of the examples use the current day message format.

15 Policies

Policy status before User action

Policy status after

Saved at <time> today Assign policy

Saved at <time> today, not deployed

Edit policy Saved at <time> today

Saved at <time> today, not deployed Assign policy


Unassign policy


Edit policy Saved at <time> today, not deployed

Deployed to <n> of <n'> Transfer CFTs at <time> today

Assign policy

Deployed to <n> of <n'+1> Transfer CFTs at <time> today

Unassign policy

Deployed to <n-1> of <n'-1> Transfer CFTs at <time> today


Deployed at <time> today Assign policy

Deployed to <n> of <n+1> Transfer CFTs at <time> today

Unassign policy

Deployed at <time> today


Business lifecycle scenarioThe following table illustrates the phases a policy goes through and the status changes that occur in a store-to-corporate business use case. Multiple stores in different regions require the same configuration. The stores communicate with the product catalog application at corporate headquarters. All of the examples use the current day message format.

Business need Policy status before

User action

Policy status after

All stores must be able to communicate with the corporate application in a common way

Create policy

Saved at <time> today

15 Policies

Business need Policy status before

User action

Policy status after

All stores must be configured in the same way, for example, by using the same protocol


Assign policy


To meet a short time window to exchange files, must optimize throughput, for example, by configuring file transfer acceleration


Edit policy


Save time and money by deploying the configuration to all stores at one time


Deploy policy


Due to expansion into new region, add stores communicating with the corporate application


Assign policy

Deployed to <n> of <n+n'> Transfer CFTs at <time> today

Save time and money by deploying the configuration to all new stores at one time

Deployed to <n> of <n+n'> Transfer CFTs at <time> today

Deploy policy


Close some stores that are not performing Deployed at <time> today

Unassign policy


Manage policiesUse the following procedures to manage policies. Note that you can define the link to a policy at registration, as described in Transfer CFT registration on page 177

Add a policy 1. Select Products > Policies to open the Policy List page.

2. Click Add policy to open the Add Policy page.

3. In the Policy Information section, enter a name and, optionally, tags and a description.

4. In the left menu, select the section of the configuration to provide new values.

You can click the help link for each section to open a configuration topic that maps to the target section.

5. Click the appropriate icon next to the field you want to modify.

15 Policies

One icon sets the value so that it can be overridden and the other locks the value. When a field is locked, you cannot edit it on the Transfer CFT configuration page. This applies to all assigned Transfer CFTs.

The field is now editable.

6. If a default value is displayed in the field, accept it or enter a different value.

7. You can change as many sections as you want for the policy.

8. Click Save.

Assign a policyWhen assigning a policy, you link it to one or more Transfer CFTs. The configuration values in the policy are applied immediately and saved in Central Governance. Changes to the Transfer CFTs only occur when the policy is deployed. The Policy List page provides access to all members of a policy.

You can assign only one policy at a time to Transfer CFT.

1. Select Products on the top toolbar to open the Product List page.

2. Select one or more Transfer CFTs and click Assign policy.

3. On the Assign Policy dialog, select the policy to assign and click Apply.

To unassign a policy, select None and click Apply.

Unassigning a policy disassociates it from the Transfer CFT, but there is no effect on the configuration itself. All policy values are retained in Central Governance and no changes are made to the Transfer CFT configuration.

Deploy a policyAfter a policy is assigned, you can deploy it. The policy is deployed only on the assigned Transfer CFTs on which it is not deployed already.

1. Select Products > Policies to open the Policy List page.

2. Select the policy to deploy and click Deploy. In the dialog, confirm the deployment. The affected Transfer CFTs are restarted after the policy is deployed.

The status of the policy changes as the deployment progresses. If a deployment fails on one or more systems, an error status is displayed. When this happens, check the in-error section on the Deployment List page at Administration > Deployments. Also check the message column of the Core Services log for information about the cause of the failure. A link to view the log is at Administration > Services.

View, edit a policyWhen you edit a policy:


15 Policies

l A changed value applies to all assigned Transfer CFT configurations.

l If a value is overridden, it overwrites the Transfer CFT configuration value.

l Transfer CFT values not defined or changed in a policy remain unchanged on Transfer CFT.


2. Click the name of a policy to open its details page.

3. Click Edit to open its edit page.

4. Click Save when you are done making changes.

Copy a policyA duplicate policy is created when you copy a policy, but no Transfer CFTs are assigned to the copy until you do so.


2. Click the name of a policy to open its details page.

3. Click Copy to make a copy of the policy.

4. Change the policy as you like and click Save when done.

When you copy a policy, Central Governance gives the copy a name in the format:

<original policy name> - Copy<n>

Where <n> is the number of the copy. The first time a policy is copied, n = 1, the second time n = 2 and so on.

The copy also is given a default description in the format:

Policy copied from <original policy name>

You can keep or change the default name or description of the copy.

If you make a copy of a copy, the default name of the subsequent copy is in the format:

<original policy name> - Copy<n> - Copy<n>

Remove a policyA removed policy is unassigned from Transfer CFT, but no changes are made to the Transfer CFT configuration.


2. Select the policy or policies to remove and click Remove. In the dialog, confirm the removal.

16 Applications

An application is the logical representation of a business software application that is the true sender or true receiver in a file exchange. An application represents a back-end enterprise resource planning system such as SAP or PeopleSoft.

File-exchange processes are specified in flows1. You must add applications in Central Governance before you can define flows involving applications.

You can view and manage applications on the Application List page in the Central Governance user interface. You can filter the list and perform other tasks on the page.

Manage applicationsThe following topics describe how to add, view, edit and remove applications in Central Governance.

Adding an application2 in the user interface makes it known to Central Governance. Adding applications is a prerequisite to defining flows involving them and being able to exchange files.

An application can be associated with multiple registered products; the products can be on the same or different hosts. One or more products in the application can be assigned for use within a single flow. And you can have another flow that uses the same application as the source or target, but that specifies different products in the application. See Defining flows on page 349 for more information.

Multiple products and multiple types of products on the same or different hosts are allowed within the same application because all have similar folder-monitoring behavior. All of these products can consume files from a directory and produce files to a directory.

Add an application 1. Click Applications on the top toolbar to open the Application List page.


3. Do the following:

a. Enter a name for the application. Typically, use a unique name, but you can reuse a name provided the associated product is on a different computer. Central Governance checks whether an application name is valid by name-host pairs.

1A flow specifies the technical details and communications protocols for exchanging business data between business applications or partners.2The logical definition of a business application that is the real endpoint of a file exchange.


16 Applications

b. Specify the computer that hosts the application. You can provide a computer name or an IP address. You can find the hosts of registered products by clicking Products on the top toolbar and checking the Product List page.

When you enter a host value, Central Governance detects all registered products on the computer and lists their names in the Products field. For example, if instances of Transfer CFT and SecureTransport are on the computer and are registered in Central Governance, the names of all three are added to the Products field.

c. If necessary, edit the Products field. For example, although two registered products might be on the same host, you want only one of the products to be associated with the application. Also, you might want to add the name of a registered product that is on a different host than the one specified in the Host field.

4. In the optional Details area:

a. Enter a group name if you want the application to be a member of a group. To associate an application to multiple groups, use a comma to separate group names.

b. Enter any tags1 to help you identify or categorize the application.

5. In the optional Contact area, enter information about the primary business contact for the application.

6. Click Save application to add it and return to the Application List page. The products and product types associated with the new application are listed in the Products and Product Types columns.

View or edit an applicationThe details page for an application enables you to review more information than is displayed on the Application List page.

Click Applications on the top toolbar and then click the name of an application to open its details page.

On the details page, you can:

l Click Edit to edit any fields, such as:

o The host associated with the application

o Contact information

l Click Remove on the right side of the page to remove it. See the next topic.

Remove an applicationYou can remove an application from Central Governance by:

1Keywords for classifying objects like applications, products, flows, partners.


16 Applications

l Selecting the application on the Application List page and clicking Remove.

l Clicking Remove when viewing the application details page.

If the application is used in flows, a confirmation message is displayed. If you confirm the removal, the application is removed from the flows and the status of the flows is recalculated. You must redeploy the flows manually.

Application groupsYou can organize multiple applications that have a common purpose into application groups. For example, group all stores in a region so all can be members of the same flow.

Groups do not have to be predefined. You can assign an application to one or more groups when you add or edit the application. If those groups do not exist, they are created.

Alternatively, you can make group assignments and add groups from the Application List page. You also can create groups directly from the page

Flow managementGrouping applications eases the task of flow definition and management. For example, if your organization needs to exchange files between corporate headquarters and stores located in a geographic region, you can create a single group that contains the applications running at those stores. When you define the flow for the exchange, the flow target is the entire group. If a new store opens, you can add it to the group, and the store is automatically included in the flow and receives the exchanges that all other stores in the group receive.

If you remove an application from a group that is used as a source or target in a flow, the application or the system no longer sends or receives the exchanges.

Central Governance supports using, as sources and targets, application groups containing applications linked only to Transfer CFTs and not to any other registered products.

Assign applications and add group at same time 1. Click the Applications tab to open the Application List page.

2. Select one or more applications to assign to a group and click Grouping.

3. Select the group and click Apply.

4. If the group does not exist, click Add group.

5. Enter a name, select the check box if it is not already selected, and click Apply.


16 Applications

Add group and add applications to it 1. Click the Applications tab to open the Application List page.

2. Click Grouping.

3. Click Add group.

4. Enter a name and click Apply.

5. You can now select applications from the list to add to this group.

Remove application from group 1. Click the Applications tab to open the Application List page.

2. Select one or more applications.

3. Click Grouping.

4. Deselect the check box next to the group name.

5. Click Apply.

Manage application groupsThe Application Group List page enables viewing all application groups and performing actions on groups: add, edit, remove. You can see the number of application members assigned to a group. The page also lists the product types represented within groups, which is helpful because you can associate different types of products with one application.

Access the Application Group List page by:

l Selecting Applications > Groups on the top toolbar

l On the Application List page, clicking Grouping > Manage groups.

Add a group 1. Click Add application group on the Application Group List page.

2. Enter a unique name, and optionally, tags and a description.

3. Click Save application group.

Edit a group 1. Click a group name.

2. Click Edit.


16 Applications

3. Make your changes.

4. Click Save application group.

Remove a group 1. Select the group to remove.

2. Click Remove.

3. Click Remove application group to confirm.

View group membersIn the Members column, click a number to view the group members. The number represents the total group members. The Application List page is displayed and lists the group members. Note the Filter field above the table shows the list of applications is filtered by the group name.


17 Groups

Groups enable you to organize and manage similar items. Groups are collections of objects with a common purpose or characteristics. You can group products, unmanaged products and applications. The main use cases for grouping items are for configuration management and flow management.

Note See Application groups on page 279 for more information.

Grouping productsGrouping products enables you to deploy configurations and perform operations all together. For example, perform operations such as starting or stopping from the command line interface by specifying the group of products.

Things to know l Groups must contain only like items, such as applications or products. A group cannot contain both applications and products.

l A group cannot be a sub-group of another group.

l An object can be added to a group and later removed.

l An object can belong to one or more groups.


18 Partners

Partners represent entities such as companies that send or receive business data in file transfers governed by Central Governance flows. Partners can use third-party products or Axway products not registered in Central Governance to communicate with other parties over supported protocols.

Partners can be sources or targets in Central Governance flows. They also can be in client or server roles, depending on whether the partners initiate transfers. Partners support multiple types of communication protocols.

Partner objects in Central Governance consist of:

l General information that includes the partner name, tags, description and contact information such as street and email addresses.

l Server communication profiles that specify the protocols for secure or unsecure connections to partners. See Communication profiles on page 302.

You must add partners in Central Governance before you can use them in flows.

Manage partnersUse the following procedures to manage partners. If you edit an existing partner definition that is used in a flow, a message displays when you click Save indicating the impact on the flow. A warning message indicates that the modification has a detrimental effect on one or more flows. Additionally a corresponding entry displays in the audit for each impacted flow.

View list of partnersSelect Partners to open the Partner List page. The page lists all partners and details about them.

You can:

l Filter the list of partners by conditions such as name, email address and so on.

l Click the name of a partner to view or edit its details.

l Add or remove a partner.


18 Partners

Add partner 1. Select Partners > Add partner to open the Add Partner page.

2. Complete at least the required fields. Optionally, you can add one or more tags1. See Partner fields on page 285.

3. Click Save to add the partner.

View, edit partner 1. Select Partners to open the Partner List page.

2. Click the name of a partner to view its details.

3. Click Edit on the details page.

4. Enter changes as needed. See Partner fields on page 285.

5. Click Save.

Remove partnerSelect Partners to open the Partner List page, select one or more partners and click Remove. When you confirm the removal, all related flows are updated and a message is displayed in the audit for each impacted flow.

This removes the partner from the flow or flows where it is used. The flows are then recalculated to reflect the new status following this change.

Remove a server communication profile from a partnerTo remove a server communication profile from a partner, select the partner then click Edit. Scroll to the name of the profile to remove, and click X in the right margin. Clicking Save removes the partner communication profile from the partner. However if the profile is used in a flow, a warning message indicates that the modification may have a detrimental effect on one or more flows. If you confirm the removal, a corresponding entry displays in the audit for each impacted flow.



18 Partners

Partner fieldsThe following are the fields for adding or editing partners1 in the Central Governance user interface. If you edit an existing partner definition that is used in a flow, a message displays when you click Save indicating the impact on the flow.

See Manage partners on page 283 for actions you can perform and the possible impact on existing flows.

General informationOnly the partner name field is required in the general information section for a partner. All other fields — tags2, description, address, phone, email — are optional.

Server communication profilesA server communication profile contains the technical details for a client to connect to the partner's server via a specified protocol. A partner can have multiple communication profiles. Minimally, a partner must have at least one profile to transfer files as defined in flows configured in Central Governance and deployed to products.

A communication profile requires a unique name. This is the name you can select when defining a protocol in a flow. Optionally, you can specify tags and a description.

The user interface warns if you try to add a duplicate profile name. Names are unique by the objects related to them. For example, a name for a partner profile must be unique for a specific partner. But the same name could be used for another partner.

The following describes the fields by protocol. To add multiple profiles, click Add communication profile.

PeSITNetwork protocol



1Partners represent entities such as companies that send or receive business data in file transfers governed by Central Governance flows.2Keywords for classifying objects like applications, products, flows, partners.


18 Partners


l UDT - The UDP-based Data Transfer Protocol (UDT) is a high performance data transfer protocol designed for transferring large volumetric data sets over high-speed wide-area networks.

Host

URL of the PeSIT server. You can specify multiple hosts separated by commas.

Port


PeSIT login

User name for connecting to the server.



Enable SSL/TLS







Server authentication

If SSL/TLS is enabled, upload a file containing the server's public key certificate or reuse an existing certificate. For a new certificate, get the certificate file from the server administrator. Supported file types are DER, CER, CRT and P7B.




18 Partners



SFTPHost

The IP address or fully qualified domain name of the server. You can specify multiple hosts separated by commas.

Port



Indicates the method for authenticating clients to the server.

l Password - The user name and password for connecting to the server is used to authenticate the client.

l Public key - The client's public key is used to authenticate to the server.

l Password or public key - The public key or password can be used by clients to authenticate to the server.

Server verification

Upload a file containing the public key or select an existing key.

For a new key, specify an alias for it. This enables you to use the same certificate in multiple profiles. The alias must be unique at the product configuration level.





18 Partners

FTPHost

The IP address or fully qualified domain name of the server. You can specify multiple hosts separated by commas.

Port


Connection mode

Indicates whether the connection mode is active, passive or both. The server initiates the session in active mode, while the client initiates in passive mode. Both means the server or client can initiate the session.

Port range

If the connection mode is passive or both, specify the range of ports for the server to listen for connections.

Enable SSL/TLS







Security mode

Indicates whether the security mode is explicit or implicit.

FTP supports two methods to accomplish security through a sequence of commands passed between two computers. The sequence is initiated with explicit (active) or implicit (passive) security.

l Explicit security. The initial connection is unencrypted. To establish the secure link, explicit security requires the FTP client to issue a specific



18 Partners

command to the FTP server after establishing a connection. The default FTP server port is used.

l Implicit security. Implicit security begins with a secure connection as soon as the FTP client connects to an FTP server. The FTP server defines a specific port for the client to be used for secure connections.



For a new certificate, specify an alias for it. This enables you to use the same certificate in multiple profiles.

The user interface warns if you try to add a duplicate alias. Aliases are unique by the objects related to them. For example, an alias for a partner certificate must be unique for a specific partner. But the same alias could be used for another partner.



HTTP Server address format

Specify the server with a URL or a host-name pair.

URLs

If the URL format is selected, enter one or more URLs separated by commas. The expected pattern for a URL is: http://{host}:{port}

Host

If the host-port format is selected, enter one or more computer names separated by commas.

Port

If the host-port format is selected, enter the port that the specified server or servers listen for connections. You can enter only one port number.

HTTP methods

Select one or more methods for transferring data:


18 Partners

PUT requests the enclosed entity be stored under the supplied URI1. If it refers to an existing resource, the URI is changed. If the URI does not point to an existing resource, the server can create the resource with that URI.

POST requests the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources.

GET requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect.

Enable SSL/TLS









For a new certificate, specify an alias for it. This enables you to use the same certificate in multiple profiles.

The user interface warns if you try to add a duplicate alias. Aliases are unique by the objects related to them. For example, an alias for a partner certificate must be unique for a specific partner. But the same alias could be used for another partner.



1A uniform resource identifier (URI) is a string of characters for identifying the name of a resource. This enables interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols.2Secure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information.3Transport Layer Security (TLS) is an encryption protocol that ensures communication security over the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS.


19 Unmanaged products

Unmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be:

l Transfer CFTs 3.1.2 or higher that are not registered with Central Governance

l SecureTransports 5.3.1 or higher that are not registered with Central Governance

l Gateways 6.17.1 or higher that are not registered with Central Governance

l Earlier versions of Transfer CFT, Gateway, or SecureTransport that cannot register with Central Governance

l Axway products other than Transfer CFT, Gateway, or SecureTransport

l Third-party products

Unlike registered products, Central Governance cannot detect, start, stop or change the configurations of unmanaged products. However, the Central Governance user interface provides a way to define unmanaged products and include them in flows.

In Central Governance, unmanaged products can be defined in flows as a source, target or relay. Central Governance deploys flows on registered products. When unmanaged products are used in flows, however, the flow definitions must be applied externally to those products.

Certain Central Governance predefined user roles allow users access to unmanaged products.

l The predefined Middleware Manager role lets users view unmanaged products.

l The predefined IT Manager role lets users view, add, change and delete unmanaged products.

Use Unmanaged Products pageUse the Unmanaged Products page to administrate products that are known to Central Governance, but are not managed by it.

Select Products > Unmanaged Products to open the page.

On the page you can:

l View a list of all unmanaged products. Use the Filter button to filter the list according to selected criteria.

l Click Add unmanaged product to add one. See Add unmanaged product on page 292.

l Click the name of a product to view its details page. See View unmanaged product on page 292.

l Select one or more in the list and click Remove to delete.



Add, view, edit unmanaged productsUse the following procedures to add and edit unmanaged products.

Add unmanaged product 1. Select Products > Unmanaged Products to open the Unmanaged Products page.

2. Click Add unmanaged product to open the Add Unmanaged Product page.

3. Complete at least the required fields. See Unmanaged product fields on page 292 for details.

4. Click Save unmanaged product to add it.

View unmanaged product 1. Select Products > Unmanaged Products to open the Unmanaged Products page.

2. Click the name of a product to open its details page. See Unmanaged product fields on page 292 for field descriptions.

Edit unmanaged product 1. Select Products > Unmanaged Products to open the Unmanaged Products page.

2. Click the name of a product to open its details page.

3. Click Edit to open its edit page.

4. Change values and click Save changes when done. See Unmanaged product fields on page 292 for details.

Changing some values, such as host or protocol, triggers Central Governance to check whether an unmanaged product is used in a flow. If so, a message advises that changing the product also changes the flow and prompts whether you want to continue.

Unmanaged product fieldsThe following are the fields for unmanaged products. You only need complete required fields. Required fields are identified on the user interface page.

Name

Unique name of the unmanaged product.

The name must be unique among all unmanaged products in Central Governance. For instance, you can register a product with the same name as an unmanaged product if you plan to migrate flows to the new product instead of using the old unmanaged product.



Host

A single host or multiple hosts separated by commas. Host name must have alphanumeric characters, but the following special characters are allowed:

. period: semicolon_ underscore- hyphen

Type

You can select an Axway product as the type. Or, select Custom for any product not listed and enter the name in the provided field.

Version

Product version.

Operating system

Operating system of the computer where the product is installed.

ProtocolThere are three supported network protocols. At least one must be defined. The types are TCP, pTCP and UDT. All three are associated with TCP, but pTCP and UDT are used specifically for file transfer acceleration.

PeSIT login

The identifier for connecting to the PeSIT server. The PeSIT login must be unique among all unmanaged products in Central Governance. However, it can be the same as the PeSIT login for a registered product.

PeSIT password and confirm password

The password for connecting to the PeSIT server. The password might be required or optional, depending on the requirements of the unmanaged product.

PeSIT/

Optionally, specify mutual authentication for file transfers. Specify a certificate if mutual authentication is selected.

Port in

The port the server listens for connections.

Certificate

Click Browse to select a public-key certificate file in the format DER or PEM or a public certificate chain file in the format P7B (PKCS#7). A certificate is required when mutual authentication is enabled.



When a certificate is selected, click Display to show certificate details.

DetailsGroups

One or more groups1 separated by commas. See Groups on page 282.

Tags

One or more tags2 separated by commas.

Description

Description of the unmanaged product.

ContactOptionally, the name, job title, email address and phone number of a contact person for the unmanaged product.

1Groups enable you to organize and manage related products.2Keywords for classifying objects like applications, products, flows, partners.


20 General concepts about flows

You can view and manage the flows defined in Central Governance on the Flow List page. You can filter the list of flows and perform other tasks.

A flow1 in Central Governance is the complete definition of the file transfers between the source and target.

See the following topics for information about use of Axway products in flows.

l Transfer CFT flow concepts on page 323

l SecureTransport flow concepts on page 316

l Gateway flow concepts on page 340

Composition, deployment, executionA flow is an exchange of business data between business applications or partners. You create flows in Central Governance and deploy them. Flows are triggered at the system level.

Flow compositionA flow is comprised of the following elements:

l A name.

l Optionally, tags and a description.

l Optionally, contact information about the business owner of the flow.

l Information about the source that owns the data being transferred. You can select as the source applications, application groups, partners, or unmanaged products. When the source is a business application, it must be associated with a registered product. In the Transfer CFT case, the flow definition includes transfer and file properties, processing rules and integration information.

l Information about the target that receives the data being transferred. You can select as the target applications, application groups, partners, or unmanaged products. When the target is a business application, it must be associated with a product. In the Transfer CFT case, the flow definition includes transfer and file properties, processing rules and integration information.




l Information about relays, or hubs, if they are part of the flow. A relay1 can be a registered product or an unmanaged product2.

l The protocols used for the exchange between each segment: source-relay, relay-relay, relay-target.

Flow deployment and executionTypically, a flow runs automatically, but can be run manually by executing a command on the products in the flow. For example, running the SEND command on Transfer CFT.

In the case of Transfer CFT, the flow definition:

l Might override some Transfer CFT configuration values, such as default processing scripts, during flow execution.

l Uses some network configurations that must be set in the Transfer CFT configuration. For example, all Transfer CFT have the following settings in the network system configuration: Interface=Any, PeSIT/No encryption.

Deploying a flow does not change the configurations of the products involved in the flow.

Direction in flowsDirection indicates the initiator of a file transfer in a flow, which can have multiple way points where direction changes. Direction is set in the protocol, and can be set differently in multiple places in flows with multiple protocols.

In the simplest flow, there is only the sender and receiver and the protocol for the transfer. The initiator of the transfer is configured in the protocol as:

l Sender pushes file. The sender is the initiator of the transfer request. The sender is the client and the receiver acts as the server.

or

l Receiver pulls file. The receiver is the initiator of the transfer request. The receiver is the client and the sender acts as the server. The receiver's request triggers the sender to send the file.

A more complex flow might specify one or more relays between the sender and receiver. For example:

Source > Relay 1 > Relay 2 > Target

Direction in this flow is set in three places, as indicated in the following examples:

1A relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product.2Unmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that cannot register in Central Governance or third-party products.



l Protocol between source and relay 1. Direction = Sender pushes file.

l Protocol between relay 1 and relay 2. Direction = Sender pushes file.

l Protocol between relay 2 and target. Direction = Receiver pulls file.

Direction = Sender pushes fileDirection = Sender pushes file describes a flow where a sender sends one or more files to a receiver.

Business scenarioThe inventory management application receives reports from all warehouses about stock levels. It generates a file daily containing consolidated information on product availability. The inventory management application sends the file to the product catalog application.

Flow definition 1. Add source and target applications. The source is the inventory management application. The

target is one or more warehouse applications.

2. Optionally, edit the flow definition properties for the source and target.

3. Click Protocol between the source and target. Use Sender pushes file as the direction and set PeSIT as the protocol.

4. Save and deploy the flow.



Direction = Receiver pulls fileDirection = Receiver pulls file describes a flow where the receiver requests one or more files from a sender.

Business scenarioThe inventory management application receives reports from all warehouses about stock levels. It generates a file daily containing consolidated information on product availability. The product catalog application requests the file, which the inventory management application sends in response.

Flow definition 1. Add source and target applications. The source is one or more warehouse applications. The

target is the inventory management application.


3. Click Protocol between the source and target. Set Receiver pulls file as the direction and PeSIT as the protocol.


Flow lifecycleStatuses are displayed on the Flows and flow detail pages during the phases of a flow’s lifecycle.

The user interface uses two date formats for status messages:


l When today: <Status> at <time> today

l When a past day: <Status> on <date>

PhasesThe following describes each phase in a flow’s lifecycle. All of the following examples use the today message format.

Add flowAdd a flow. If the flow is not complete, the status is Saved at <time> today. If the flow is defined fully , the status is Saved at <time> today, not deployed. The flow definition is saved in Central Governance.

Deploy flowDeploying a flow pushes the definition saved in Central Governance to products involved in the flow. The following statuses are possible during deployment.

Deploying since <time> todayDisplayed while the deployment is in progress. Next to the status are details on the deployment status on all products:

l Number of products where the flow is being deployed

l Number of products where the flow is deployed successfully

l Number of products where the flow failed to deploy

You can click a link to access details of the deployment.

Deployed at <time> todayDisplayed after the flow is deployed to all systems. Next to the status are details on the deployment status on all products:

l Number of products where the flow is deployed successfully

l Number of products where the flow failed to deploy

You can click a link to access details of the deployment.

Edit flowEdit a flow that was deployed previously and save it. The status is Saved not deployed. Note that if you only change the details or contact of the general information section, the status does not change because this information is not pushed to products. For example, if you edit the flow

description, the status does not change. Depending on the type of change, the flow might be deployed to one or all of the products involved.

Also, if the flow was deployed previously and then edited, the last deployment status is displayed in the status of the flow page. For example, Saved at <time>, not deployed (Last deployment: 2 deployed). You can click the link for details of the previous flow deployment.

During modification, a flow can become incomplete for deployment. For example, all sources are removed or a protocol is not yet defined or all targets are removed. In these cases, when saving the flow the status becomes Saved at <time> today.

Remove flowRemoving a flow removes it from Central Governance. If the flow is deployed on a product, removing it also removes the flow definition from the product.

Likewise, removing a product from a flow also removes it from the flow definition when the flow is deployed.

The following statuses are possible while removing a flow.

Removing since <time> todayDisplayed while the removal is in progress.

Removed at <time> todayDisplayed after the remove flow process stopped but failed to remove on one or more products. Once the problem is corrected, you can attempt to remove flow again, but the flow can no longer be edited. Next to the status are details on the remove status on all products:

l Number of products where the flow is removed successfully

l Number of products where the flow failed to remove

You can click a link to access details of the deployment. No dedicated status is available once the flow is fully removed.

Business scenarioThe following table illustrates the flow phases and the status changes that occur in a store-to-corporate business use case. Multiple stores in different regions must exchange files with the product catalog application at corporate headquarters. All of the examples use the today message format.

Business need Flow status before

User action Flow status after

All stores must be able to exchange files with the corporate application in a common way

Create flow Saved at <time> today, not deployed

Save time and money by deploying the flow to all stores at one time


Deploy flow Deployed at <time> today

Due to expansion into new region, add stores exchanging with the corporate application


Edit flow to add new stores

Saved not deployed

Save time and money by deploying the flow to all new stores at one time

Saved not deployed



Remove stores from groups


All stores must be able to exchange files with the corporate application in a common way

Create flow; all store groups not defined


Ensure all stores assigned to regional groups for ease of management


Edit flow; flow definition complete


Save time and money by deploying the flow to all stores at one time



Due to expansion into new region, add a new application group for the new stores exchanging with the corporate application


Edit flow to add new application group to the source

Saved not deployed

Save time and money by deploying the flow to all new stores at one time

Saved not deployed


Business need Flow status before

User action Flow status after


Remove stores from application groups; flow is not modified


Communication profilesA communication profile contains the technical details for making connections between clients and servers to transfer data. The two types of profiles are based on the roles of senders and receivers in file transfers.

l A server communication profile contains details for a client to transfer data via a protocol to the sender or receiver that acts as a server.

o The sender acts as a server when it publishes files for the receiver.

o The receiver acts as a server when it receives files pushed by the sender.

l A client communication profile contains details for the sender or receiver to connect via a protocol to the server.

o The sender acts as client when it pushes files to the receiver.

o The receiver acts as a client when it pulls files from the sender.

PeSIT, which supports acknowledgments, also must have communication profiles for acknowledgments to enable sending receipts or ACKs when requested.

Communication profiles are used in flow segments between source and target, source and relay, relay and relay, and relay and target. The user interface prompts when communication profiles are required.

Registered products, unmanaged products and partners own server communication profiles. The following describes how to view the communication profiles of these objects.

Products

Click Products on the top toolbar, click the name of a product and click Configuration. For SecureTransport and Gateway the profiles are listed under Server Communication Profiles. For Transfer CFT the profiles are listed under Protocols.

Unmanaged products

Select Products > Unmanaged Products and click the name of an unmanaged product. The profiles are listed under Protocol.

Partners

Select Partners on the top toolbar and click the name of a partner. The profiles are listed under Server Communication Profiles.



Client communication profiles only are designated in flow definitions. When a flow is removed, any client communication profiles within it also are removed.

Applications do not own communication profiles. They inherit the profiles of their associated products.

Relays in a flowA relay is a product used to route a file from a source to a target or another relay. A relay can push the files it receives to the next application or product in the flow, which is the target or another relay. It also can pull files from the source or another relay in the flow.

You can define multiple relays in a flow. For example, a bank's branches in the United States must send files to its branches in France. The files are transferred through a central relay in the United States to a central relay in France, which sends the files to the branches.

The following are reasons for using relays.

l Reduce network complexity and cost. If multiple groups of stores are sending files to a corporate system, all files can pass through the relay to corporate using a single network connection. Also, if there are multiple regional networks, you can route traffic through a regional hub system that acts as a relay and sends files on to another regional hub, which then distributes files to one or more targets.

l Simplify tracking of flows and simplify identifying and resolving problems. Using Central Governance monitoring, you can track a flow from source to target through one or more relays.

For more information see Transfer CFT as relay in flows on page 323, Gateway as relay in flows on page 340, and SecureTransport as relay in flows on page 317.

Flow identifiersFlow identifiers are defined at each step in a flow when files are transferred via PeSIT, as the following illustrates.

In the graphic, a partner is an external partner, ST represents an instance of SecureTransport and CFT represents an instance of Transfer CFT.



When deploying to Transfer CFT, flow identifiers are used to set the name of the send template and receive template. This identifier is used when you trigger a transfer on PeSIT: idf parameter. A flow identifier is called an IDF1 in Transfer CFT.

The flow identifier is defined at each step of the flow only for PeSIT for each sender-receiver pair. A flow identifier is unique across all flows, but the same flow identifier can be used multiple times in the same flow. In store-and-forward2 cases, the identifier must be the same all along the store-and-forward path.

The following illustrates how identifiers can be set in different flows.

Flow patternsYou can have many types of flow patterns for internal file transfers between senders and receivers. Most of the patterns described in the following topics are for flows where direction is set as sender pushes file. However, you can implement these as receiver pulls file.

Internal flows describe file transfers between applications.

Relays are Axway products or unmanaged products3.

The following outlines the types of flow patterns.

1An IDF is a model file identifier, or file identifier, in Transfer CFT.2Store-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).3Unmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that cannot register in Central Governance or third-party products.



1. Internal flows

a. Point to point (no relay)

l One to one

l One to many

l Many to one

b. Via relays

l One to one

l One to many

l Many to one

2. External flows

In addition, external flows can have one-to-one, one-to-many or many-to-many patterns.

a. Inbound

b. Outbound

c. Partner to partner

Internal flow: One to oneThe one-to-one pattern describes a flow where a single source application sends one or more files to a single target application.

Business scenario 1The inventory management application receives reports from all warehouses about stock levels. It generates a file daily containing consolidated information on product availability. It sends the file to the product catalog application.



Flow definition 1. Add the application inventory management system as the source and the application product

catalog system as the target.


3. Edit the protocol between the source and target and set PeSIT as the exchange protocol.


Business scenario 2The inventory management application receives reports daily from all warehouses about stock levels. It generates a file daily containing consolidated information on product availability. The product catalog application requests the file, which the inventory management application sends in response.

Flow definition 1. Add the application product catalog system as the source and the application inventory

management system as the target.


3. Edit the protocol between source and target and set Receiver pulls file as the direction and PeSIT as the exchange protocol.




Internal flow: One to manyThe one-to-many pattern describes a flow where a single source application sends a file to multiple target applications.

Business scenarioThe product catalog application generates a file daily describing products and their prices. It sends the file to all stores nightly so stores have the updated information before opening in the morning.

The product catalog application uses a broadcast list to send the file to all stores at once. See Transfer CFT broadcast and collect on page 336.

Flow definition 1. Add the product catalog system application as the source.

2. Add applications corresponding to all stores as the targets. Optionally, you can add the store applications as a group. See Application groups on page 279.

3. Edit the protocol between source and target and set PeSIT as the exchange protocol.

4. To use a broadcast list, edit source transfer properties and enable the broadcast list. Specify the name of the list and the action to take if a target is unknown at the time of the transfer.

5. Optionally, edit source file properties.



6. Optionally, edit source processing scripts to specify how the scripts are applied to the broadcast list.

7. Optionally, edit target transfer properties and processing scripts.


Internal flow: Many to oneThe many-to-one pattern describes a flow where multiple source applications send a file to a single target application.

Business scenarioThe store applications generate and send a daily sales report to the product catalog application at the end of each business day. The product catalog application might use the data to generate and send files to the inventory management application. That application in turn might notify logistics and warehouse applications whether store inventory levels are low and need restocking.

Flow definition 1. Add applications corresponding to all stores as the sources. Optionally, you can add the store

applications as a group. See Application groups on page 279.

2. Add the product catalog system application as the target.

3. Edit the protocol between source and target and set PeSIT as the exchange protocol.



4. Optionally, edit the flow definition properties for the source.

5. Optionally, edit target file properties and processing scripts.


Internal flow: One to one via relayThe one-to-one via relay pattern describes a flow where a single source application sends one or more files to a single target through a relay.

Only the use of a relay1 makes this pattern different than the one-to-one pattern.

Business scenarioThe inventory management application receives reports from all warehouses about stock levels. It generates a file daily containing consolidated information on product availability. It sends the file to the product catalog application through a relay. The relay is Transfer CFT.

Flow definition 1. Add the application inventory management system as the source and the application product

catalog system as the target.


3. Add a relay.

4. Edit the protocol between the source and relay and set PeSIT as the exchange protocol.

5. Edit the protocol between relay and target and set PeSIT as the exchange protocol.


1A relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product.



When used as relay, if the direction of the flow is push for source-relay and relay-target, Transfer CFT uses store and forward by default for transfers. See Direction in flows on page 296.

Internal flow: One to many via relayThe one-to-many via relay pattern describes a flow where a single source application sends a file to multiple targets through a relay.

Only the use of a relay1 makes this pattern different than the one-to-many pattern.

Business scenarioThe product catalog application generates a file daily describing products and their prices. It sends the file to each store nightly so the stores have the updated information before opening in the morning. The relay is Transfer CFT.

The product catalog application uses a broadcast list to send the file to all stores at once. See Transfer CFT broadcast and collect on page 336.




Flow definition 1. Add the product catalog system application as the source.

2. Add applications corresponding to all stores as the targets. Optionally, you can add the store applications as a group. See Application groups on page 279.

3. Add a relay.



6. To use a broadcast list, edit source transfer properties and enable the broadcast list. Specify the name of the list and the action to take if a target is unknown at the time of the transfer.

7. Optionally, edit source file properties.

8. Optionally, edit source processing scripts to specify how the scripts are applied to the broadcast list.

9. Optionally, edit target transfer properties and processing scripts.


Internal flow: Many to many via relayThe many-to-many via relay pattern describes a flow where multiple source applications send a file to multiple target applications through a relay.

Business scenarioThe store applications generate a daily sales report at the end of each business day. They send the files nightly to the product catalog and accounting management applications. The relay is Transfer CFT.



Flow definition 1. Add applications corresponding to all stores as the sources. Optionally, you can add the store

applications as a group. See Application groups on page 279.

2. Add the product catalog and accounting management applications as the targets. Optionally, you can add both applications as a group. See Application groups on page 279.

3. Optionally, edit the flow definition properties for the sources and targets.

4. Add the relay.




External flow: InboundThe inbound pattern describes a flow where a partner uploads a file and the file is routed to an application.



Business scenarioPartner 1's SAP FI application must receive payments from partner 2.

Flow definition 1. Add partner 2 as the source and the SAP FI application as the target.


3. Add a relay. This can be SecureTransport.

4. Edit the protocol between source and relay, setting any protocol as the exchange protocol.

5. Edit the protocol between the relay and target, setting PeSIT as the exchange protocol.


In this example you can change the directions between source-relay and relay-target. One or both of the following are possible:

l The relay can request files from partner 2.

l The SAP FI application can request files from the relay.

The flow can have multiple partners as sources. For example, two partners could send data to partner 1.

External flow: OutboundThe inbound pattern describes a flow where an application uploads a file that is routed to a partner

Business scenarioPartner 1 must send an invoice to partner 2. Partner 1's SAP-FI application uploads the invoice to SecureTransport and the file is routed to partner 2.



Flow definition 1. Add the SAP FI application as the source and partner 2 as the target.



4. Edit the protocol between source and relay and set PeSIT as the exchange protocol.

5. Edit the protocol between relay and target and set any protocol as the exchange protocol.



l The relay can request files from the SAP FI application.

l Partner 2 can request files from the relay.

The flow can have multiple partners as targets. For example, two partners could receive data from partner 1.

External flow: Partner to partnerThe partner-to-partner pattern describes a flow where a partner uploads a file that is routed to another partner.

Business scenarioPartner 2 receives orders from partner 1 that must be sent to partner 3. Partner 1 uploads the orders to partner 2's SecureTransport and the file is routed to partner 3.



Flow definition 1. Add partner 1 as the source and partner 3 as the target.



4. Edit the protocol between source and relay and set any protocol as the exchange protocol.

5. Edit the protocol between relay and target and set any protocol as the exchange protocol.



l The relay can request files from partner 1.

l Partner 3 can request files from the relay.

The flow can have multiple partners as sources and targets.


21 SecureTransport flow concepts

The following topics describe using SecureTransport in flows.

SecureTransport as source in flowsWhen used as the source in a flow, SecureTransport picks up files made available by an internal application and sends them, directly or via relays, to other applications or external partners. The internal application moves files into a directory local to SecureTransport. SecureTransport monitors the application directory according to an implicit or explicit scheduler, selects files matching a filter and sends the files.

You define receive, file processing and send properties in flows when SecureTransport is the sender.

l Receive properties contain the folder monitoring properties for how SecureTransport scans the application directory.

l File processing properties are configured the same as when SecureTransport is a relay.

l Send properties depend on the exchange protocol and direction between SecureTransport and the next participant to the flow.

When using flow patterns where SecureTransport is the source or target, you can have only one application linked to the source SecureTransport or target SecureTransport. That is, you cannot have multiple applications as the source or as the target with SecureTransport.

Business scenarioThis scenario describes a one-to-one flow pattern where SecureTransport is the source. SecureTransport has folder monitoring enabled to retrieve files from an internal orders application. After receiving the file, SecureTransport pushes it to the external partner, which is the flow target.



Flow definition 1. Add the orders application and associate it with SecureTransport.

2. Add a flow, using SecureTransport as the source and the partner as the target.

3. Configure SFTP as the protocol between the source and target.

4. Edit the flow properties for the source.

5. Save and deploy the flow

SecureTransport as relay in flowsSecureTransport can be used as relays in external and internal flows, but use in external flows is more common.

See SecureTransport fields in flows on page 375 for property field descriptions.

OverviewIn external flows:

l Partners can send files to applications via SecureTransport relays.

l Applications can send files via SecureTransport relays to partners.

l Atypically, partners can send files via SecureTransport relays to other partners.

In internal flows, applications can send files via SecureTransport relays to other applications.

As a relay, SecureTransport can receive files directly from the sender or initiate the request by pulling files from the sender. SecureTransport can push files to a receiver or it can publish received files that a receiver pulls.

Flow properties you define for SecureTransport as a relay are receive, file processing and send properties.

Receive properties depend on the protocol and direction definition configured before the SecureTransport relay. Receive properties also depend on the protocol and direction definition configured after the SecureTransport relay. If you change the protocol or direction in the flow, different properties are displayed in the user interface. For example:

l When SecureTransport pulls files from a sender, you can enable a scheduler to trigger the pull. (The scheduler is not available when the sender pushes files to SecureTransport.)

l When SecureTransport pushes files to a receiver via SFTP, you must define the remote directory of the receiver. (Over PeSIT the remote directory is not specified in SecureTransport.)



Flows defined in Central Governance and deployed on SecureTransport use advanced routing1 for routing files from senders to receivers.

When used as a relay in PeSIT flows, SecureTransport does not use store-and-forward2 explicitly for transfers. The sender sends files to SecureTransport, which routes the files to receivers. If store-and-forward was explicit, the sender would send files to the receiver directly.

Relay examplesThe following scenarios describe one-to-one flow patterns where SecureTransport is used as a relay3.

Business scenario 1An internal application sends orders to an external partner via a relay. The source pushes files to SecureTransport, which sends to the partner.

Flow definition 1. Add the orders application as the source and the partner as the target.


3. Add SecureTransport as the relay.


5. Edit the protocol between relay and target.

6. Edit the flow definition properties for the relay.


1In SecureTransport, advanced routing is an intelligent routing engine enabling flexible provisioning of new data flows, creating diverse patterns for moving data among parties.2Store-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).3A relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product.



Business scenario 2An internal application sends orders to an external partner via a relay. SecureTransport pulls files from the source and then sends to the partner.




4. Edit the protocol between the source and relay and set PeSIT as the exchange protocol and the direction as receiver pulls file.




Business scenario 3An internal application sends orders to an external partner via a relay. The source pushes files to SecureTransport, which pushes to the partner.






4. Edit the protocol between the source and relay and set PeSIT as the protocol.

5. Edit the protocol between relay and target and set the exchange protocol.



Business scenario 4An internal application sends orders to an external partner via a relay. The source pushes files to SecureTransport, and the partner pulls the files from SecureTransport.





5. Edit the protocol between relay and target and set the exchange protocol and the direction as receiver pulls file.



Business scenario 5A partner sends invoices to an internal application via a relay. The partner pushes files to SecureTransport, which sends the files to the application.



Flow definition 1. Add the partner as the source and the orders application as the target.

2. Optionally, edit the flow definition properties for the target.


4. Edit the protocol between the source and relay and set the exchange protocol.




As SecureTransport is the relay in this example, you can change the protocol directions between source-relay and relay-target.

SecureTransport as target in flowsWhen used within an application as the target in a flow, SecureTransport pushes the files received, directly from partners or other relays, to a directory where an internal application has access. SecureTransport can create the directory or rename received files.

You define receive, file processing and send properties in flows where SecureTransport is the receiver.

l Receive properties depend on the exchange protocol and direction between SecureTransport and the preceding participant in the flow.

l File processing properties are configured the same as when SecureTransport is a relay.

l Send properties have information about the directory where files are pushed and settings on possible post-sending actions.

When using flow patterns where SecureTransport is the source or target, you can have only one application linked to the source SecureTransport or target SecureTransport. That is, you cannot have multiple applications as the source or as the target with SecureTransport.

Business scenarioThe following scenario describes a one-to-one flow pattern where SecureTransport is the target. SecureTransport receives from a partner an invoice that must be moved to a folder the invoice application can access.



Flow definition 1. Add the invoice application and associate it with SecureTransport.

2. Add a flow, using the partner as the source and the application invoice application as the target.


4. Edit the flow properties for the target.



22 Transfer CFT flow concepts

The following topics describe using Transfer CFTs in flows. Central Governance uses the Copilot WebService to deploy flows to Transfer CFTs.

Transfer CFT as relay in flowsA Transfer CFT relay in a flow can receive a file from a source and transmit it to a target or to another relay.

See Transfer CFT fields in flows on page 423 for field descriptions.

OverviewWhen you create a Transfer CFT relay in a flow, by default the store-and-forward1 mode is enabled. Some business scenarios, however, require the relay to have different properties than the source or the target. To achieve this configuration, you can disable store and forward and customize the relay definition, as described in Relay without store and forward on page 325.

Relay using store and forward A Transfer CFT relay with store and forward mode set to Enable (default) can only receive and push files to the next relay or target exactly as they were received from the source or previous relay. During the transfer, the relay does not perform post-processing, error processing, or acknowledgment processing. Additionally, you cannot set transfer or file properties for the relay as receiver or sender. In this mode, when the Transfer CFT relay receives a transfer, it creates a temporary file that is deleted after the file is sent to the target or next relay.

PrerequisitesTransfer CFT store and forward relays require:

l The flow identifier of the protocol before the relay should coincide with the flow identifier of the protocol after the relay.

l There must be at least three consecutive segments in the flow, where PeSIT is the protocol and the file direction is source pushes file.

1Store-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).



Note If the store and forward mode is set to Enable, but the relay does not meet the conditions for acting in store and forward, the receive and send properties of the relay are not displayed unless the user explicitly disables the store and forward in the user interface.

Scenario with Transfer CFT as store and forward relayThe three consecutive segments of the flow are illustrated in the shaded parts of the graphic, and include the Transfer CFT relay. Note that there can be several store-and-forward blocks in the same flow.

An unmanaged product can be part of the store-and-forward path, as shown in the diagram. An unmanaged product used as a relay is considered to be in store and forward mode, and does not interrupt the path. On the other hand, an instance of SecureTransport that is a registered product and that is used as a relay in a flow cannot be in the path.

The unshaded parts of the graphic are not part of the store-and-forward path because:



l The protocol is SFTP between Partner 1 and SecureTransport 1.

l The protocol is PeSIT between the unmanaged product 1 relay and Partner 2, but the direction is receiver pulls file.

Relay without store and forwardIf your business use case requires the relay to have different properties than the source or the target, you can disable store and forward option.

After selecting the Transfer CFT as relay, set Store and Forward mode to No to disable. The relay then has send and receive properties, just as any source or target application linked to a Transfer CFT does. This means that the relay can alter the file it receives before sending it to the destination.

A Transfer CFT relay with store and forward disable can receive files or pull files from a previous relay or source and push files or allow the next relay or target to pull files from it.

Transfer CFT flow transfer modesThe following table lists the Transfer CFT flow transfer modes by direction. Transfer CFT can push files to next receiver in the flow or pull files from the sender.

Transfer mode Direction

Send a file – closed mode on page 326 Sender pushes

Send a file – open mode on page 327 Sender pushes

Receive a file – explicit provisioning on page 329 Receiver pulls

Receive a file – implicit provisioning on page 330 Receiver pulls

Send a group of files – grouped on page 328 Sender pushes

Send a group of files – file-by-file on page 329 Sender pushes

Receive a group of files – grouped, explicit provisioning on page 331 Receiver pulls

Receive a group of files – file-by-file, implicit provisioning on page 331 Receiver pulls

Transferring groups of filesWhen defining a flow with Transfer CFT in Central Governance, you can specify a group of files to send in source file properties by selecting the Multiple option in the Source field.

Specify a set of files or a directory in the File name sent field:



l Use wildcard characters in the file name. The asterisk (*) is used for multiple characters and the question mark (?) is used for a single character.

o /mydir/*.txt

o /mydir/a?.*

l Specify a directory name.

o mydir

Or, specify a file containing the list of files to be transferred in the File list field:

l myfile

Group transfer modesThere are two processing modes when sending groups of files:

l File-by-file: Files are transmitted individually. This is the default mode. You can change the mode in the transfer processing section of the Transfer CFT configuration.

l Grouped: Files are transmitted as a group when possible. On the source, a single file (archive) is created from the group of files. On the target, there is a directory where the archive (working file) is received. Files are automatically extracted from the working file into this directory.

The mode used depends on the operating system of the Transfer CFTs involved in the flow and the transfer processing mode configuration of each. When you use the grouped mode, the files are transferred as a group only when the source and target systems have the same operating system. If the operating systems are different, the transfer is sent file-by-file.

Transfer mode: Sender pushes filesThe following topics describe source-initiated transfer modes in flows involving Transfer CFT.

PrerequisiteThe source and target of the flow are business applications associated with Transfer CFTs. The direction is Sender pushes file in the definition of the protocol after the source.

Send a file – closed modeThe source defines the location of the file to send. The target defines the file to receive.


Source file properties l Select the Single option.

l Optionally, in the Filename field , specify the full path name of the file to send. If you don't specify a value, it can be set at transfer execution time. If you do set a value, you can override it at transfer execution time.

Target file propertiesSpecify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. The default value is pub/&IDF.&IDTU.&FROOT.RCV. This is a required field because the value cannot be set at transfer execution time.

Transfer execution commandOn the Transfer CFT source, the command syntax to initiate the transfer is:

CFTUTIL send PART=<CFT_target>, IDF=<flow_ID>[, fname=<source_filename>]

Note The fname parameter is required if a value was not supplied in the Path field in the source file properties definition.

Send a file – open modeThe source defines the location of the file to send and the file name on the target.


l In the Filename field, optionally specify the full path name of the file to send. If you don't specify a value, it can be set at transfer execution time.

l In the File name sent field, specify an existing file path on the target and the desired file name on the target.

Target file propertiesSpecify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. Best practice is to set this value to &NFNAME.


CFTUTIL send PART=<CFT_target>, IDF=<flow_ID>[, fname=<source_filename>, nfname=<target_filename>]

In this command, fname represents the file to be sent and nfname matches the filename under which the file is sent to the target. For example:

CFTUTIL send PART=CFT10, IDF=WR1, fname=/home/DS1234.txt,

nfname=DS1234QR.txt

Note The fname parameter is required if a value was not supplied in the Path field and the nfname parameter is required if a value was not supplied in the File name sent field in the source file properties definition.

Send a group of files – groupedThe source defines the group of files to send. Source and target Transfer CFTs must have the same operating system. The source Transfer CFT must be configured to use this mode, which requires setting Transmit files individually to When necessary in the Transfer processing section of the configuration.

Source file properties l Select the Multiple option.

l In the Path field, specify the group of files to send using wildcard characters or a directory name. You can instead specify a file list using the file list field. If you don't specify a value, it can be set at transfer execution time.

l In the Archive name field, specify a value. For example, &IDF.&IDTU.RCV.

Target file properties l In the Filename field, specify the path for the received files. The default value is pub/&IDF.&IDTU.&FROOT.RCV. The path is created if it does not exist.

l In the Temporary file field, specify the name of the temporary archive. The default value is pub/&WFNAME.&IDTU.RCV. If you do not change the default value, pub/&IDF.&IDTU.&FROOT.RCV is created as the directory.


CFTUTIL send IDF=<flow_ID>, PART=<CFT_target>[, fname=<#|@filename>,

wfname=<archive_name>]

Note The fname and wfname parameters are required if they were not set in the target file properties definition. The @ character must precede the file name on Linux and UNIX platforms, and the # character on Windows platforms.

Send a group of files – file-by-file The source defines the group of files to send. Source and target Transfer CFTs have different operating systems, or Transmit files individually is set to Always in the Transfer processing section of the source system configuration.


l In the Path field, specify the group of files to send using wildcard characters or a directory name. If you don't specify a value, it can be set at transfer execution time.

Target file propertiesIn the Filename field, specify the path for the received files. The default value is pub/&IDF.&IDTU.&FROOT.RCV. The path is created if it does not exist.


CFTUTIL send IDF=<flow_ID>, PART=<CFT_target>[, fname=<#|@filename>]

Note The fname parameter is required if it was not set in the target file properties definition.

Transfer mode: Target pulls filesThe following topics describe target-initiated transfer modes in flows involving Transfer CFT.

PrerequisiteThe source and target of the flow are business applications associated with Transfer CFTs. The direction is Receiver pulls file in the definition of the protocol before the target.

Receive a file – explicit provisioningThis mode is for making a file available on the source for a target to pick up.

Source transfer propertiesOptionally, set the Transfer state field to Hold. If you don't specify a value, it can be set at transfer execution time. When the target is the initiator, there is no transfer state option in the source.

l In the Filename field, specify the full path and file name.

Target file propertiesOptionally, specify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. The default value is pub/&IDF.&IDTU.&FROOT.RCV. If you don't specify a value, it can be set at transfer execution time.

Transfer execution commandsOn the Transfer CFT source, the command syntax to initiate the transfer is:

CFTUTIL send PART=<CFT_target>, IDF=<flow_ID>[, state=HOLD]

On the Transfer CFT target, the command syntax to retrieve the transfer is:

CFTUTIL recv IDF=<flow_ID>, part=<CFT_target>[, fname=<received_filename>]

Note The fname parameter is required if a value was not specified in the Filename field in the target file properties definition.

Receive a file – implicit provisioningThis mode is for making a file available for any requesting target to pick up from the source.


l In the Filename field, specify the full path and file name. This is a required field, since the value cannot be set at transfer execution time.

Target file propertiesOptionally, specify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. The default value is pub/&IDF.&IDTU.&FROOT.RCV. If you don't specify a value here, it can be set at transfer execution time.

Transfer execution commandOn the Transfer CFT target, the command syntax to retrieve the transfer is:

CFTUTIL recv IDF=<flow_ID>, part=<CFT_target>[, fname=<received_filename>]

Receive a group of files – grouped, explicit provisioningThis mode is for making a group of files available for a target to pick up from the source. The source and target systems must have the same operating system. The source Transfer CFT must be configured to receive in this mode, which requires Transmit files individually set to When necessary in the Transfer processing section of the configuration.


l In the Path field, specify the group of files to be sent using wildcard characters or a directory name. You can instead specify a file list.

l In the Archive name field, specify a value. The default is &IDF.&IDTU.RCV.

Target file properties l Optionally, specify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. The default value is pub/&IDF.&IDTU.&FROOT.RCV. If you don't specify a value, it can be set at transfer execution time.

l Optionally, in the Temporary file field, specify the name of the temporary archive. The default value is pub/&WFNAME.&IDTU.RCV. If you do not change the default value, pub/&IDF.&IDTU.&FROOT.RCV is created as the directory. If you don't specify a value, it can be set at transfer execution time.


CFTUTIL recv IDF=<flow_ID>, part=<CFT_target>[, fname=<dir_for_received_files> ,wfname=<temporary_archive>]

Note The fname parameter and wfname parameters are required if values were not specified in the Filename and Temporary file fields in the target file properties definition.

Receive a group of files – file-by-file, implicit provisioningThis mode is for making a group of files available for any requesting target to pick up from the source. The source and target systems have different operating systems or Transmit files individually is set to Always in the Transfer processing section of the source system configuration

l In the Path field, specify the group of files to send using wildcard characters or a directory name. You can instead specify a file list.

Target file propertiesOptionally, specify a value in the Filename field. The value must contain a path that exists on the target and the file name of the received file. The default value is pub/&IDF.&IDTU.&FROOT.RCV. If you don't specify a value, it can be set at transfer execution time.


CFTUTIL recv IDF=<flow_ID>, part=<CFT_target>[, fname=<dir_for_received_files>, FILE=ALL]


Flow conversion, validationCentral Governance can implicitly convert Transfer CFT legacy flows to Central Governance flows. Central Governance enables you to reuse only IDs of the following objects in legacy flows when Central Governance flows are deployed:

l Send template

l Receive template

l Distribution list

l Partner

In relays, a partner is checked across all partners and distribution lists as well. A relay also can have a distribution list.

Other fields of legacy flows are not migrated automatically to Central Governance flows.

Central Governance flow IDs are validated across legacy flow IDs in saved and deployed statuses. The following tables show what is checked.


Transfer CFT source

Central Governance flow object Legacy flow object

Flow identifier Send template ID

Flow broadcast name Distribution list ID Partner ID

Transfer CFT instance IDs of Transfer CFT target or relay Partner ID Distribution list ID

Transfer CFT target

Central Governance element Transfer CFT object

Flow identifier Receive template ID

Flow collect list Distribution list ID Partner ID

Transfer CFT instance IDs of Transfer CFT target or relay Partner ID Distribution list ID

Transfer CFT relay

Central Governance element

Transfer CFT object

Transfer CFT instance IDs Partner for the Transfer CFTs target and relay partners are available by name.

When conflicts are foundWhen conflicts are found between Central Governance flows and legacy flows, Central Governance displays messages asking users to confirm or cancel deployment actions.

l If the user confirms, reused objects are no longer accessible through the legacy flows user interface in Central Governance. Meanwhile, Central Governance deploys the flow on Transfer CFT, which updates the objects on Transfer CFT.



l If the user does not confirm, the action to deploy the Central Governance flow on Transfer CFT is canceled.

See Transfer CFT legacy flows on page 457 for more information about how Central Governance manages legacy flows in Transfer CFT.

Transfer CFT store and forwardThis topic describes how Transfer CFT store-and-forward1 paths are calculated in Central Governance flows.

To disable store and forward, see Transfer CFT as relay in flows on page 323.

Flows with store and forward relaysThe following example describes a store-and-forward case where the flow is Transfer CFT 1 > Transfer CFT 2 > ... > Transfer CFT n.

First Transfer CFTOn the first Transfer CFT of a store-and-forward block:

l A partner definition (CFTPART) is generated for the last Transfer CFT in the block (target). Some parameters in CFTPART also are modified as:

o IPART2 = identifier of the first next relay just after the first Transfer CFT

o OMINTIME3 = 0

o OMAXTIME = 0

l A partner definition is generated for the first next relay

RelayOn each intermediary relay:

l A partner definition is generated for the last Transfer CFT in the block (target) and some parameters in CFTPART also are also modified if the next Transfer CFT is an intermediary and not the target:

1Store-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).2In Transfer CFT, the IPART is the local identifier of an intermediate partner. The identifier must correspond to the ID parameter of a CFTPART object. This parameter is involved in the file store and forward or backup mechanism.3In Transfer CFT, the IMINTIME, IMAXTIME, OMINTIME and OMAXTIME parameters of the CFTPART command define the time slot for communicating with a partner for incoming and outgoing calls.


o IPART = identifier of the first next Transfer CFT

o OMINTIME = 0

o OMAXTIME = 0

l A partner definition is generated for the previous Transfer CFT

l A partner definition is generated for the next Transfer CFT if the next is not the target

l If an acknowledgment is defined on the protocol just before this relay and if the Transfer CFT just before this relay is not the Transfer CFT source, a partner definition is generated for the first Transfer CFT in the block:

o IPART = identifier of the previous Transfer CFT

o OMINTIME = 0

o OMAXTIME = 0

Transfer CFT targetOn the Transfer CFT target (the last Transfer CFT in the store-and-forward path), if there is an acknowledgment defined on the protocol just before this Transfer CFT, a partner definition is generated for the Transfer CFT source:

l IPART = identifier of the previous CFT

l OMINTIME = 0

l OMAXTIME = 0

A partner definition is generated for the last previous relay.

Transfer CFT partner templateWhen a flow using Transfer CFTs is deployed, Central Governance deploys on each Transfer CFT the definition of the partners defined in the flow. There are two Transfer CFT partner objects involved: CFTPART and CFTTCP.

l For each CFTPART, Central Governance sets values for the fields ID, NRPART, NRPASSW, NSPART, NSPASSW, PROT, SAP, SSL ( if mutual authentication is used)

l For each CFTTCP, Central Governance sets values for the fields ID, CLASS, HOST.

All the other fields of CFTTCP and CFTPART have the default values.

You can overwrite the following fields by editing the com.axway.cmp.cgcft-default.cfg file at <install directory\runtime\com.axway.nodes.ume_<UUID1>. Changing this file does not require restarting Central Governance. Changes apply only to flows defined after the file is edited.


Transfer CFT field

Corresponding property in Central Governance configuration file

Central Governance value

Default Central Governance value if property is not set

CFTPART - ID Name of the Transfer CFT partner.

%HOSTNAME% (product host as it appears in the product list)

STRING max_length=32

CFTTCP – CNXIN, CNXOUT, CNXINOUT

cft.partner.cnxin

cft.partner.cnxout

cft.partner.cnxinout

0..1000 CNXIN = '64', CNXOUT = '64', CNXINOUT = '64'

CFTTCP – RETRYW, RETRYM, RETRYN

cft.partner.retryw

cft.partner.retryn

cft.partner.retrym

0..32767 RETRYW = '7', RETRYM = '12', RETRYN = '6',

The default Central Governance value is used if any property or value is missing.

File content example:

cft.partner.id=%HOSTNAME%

cft.partner.cnxin=32

cft.partner.cnxout=32

cft.partner.cnxinout=64

cft.partner.retryw=5

cft.partner.retryn=3

cft.partner.retrym=6

Transfer CFT broadcast and collectBroadcast and collect in Transfer CFT are functions for sending files to multiple targets and receiving files from multiple sources with a single request.

BroadcastBroadcasting a file is similar to using a distribution list. To use a broadcast list, the source must be an business application associated with Transfer CFT, and it must push files to the receiver.



For example, a file such as an updated product list, can be generated by a product catalog application and transmitted to multiple stores. In this scenario, the product catalog application is the source in the flow and the store applications are the targets.

When you enable broadcasting in source transfer properties, you also specify the name of the broadcast list. This name represents a logical list of all the targets defined in the flow. You can also define what occurs if a target is unknown. In the processing scripts definition, you can specify how the scripts are applied to the broadcast list with the unknown target option.

When the transfer of a single file is executed, one SEND command sends the file to all defined targets. The transfer list contains a record for the main SEND command and records for each target. When multiple files are transferred, the number of records in the transfer list depends on additional factors, such as whether the transfer is done in grouped or file-by-file mode.

When each transfer is completed, the state of the record in the transfer list changes to either the transferred (T) state or the executed (X) state, if processing scripts were executed after the transfer.

When all the transfers to all targets are successfully completed, the record associated with the main SEND command changes to the transferred (T) or the executed (X) state.

CollectCollecting a file is the inverse of a broadcast list. To use a collect list, the target must be an business application associated with Transfer CFT, and it must pull files from the sender.

For example, each store generates a file containing daily sales information. These files are used to update an inventory management system. In this scenario, the inventory management system is the target in the flow and the stores are the sources.

When you enable collection in target transfer properties, you also specify the name of the collect list. This name represents a logical list of all the sources defined in the flow. You can also define what occurs if a source is unknown. In the processing scripts definition, you can specify how the scripts are applied to the collect list.

When the transfer of a single file is executed, one RECV command requests the file from all defined sources. The transfer list contains a record for the main RECV command and records for each source. When multiple files are transferred, the number of records in the transfer list depends on additional factors, such as whether the transfer is done in grouped or file-by-file mode.

When each transfer is completed, the state of the record in the transfer list changes to either the transferred (T) state or the executed (X) state, if processing scripts were executed after the transfer.

When all the transfers from all sources are successfully completed, the record associated with the main RECV command changes to the transferred (T) or the executed (X) state.

Transfer CFT bandwidth allocationCentral Governance sets the global incoming and outgoing transfer rates when Transfer CFT registers. You can manage these rates using policies or individual Transfer CFT definitions.



You can use the bandwidth allocation fields to manage data rates and the network bandwidth used for incoming and outgoing data in your flows.

Bandwidth allocation is based on the notion of a service class. A service class groups together all of the Transfer CFT services that facilitate data transfers. In Central Governance the transfer services are grouped according to what you define as their business priority: high, medium, or low. For example, when defining a flow you can specify the service class you want to use when executing the flow. For high priority flows you can use the high priority service class. For details see Composition, deployment, execution on page 295.

How allocation worksIn the Transfer CFT configuration page you can distribute the available network bandwidth between these services. When setting values Central Governance scales them to 100 and orders them according to class priority in case the values do not satisfy these conditions. For example, if you specify the following bandwidth allocation:

High 10 percent, Medium 5 percent, Low 11 percent

When you save the settings, the system reallocates the settings as:

High 43 percent, Medium 38 percent, Low 19 percent

By automatically reordering the values, the system ensures there is more bandwidth for high-priority services than for low-priority services.

When Transfer CFT registers, Central Governance detects whether bandwidth allocation is enabled on the Transfer CFTside. It configures the bandwidth allocation between the three service classes (high, medium, low) using the default values.

Central Governance always overwrites the Transfer CFT configuration for bandwidth allocation unless:

l A specific Central Governance property is disabled. If disabled, the Bandwidth Allocation section for Transfer CFT configuration is not available in the Central Governance user interface. The property is:

enableBandwidthThrottling=true

True (enabled) is the default value. The property is in the ume runtime node at /conf/com.axway.cmp.cftum-default.cfg.

or

l The enableBandwidthThrottling property is true and the Transfer CFT configuration fulfills the conditions cos.1 > cos.2 > cos.3 and the total value is 100.

Business scenarioThe following is a business scenario for bandwidth allocation.

Two flows are defined from the product catalog application:



l Flow 1: Product prices - The product catalog application generates a file daily containing products and their prices. The file is sent to each store every night, so updated information is available before each store opens in the morning.

l Flow 2: Products for sale - The product catalog application generates a file daily containing products. The file is sent to the accounting management application to update the list of products for sale.

The product prices file is sent first. The definition of the first flow can ensure it takes a higher bandwidth allocation by setting the value of bandwidth allocation to high.

To enable significantly faster transfer rates for large-file transfers, traveling long distances over high bandwidth networks, you also can enable pTCP network protocol on Transfer CFTs and use it in the flow protocol definition.

Flow 1: Product pricesPrerequisite : Enable bandwidth allocation on the Transfer CFT used by the product catalog application.

1. Add source.

2. Add all targets.

3. Edit source transfer properties. Bandwidth allocation = High.

4. Optionally, edit other source properties.

5. Optionally, edit target properties.

6. Edit protocol definition between source and targets.


Track a copied fileTransfer CFT supports copying a file to a different location without actually sending the file, yet still have the standard Transfer CFT tracking. This enables you to create a copied file, with visibility in Transfer CFT or Central Governance, without using network resources.

However, you must perform the configuration for this in Transfer CFT. For details see the topic "Use a shared disk as the data transfer medium" in the Transfer CFT User Guide.


23 Gateway flow concepts

The following sections describe using Gateway in flows.


Gateway as relay in flowsGateway can be used as a relay1 in external and internal flows, but use in external flows is more common.

OverviewIn external flows:

l Partners can send files to applications via Gateway relays.

l Applications can send files via Gateway relays to partners.

l Atypically, partners can send files via Gateway relays to other partners.

In internal flows, applications can send files via Gateway relays to other applications.

As a relay, Gateway can only receive files directly from the sender (it cannot retrieve from the sender), and can push files to a receiver, or publish received files that a receiver pulls.

Flow properties you define for Gateway as a relay are receive properties, local properties, routing criteria, transfer processing, and send properties.

l Receive properties depend on the protocol configured before the Gateway relay. Local and send properties depend on the protocol and direction definition configured after the Gateway relay. If you change the protocol or direction of the flow, different properties are displayed in the user interface. For example:

o When a receiver pulls files from Gateway, the relay can publish the incoming file with a specific file name.

o When a Gateway pushes files to a receiver via SFTP, you can define the remote directory of the receiver to which files are transferred. (Over PeSIT the remote directory is not specified.)




l Flows defined in Central Governance and deployed on Gateway use a set of routing criteria for routing files from senders to receivers.

l Transfer processing refers to processing actions, such as archiving data, that are performed on incoming or outgoing exchanges.

Relay examplesThe following scenarios describe one-to-one flow patterns where Gateway is used as a relay.

Business scenario 1An internal application sends orders to an external partner via a relay. The source pushes files to Gateway, which sends to the partner.



3. Add Gateway as the relay.





Business scenario 2An internal application sends orders to an external partner via a relay. The source pushes files to Gateway and the partner pulls the files from Gateway.







5. Edit the protocol between relay and target and set the exchange protocol and the direction as receiver pulls file.



Business scenario 3A partner sends invoices to an internal application via a relay. The partner pushes files to Gateway, which sends the files to the application.




4. Edit the protocol between the source and relay and set the exchange protocol.






As Gateway is the relay in this example, you can change the protocol directions between source-relay and relay-target.

Gateway as relay in PeSIT flowsThe following scenarios describe the flow patterns where Gateway is used as a relay1.

Relay examples

Business scenario 4A partner sends invoices to an internal application via a chain of relays, where Gateway is the first one. The partner pushes files to the inbound Gateway, which sends the files to the application, via one or many Transfer CFT relays, called Pivot CFT Relay in the following example.



3. Add Gateway as the first relay after the source.

4. Add other Transfer CFT as relays between Gateway relay and the target application.

5. Select the protocol as PeSIT or SFTP between source and relay and the direction as sender pushes file.

6. Select PeSIT as the protocol and the direction as sender pushes file between Gateway relay and the pivot Transfer CFT relay.




7. Select PeSIT as the protocol and the direction as sender pushes file between the pivot Transfer CFT relay and the target application.

8. Edit the Gateway relay properties.


In this example, Gateway relay initiates a store-and-forward path, with the pivot Transfer CFT as relay.

Business scenario 5An internal application sends orders to an external partner via a chain of relays. The source pushes files to the outbound Gateway, via one or many Transfer CFT relays, called Pivot CFT Relay in the following example. Gateway then sends the file to the partner.



3. Add Gateway as the last relay before the target.

4. Add other Transfer CFTs as relays between the source application and Gateway.

5. Select PeSIT as the protocol and the direction as sender pushes file between the source application and the pivot Transfer CFT relay.

6. Select PeSIT as the protocol and the direction as sender pushes file between the pivot Transfer CFT relay and Gateway relay.

7. Select PeSIT or SFTP as the protocol between Gateway relay and the target and the direction as sender pushes file or receiver pulls file.

8. Edit the Gateway relay properties.


In this example, Gateway relay is the end of a store-and-forward path, with the pivot Transfer CFT as relay.



Store-and-forwardWhen used as a relay in PeSIT flows, Gateway can initiate a PeSIT store-and-forward path or complete it, as shown in the two preceding examples. Gateway as relay does not use native store-and-forward1 mechanism for transfers. The sender sends files to Gateway, which routes the files to receivers, via configuration objects created when deploying the flow from Central Governance. If store-and-forward was explicit, the sender would send files to the receiver directly via Gateway (Gateway would not perform any explicit routing). This is why a PeSIT flow with Gateway as relay is not considered a store-and-forward path.

Relay properties in a PeSIT flowWhen Gateway has a relay role in a PeSIT flow, you can configure the receive properties, the local properties and the send properties for it.

l Receive properties instruct Gateway about the format of the files it receives, so that it can read them. It also specifies how to handle a pre-existing file.

l Local properties instruct Gateway how to store locally the files it receives.

l Routing criteria specify the conditions in which the file is sent to some or all receivers.

l Transfer processing instructs Gateway as to what processing actions, such as executing a PERL script, to perform.

l Send properties instruct Gateway how to format the files before sending them.

Receive and local properties in a PeSIT flow are the same regardless of the flow direction configured before and after the Gateway relay.

The send properties in a PeSIT flow have fields that depends on the flow direction configured between the Gateway relay A relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product. and the target The target is the receiver of the data exchange.:

l When the direction is ‘sender pushes file’, you can specify the protocol file name used to send the file.

l When the direction is ‘receiver pulls file’, you can specify the protocol file name set when publishing the file.

Note When transferring files between Transfer CFT and Gateway, the properties for the file sent and the properties for how the file is received must match. See the parameter recommendations for PeSIT settings when Gateway is receiving files in PeSIT file properties for interoperability on page 422.

1Store-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).



Gateway as relay in SFTP, FTP, or HTTP flowsWhen Gateway has a relay role in an SFTP, FTP or HTTP flow, you can configure the receive properties, the local properties, the routing criteria, transfer processing, and the send properties.

l Receive properties instruct Gateway as to where to store the incoming files. (For non-PeSIT protocols there is no way to enforce which application object to use.)

l Local properties instruct Gateway how to store locally the files it receives.


l Transfer processing instructs Gateway as to what processing steps, such as execute a PERL script, to perform.

l Send properties instruct Gateway how to format the files before sending them and where to send them.

The send properties in an SFTP, FTP, or HTTP flow function differently depending on the flow direction configured between the Gateway relay1 and the target2:

l When the direction is Sender pushes file, you must specify the name of the remote directory where the file has to be sent and the name to give to the sent file.

l When the direction is Receiver pulls file, you must specify the local directory to publish the file, and the name of the published file.

Flows defined in Central Governance and deployed on Gateway use a set of routing criteria for routing files from senders to receivers. Incoming files are routed to receivers based on conditions.

Gateway as target in flowsWhen used with an application as the target in a flow, Gateway pushes files that are received, either directly from partners or other relays, to a directory that an internal application can access. If the directory does not exist, Gateway creates the directory, or renames received files.

You define the following properties in flows when Gateway is the receiver:

l Receive properties depend on the exchange protocol and direction between Gateway and the preceding participant in the flow.

l Local properties that are configured in the same way as when Gateway is a relay when the protocol between preceding participant in the flow and Gateway is PeSIT (otherwise no properties are available for configuration).

l Transfer processing properties are configured the same as when Gateway is a relay.

l Send properties, which have information about the directory where files are pushed and the name under which the files are saved. Note, however, that you can disable this action.

1A relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product.2The target is the receiver of the data exchange.



Send properties Enable

Enable/disable this Send section.

Upload directory

Mandatory

Path where the file will be copied. This path must end with the appropriate Gateway operating system file separator (such as slash), for example /home/user1/destination/.

Upload file as

Name to be given to the copied file. If you leave the field empty, Gateway naming conventions are used.

Note The recommended file separators are:

Unix: /

For example: /home/user1/destination/

Windows: \

For example: C:\destination\

When using flow patterns where Gateway is the target, you can have only one application linked to the target Gateway. That is, you cannot have multiple applications as a Gateway target.

Business scenarioThe following scenario describes a one-to-one flow pattern where Gateway is the target and receives an invoice from a partner. Gateway copies the invoice to a folder that the invoices application can access.



Flow definition 1. Add an invoice application, and associate it with Gateway.

2. Add a flow using the partner as the source and the Invoices Application (application) as the target.


4. Edit the flow properties for the target.


Note When transferring files between Transfer CFT and Gateway, the properties for the file sent and the properties for how the file is received must match. See the parameter recommendations for PeSIT settings when Gateway is receiving files in PeSIT file properties for interoperability on page 422.


24 Defining flows

Review the following prerequisites and outline for defining a flow.

Prerequisites l Products that you intend to participate in the flow have been registered successfully in Central Governance. See Product registration on page 177.

l The following objects have been added in the user interface, as necessary to support the flow:

o Applications, grouped or not. See Applications on page 277.

o Partners. See Partners on page 283.

o Unmanaged products. See Unmanaged products on page 291.

Flow definition outlineThe following outlines tasks for defining a flow. Required and optional steps are identified.

1. Enter general information about the data flow, such as a name. This step is required.

See Add a flow on page 351.

2. Add the source and target. Select whether the source or target is the initiator of the flow. The source is the owner of the data being transferred. The target is the receiver of the exchange. This step is required.

See Add source and target on page 351.

3. If the flow goes through one or more intermediate systems, specify these relay points. This step is optional.

See Add a relay on page 353.

4. Define the protocols between source and target. You also can define protocols between relays and source and target. This step is required.

See Specify the protocol on page 354.

5. If the source is applications or a group of applications associated with Transfer CFTs, you can define the following information about the source: transfer properties, file properties, processing scripts. This step is optional.

See Transfer CFT source fields in flows on page 423.

6. If the target is applications or a group of applications associated with Transfer CFTs, you can define the following information about the target: transfer properties, file properties, processing scripts. This step is optional.


24 Defining flows

See Transfer CFT target fields in flows on page 442.

7. Save the flow or save and deploy the flow. This step is required.

See Save and deploy a flow on page 372.

Manage flowsThis topic describes actions you can perform on flows in the user interface and provides links where appropriate to other topics for more details on some actions.

There are many steps in adding, configuring and editing flows. See Defining flows on page 349 for an outline of tasks.

Flow List pageThe Flow List page is the starting point for performing actions on flows. Click Flows on the top toolbar to open the page. On this page you can:

Add

Click Add flow to add and configure a new flow. See Add a flow on page 351.

Deploy

Click Deploy to send a flow to the registered products defined in the flow. See Save and deploy a flow on page 372.

Remove

Select one or more flows and click Remove to remove them in Central Governance and the flow definition from all registered products where deployed.

Filter

Click Filter to filter the list of flows by name, status and other conditions.

Flow details pageClick the name of a flow on the Flow List page to open a details page for the flow. The page has the flow's name and information, if available, about tags, a description and a contact person.

Deploy

Click Deploy to send a flow to the registered products defined in the flow. See Save and deploy a flow on page 372.


24 Defining flows

Edit

Click Edit to change the flow configuration. If you remove a registered product from a flow, the flow definition also is removed from the product when the flow is redeployed. See Defining flows on page 349 for an outline of tasks.

Copy

Click Copy to add a flow with attributes of the original flow. The copy is identical, except the flow name is appended with Copy<n>, where n is the number of the copy, and a note in the Description field with the name of the original flow.

You can accept or change the default name and description.

Using a copy as the starting point, you can keep or change the original configuration as you want. Best practice is adding copies when you want multiple flows that differ only in details.

Add a flowThe following steps only specify the initial task in adding a flow, which is completing the general information section for a new flow. See Defining flows on page 349 for an outline of all tasks.

1. Select Flows > Add flow.

2. Type a friendly name for the flow. For example, the daily sales data from all the stores in the western region might be named West Daily Sales.

3. Type the identifier of the flow. When the flow is deployed, this value is the flow identifier in the configurations deployed to the systems involved in the flow. For example, the flow identifier for the daily sales data from the western region might be named WR01.

4. In the Details area, you can add tags1 to categorize the flow and a description to differentiate the flow when viewing a long list.

5. In the Link field you can optionally enter a URL to point to an existing page, such as an external html page or documentation located on the server.

6. In the Contact area, you can provide information about the business owner of the flow.

7. Click Save to save the flow or continue defining the flow and save it later.

Add source and targetA flow requires at least one source and one target. However, you can have multiple sources and targets in a flow.

24 Defining flows

Prerequisites l Applications are added and linked to registered products. See Manage applications on page 277.

l Application groups are added and contain at least one application. See Manage application groups on page 280.

l Partners used in flows are added. See Manage partners on page 283.

l Unmanaged products used in flows are added. See Unmanaged products on page 291.

l The required general information has been completed. See Add a flow on page 351.

Steps 1. Open the flow in edit mode, if not already opened.

This might be a partially defined flow you saved previously or an unsaved flow still in the process of being defined.

To open a flow for editing, click Flows on the top toolbar, click the name of a flow and then click Edit.

2. Click Source in the panel on the left side of the page.

3. Select a source type from the drop-down field. Objects you can select are:

l Applications, which are associated with registered products. You can select:

o A single application or multiple applications that are each linked to one instance of Transfer CFT.

o A single application linked to a product other than Transfer CFT. For example, you can select one application linked to SecureTransport, but not two applications linked to SecureTransports.

l Application groups. You can select only application groups containing applications linked to Transfer CFTs.

l Partners.

l Unmanaged products.

For application groups, Central Governance only lets you select groups that contain the same types of products. It does not let you select groups that contain different types of products. For example, if:

l Group 1 contains an application with one Transfer CFT and an application not associated with any product

l Group 2 contains an application with one Transfer CFT and an application with one SecureTransport

l Group 3 contains two applications with one Transfer CFT each

Central Governance only lets you select Group 1 and Group 3.


24 Defining flows

4. After selecting a source type:

l If the source type is applications, select a product type in the drop-down field. The product type corresponds to the type of products for each application selected in the flow. Click Add source to display a list of available applications, with products matching the selected product type. Select one or more applications and click Select as source. Click Select Products to choose the products to involve in the flow for each selected application. By default, all products matching the selected product type are selected. When no product is selected for the application, a warning displays in the notification column. The flow can be saved but cannot be deployed until this warning has been resolved. To remove a source application, select an application and click Remove.

l If the source type is application groups or unmanaged products, click Edit source. Select one or more sources from the list and click Select as source.

l If the source type is partners, click Add source to display a list of available partners. Select one or more partners and click Select as source. To remove a source partner, select a partner and click Remove.

5. Click Target in the panel on the left side of the page.

6. Select one or more targets in the same manner as selecting sources. You can also select a Gateway as a target. Click Select as target.

You can now edit the fields for the source and target. You can save the flow now or later.

If applications or application groups are changed after creating the flow, the change affects the flow status where the group already is used. You must redeploy the flow.

Next steps

If you select See

Transfer CFT as source Transfer CFT source fields in flows on page 423

SecureTransport as source Source fields in flows on page 375

Transfer CFT as target Transfer CFT target fields in flows on page 442

Add a relayA relay in a flow is the product1 or unmanaged product2 that receives a file from the source and transmits it to the target or to another relay.

1Axway business application software. For example, Transfer CFT.2Unmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that cannot register in Central Governance or third-party products.


24 Defining flows

When you define multiple relays in a flow, the files are transferred from source to target through the relays in the order specified in the definition. For example, if a flow from a bank branch in California to a branch in Paris must pass through a relay in New York and one in Paris, the New York relay must be the first relay defined in the flow.

Add relay 1. Open the flow in edit mode, if not already opened.



2. Click Relay in the panel on the left side of the page.

3. Under No relay selected, click Edit Relay to show a list of products. Or, select Unmanaged products in the Select Relay From drop-down list to display unmanaged products.

You can use the Filter to refine the list.

4. Select a product or unmanaged product and click Select as relay.

l If the relay is SecureTransport, see SecureTransport as relay in flows on page 317.

l If the relay is Transfer CFT, see Transfer CFT as relay in flows on page 323. To disable the store and forward on Transfer CFT relays, see Transfer CFT store and forward on page 334.

l If the relay is Gateway, see as relay in flows.

5. To add another relay, click Relay on the left side of the page again and repeat the previous steps.

If you select an unmanaged product as the relay and it is changed after creating the flow, the change affects the flow status where the unmanaged product is already in use. You must redeploy the flow manually.

Remove relayTo remove a relay, select the relay. Under Relay Product, place the cursor over the relay to be removed. Click X to remove it.

Specify the protocolYou must define a protocol between the source and target in a flow. If there are relays between the source and target, you also must define a protocol between each of the following pairs or flow segments:

l Source and target

l Source and relay


24 Defining flows

l Relay and relay

l Relay and target

The configuration of any protocol must include the direction of the flow (sender pushes file or receiver pulls file) and technical details of the protocol.

Prerequisites l The flow is open in add or edit mode in the user interface.

l General information is defined.

l Source, target and, if applicable, relays are specified.

Fields Default values are provided in the user interface. Change the defaults to meet your needs.

Exchange protocol

The protocol used for the exchange.

l SecureTransport and partners support HTTP1, FTP2, PeSIT3 and SFTP4.

l SecureTransport, Gateway and partners support PeSIT5, FTP6, HTTP7 and SFTP8.

l Transfer CFT, unmanaged products and applications associated with Transfer CFTs support PeSIT only.

Direction

Direction indicates the initiator of a file transfer in a flow.

l Sender pushes file. The sender is the initiator of the transfer request. The

1Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to commands.2File Transfer Protocol (FTP) is a standard network protocol for transfering files from one host to another host over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and uses separate control and data connections between the client and the server.3PeSIT is an open file transfer protocol often associated with Axway. PeSIT stands for Protocol d’Echanges pour un Systeme Interbancaire de Telecompensation. It was designed as a specialized replacement for FTP to support European interbank transactions in the mid-1980s.4SSH File Transfer Protocol (SFTP) is a network protocol for file transfer and manipulation functionality over any reliable data stream.5PeSIT is an open file transfer protocol often associated with Axway. PeSIT stands for Protocol d’Echanges pour un Systeme Interbancaire de Telecompensation. It was designed as a specialized replacement for FTP to support European interbank transactions in the mid-1980s.6File Transfer Protocol (FTP) is a standard network protocol for transfering files from one host to another host over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and uses separate control and data connections between the client and the server.7Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to commands.8SSH File Transfer Protocol (SFTP) is a network protocol for file transfer and manipulation functionality over any reliable data stream.


24 Defining flows

sender is the client and the receiver acts as the server.

l Receiver pulls file. The receiver is the initiator of the transfer request. The receiver is the client and the sender acts as the server. The receiver's request triggers the sender to send the file.

You can set direction for each protocol in the flow. If you want to change direction, the user interface enforces and warns when a protocol or direction is invalid.

The following describes the fields by protocol. Configuring protocols requires having communication profiles. See Communication profiles on page 302. Transfer CFT supports only PeSIT.

FTPConnection mode

Indicates whether active mode1 or passive mode2 is used for transfers.

The server can support active mode, passive mode, or both.

SSL/TLS

Indicates whether the connection is secured via SSL or TLS.

l Client optional - Only the server must authenticate; the client might assure its identity. The server asks for the client's certificate during the SSL handshake, but allows the connection to proceed if the client does not present a certificate or when authentication with the presented certificate fails.

l Mutual authentication - Both parties authenticate themselves to assure identities.

l None - No security.

l Server only - Only the server must authenticate. The client does not present a certificate for authentication.



Security mode

Indicates whether the security mode is explicit or implicit.

1In FTP active mode, the client establishes the command channel, from client port X to server port 21, but the server establishes the data channel, from server port 20 to client port Y, where the client supplies Y. Also see passive mode.2In FTP passive mode, the client establishes the command channel and the data channel. The server tells the client which port to use for the data channel. Also see active mode.


24 Defining flows

FTP supports two methods to accomplish security through a sequence of commands passed between two computers. The sequence is initiated with explicit (active) or implicit (passive) security.

l Explicit security. The initial connection is unencrypted. To establish the secure link, explicit security requires the FTP client to issue a specific command to the FTP server after establishing a connection. The default FTP server port is used.

l Implicit security. Implicit security begins with a secure connection as soon as the FTP client connects to an FTP server. The FTP server defines a specific port for the client to be used for secure connections.

Client communication profile

Indicates the client communication profile to use. You can use an existing profile or add a profile to use in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, connection mode, SSL/TLS, FIPS, security mode options and relevancy to the sender.

To add an FTP profile for a partner or SecureTransport, see FTP client communication profile on page 368.

Server communication profile

Indicates the server communication profile to use. You can use an existing profile in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, connection mode, SSL/TLS, FIPS, security mode options and relevancy to the sender.

More information about server communication profiles:

SecureTransport: Network zone and server communication profile fields on page 252

Transfer mode

Indicates the format of the transferred files. You can specify ASCII or binary or select autodetect to determine file format dynamically.

HTTPEnable HTTP methods check

Indicates whether HTTP methods check is enabled.

HTTP methods

If HTTP methods check is enabled, indicates the method for moving the file.

l PUT - Requests the enclosed entity be stored under the supplied URI1. If it

1A uniform resource identifier (URI) is a string of characters for identifying the name of a resource. This enables interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols.


24 Defining flows

refers to an existing resource, the URI is changed. If the URI does not point to an existing resource, the server can create the resource with that URI.

l POST - Requests the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources.

l GET - Requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect.

SSL/TLS









Indicates the client communication profile to use. You can use an existing profile or add a profile to use in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, HTTP methods, SSL/TLS, FIPS, security mode options and relevancy to the sender.

To add an HTTP profile for a partner or SecureTransport, see HTTP client communication profile on page 362.


Indicates the server communication profile to use. You can use an existing profile in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, HTTP methods, SSL/TLS, FIPS, security mode options and relevancy to the sender.




24 Defining flows

Transfer mode


PeSITFlow identifier

The unique identifier of the flow or flow segment. Each protocol within the flow can have the same ID or a different unique ID. See Flow identifiers on page 303.

Network protocol




l UDT - The UDP-based Data Transfer Protocol (UDT) is a high performance data transfer protocol designed for transferring large volumetric data sets over high-speed wide-area networks.

See About transfer acceleration on page 222 for more information.

SSL/TLS






Transfer CFT as server supports only options Mutual authentication and None.


24 Defining flows


Indicates the client communication profile to use. You can use an existing profile or add a profile to use in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, network protocol, SSL/TLS, FIPS, security mode options and relevancy to the sender.

To add an PeSIT profile for a partner or SecureTransport, see PeSIT client communication profile on page 364.


Indicates the server communication profile to use. You can use an existing profile in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, network protocol, SSL/TLS, FIPS, security mode options and relevancy to the sender.



Acknowledgment

Indicates whether acknowledgments for transfers are enabled.

PeSIT properties

Indicates whether the file is compressed during transfer.

When multiple flows are defined between the same Transfer CFTs and security is different, commands for executing flows must include the PROT parameter. This ensures the security level defined in the flow is correct.

SFTPClient authentication

Indicates the method for authenticating the server.

l Public key - The server's public key is used to authenticate the server.

l Password - The user name and password for connecting to the server is used to authenticate the server.

l Password or public key - The public key or password are used to authenticate the server.


Indicates whether Federal Information Processing Standards (FIPS) is enabled for transfers. When enabled, the sender and the receiver must use FIPS-compliant ciphers and ciphers suites. Transfers fail if the sender and receiver do not provide them.


24 Defining flows


Indicates the client communication profile to use. You can use an existing profile or add a profile to use in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, client authentication, SSL/TLS, FIPS, security mode options and relevancy to the sender.

To add an SFTP profile for a partner or SecureTransport, see SFTP client communication profile on page 366.


Indicates the server communication profile to use. You can use an existing profile in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, client authentication, SSL/TLS, FIPS, security mode options and relevancy to the sender.



Note When password or public key is used for server authentication, available server communication profiles also are the result of the union of server communication profiles configured with client authentication set at public key or password.

Transfer mode


AS2SSL/TLS






Require signing

Indicates whether files are signed digitally.


24 Defining flows

Require encryption

Indicates whether files are encrypted.


Indicates the server communication profile to use. You can use an existing profile in the flow. If available, Central Governance suggests existing profiles you can use based on the selected protocol, connection mode, SSL/TLS, FIPS, security mode options and relevancy to the sender.



Message disposition notification

Indicates whether the receivers of files must send message disposition notifications (MDNs) to acknowledge receiving files. If enabled you can specify:

l Synchronous receipts - A synchronous receipt is returned to the sender during the same HTTP session as the sender's original message.

l Asynchronous receipts - An asynchronous receipt is returned to the sender on a different communication session than the sender's original message session.

Compression

Indicates whether files are compressed before being transferred.

Chunking

Indicates whether large files are broken into smaller pieces while being transferred.

HTTP client communication profileDefining an HTTP client communication profile depends on whether the client is an external partner, Gateway, or SecureTransport.

If the FIPS transfer mode is enabled, the client communication profile has the property enabled.

Prerequisites l A flow is open in add or edit mode.

l You have selected HTTP as the protocol in a flow segment.

l You need to add a client communication profile.

See Specify the protocol on page 354 for more information.


24 Defining flows

FieldsName

The unique name of the communication profile.

Network Zone

The network zone defines the product proxies to use for the transfer.

Select a specific network zone to use the proxy configuration defined for that zone.

The available network zones are defined for a registered product on its configuration page under the Products area of the user interface.

Login

The user name for the client to connect to the server



Private or Public Certificate

When SSL/TLS is enabled, you can select an existing certificate or upload a new one. This is required when mutual authentication is selected, but optional when client optional is selected. For client optional you can select No certificate authentication as the client certificate option when you specifically do not want to use a certificate.

For a new certificate:

l If the certificate is for a product, use a file containing the product’s private certificate. Supported file type is P12 (PKCS#12). You have to specify the certificate’s password.

l If the certificate is not for a product, upload a file containing the server's public key certificate. Supported file types are DER, PEM and P7B (PKCS#7).

Specify an alias for a new certificate. This enables you to use the same certificate in multiple profiles.


Server certificate verified

Specifies whether the client verifies the server's certificate when communication between the two is being established. You can have the client verify the server certificate when client optional or server only is selected for SSL/TLS. The server certificate always is verified when mutual authentication is selected for SSL/TLS.


24 Defining flows

SSl/TLS setting


None Not set and not displayed

Client optional Displayed and by default yes regardless whether a certificate is presented

Server only Displayed and by default yes

Mutual authentication

Not displayed and forced to yes

PeSIT client communication profileDefining a PeSIT client communication profile depends on whether:

l The client is an external partner, Gateway, or SecureTransport.

l An SSL option is selected.



l You have selected PeSIT as the protocol in a flow segment.



FieldsDefault values are provided in the user interface. Change the defaults to meet your needs.

Name

Name


Network Zone





24 Defining flows

Login


When SecureTransport is the initiator of the connection, the user name must be all upper-case letters and no more than 24 characters.



When SecureTransport is the initiator of the connection, a password is optional and can be no more than eight characters.










SSl/TLS setting






24 Defining flows

SSl/TLS setting




SFTP client communication profileDefining an SFTP client communication profile depends on whether:

l The client is an external partner, Gateway, or SecureTransport.

l Client authentication is selected in the protocol definition.



l You have selected SFTP as the protocol in a flow segment.



FieldsDefault values are provided in the user interface. Change the defaults to meet your needs.

Name

Client authentication = passwordName


Network Zone




Login



24 Defining flows



Client authentication = public keyName


Network Zone

The network zone defines the SecureTransport proxies to use for the transfer. This is available only when defining client communication profiles.


The available network zones are defined for a registered SecureTransport on its configuration page under the Products area of the user interface.

Login


Public or Private Key

The key the client uses to connect to the server. You can select an existing key or upload a new one.

Upload a public SSH key if the client is a partner. You must provide an alias for the key.

Select or upload a PKCS#8 or PEM password-protected private key if the client is SecureTransport. You must provide a password and an alias for the key.

Verify fingerprint

Indicates whether SecureTransport verifies the fingerprint of the SSH key against the value in the Fingerprint field. Connections are refused if values do not match. This field is available only for a product.

Fingerprint

If fingerprint verification is enabled, this field specifies the for value for verifying the fingerprint.

Client authentication = password or public keyName



Indicates how the client connects to the server.


24 Defining flows

The final client authentication type depends on the setting in the server communication profile.

l If the server communication profile has password configured for the client authentication, password is the client authentication in the client communication profile. No action is required on the client communication profile.

l If the server communication profile has public key configured for the client authentication, public key is the client authentication in the client communication profile. No action is required on the client communication profile.

l If the server communication profile has password or public key configured for the client authentication, you can select password or public key as the client authentication in the client communication profile.

FTP client communication profileDefining an FTP client communication profile depends on whether the client is an external partner, Gateway, or SecureTransport.



l You have selected FTP as the protocol in a flow segment.



FieldsName


Network Zone




Login



24 Defining flows












SSl/TLS setting








24 Defining flows

Symbolic variablesA symbolic variable is a representation of a value that is not known at the time the flow is defined, but only at the time the transfer is executed.

The syntax of the variable is &VAR, where VAR is the variable name. For example, the variable &FNAME represents the name of the file at the source.

The table lists the variables grouped by category, the value represented by the variable, and the maximum length of the substituted value in characters. For ease of scanning, the variables are listed without the leading ampersand (&).

Note When using symbolic variables in Gateway fields, if an option applies to an Application object, use the syntax &(x_%parameter%). If it applies to a Model or Exchmd object, use the syntax &(%parameter%).

Category Variable Value Max Length

Application IDA Application identifier 64

PARM Relates to the Additional information field on the Source transfer properties page of the flow definition

513

RAPPL Target application name 48

SAPPL Source application name 48

Date/time a file was made available for transfer

FDATE Date 8

FTIME Time 8

FYEAR Year 4

FMONTH Month 2

FDAY Day 2

Date/time associated with a transfer

BDATE Transfer start date 8

BTIME Transfer start time 8

BYEAR Transfer start year 2

BMONTH Transfer start month 2

BDAY Transfer start day 2


24 Defining flows


Date/time of the system

SYSDATE System date 8

SYSTIME System time 8

File FNAME Name of the physical file at the source including the path to the file. For example, /usr/TATA/tmp/TOTO.TXT

512

FPATH Path to the physical file at the source. For example, /usr/TATA/tmp/

512

FROOT Name of the physical file at the source. For example, TOTO.TXT

512

IDF Flow identifier

32

NFNAME Name of the file as it is being transmitted over the network

512

NFVER Version number of the file 255

NIDF Identifier of the flow as it is being transmitted over the network

512

Source/target Transfer CFT

GROUP Group to which the source or target belongs 32

PART Identifier of the Transfer CFT on which you are using the variable

32

IPART Identifier of the Transfer CFT that is the relay in the flow

32

NPART Network name of the source or target, depending on the direction of the transfer

32

RPART Name of the target 32

SPART Name of the source 32


24 Defining flows


Transfer IDT Identifies a transfer for a given source or target and the transfer direction. It does not ensure the uniqueness in the transfer list. To ensure uniqueness, the IDTU variable is used.

8

IDTU Transfer list identifier for the transfer. When there are several Transfer CFT systems on the same computer, this variable guarantees the uniqueness among the systems sharing the same transfer list.

8

MODE Indicates whether the transfer was initiated by the source (S) or by the target (R)

1

User RUSER Name of user receiving the file or files 32

SUSER Name of user sending the file or files 32

Save and deploy a flowAfter defining a flow, you can save it or save and deploy it. This enables you to prepare a deployment before pushing the configuration to the source and target systems. After deployment, when the flow is executed, the configuration changes defined in the flow are used.

Click Save to store the flow definition locally in Central Governance. You can do this if you still have changes to make or if you are not ready to deploy the flow.

Click Deploy to save the definition and push it to the products in the flow. For example:

1. You define a flow with Host A as the source and Host B as the target.

2. You deploy the flow to Host A and Host B.

3. You change a field in the source properties section of the flow and deploy the flow. Only Host A is updated, since no changes were made to the target properties.

4. You add Host C as a target and deploy the flow. In addition to Host C, the flow is deployed to Host A, which requires the information about the new target.

l For Transfer CFT, Central Governance uses the Copilot WebService to deploy flows to Transfer CFT.

l For SecureTransport, Central Governance uses SecureTransport RESTful APIs to deploy flows to SecureTransport.

l For Gateway, Central Governance uses command line commands to deploy flows to Gateway.


24 Defining flows

Configuration change managementCentral Governance implements a series of configuration-change checks that display messages if certain changes occur in a configuration that is used in a flow. The following actions impact related flows:

l Removing

o Protocol

o Network protocol

l Disabling

o Protocol

o Network protocol

l Modifying

o Protocol

o Protocol port

o FIPS

o PeSIT password

When removing a protocol or network, a warning message is triggered immediately if there is an impact on a flow. Otherwise, the notification occurs when you click to save the configuration.

NoteYou cannot use a non-deployed configuration in a flow. By extension, if you update a configuration (e.g., you change the port of a protocol in an existing configuration), the moment the configuration passes through the “Saved” state, it is removed from the flow and the flow itself changes to "Saved". Even if you immediately deploy the updated configuration, you will need to manually reload the configuration on the flow.

Back up flows from UIYou can export files of flows to a specified directory from the Central Governance user interface. The intent behind this backup feature is promoting flows from one instance of Central Governance to another. For example, promote from a development or staging environment to a production environment. After backing up flows, you could have an external process retrieve the files and import to another instance. However, Central Governance only can back up flows; any external process for retrieving and importing is outside its control.

UI flow backup is an alternative to using CLI1 to export flows to files. The UI feature only can write flow files to a static directory accessible to the server, while CLI can export to any server or local directory when used remotely. See flowExport on page 95.



24 Defining flows

None of the Central Governance default user roles gives permissions for backing up flows from the UI. Users who want to must have a role with the Central Governance Backup Flow predefined privilege. Or, create a user-defined privilege based on the Central Governance Flow resource with the View and Backup actions enabled and add it to a role. The Flow resource is FGAC1-enabled (see Fine-grained access control on page 157).

See Prerequisites for promoting flows on page 498 for more information about promoting flows.

Use flow backup 1. Click Flows on the top toolbar in Central Governance to open the Flow List page. The control is

available only for users whose role gives permission to back up flows from the UI.

2. Select one or more flows and click Backup. Central Governance responds with a message indicating whether backup has succeeded or failed. Success messages list the names of the backed-up flows.

Central Governance writes the file to the configured backup directory. The default directory is <install directory>/backup. The file is in the following format:

export_flow_<timestamp>.json

If you create multiple backup files, only the timestamp differentiates one file from another. If you need to identify the flows in a file, open the file to review its contents.

Change flow backup directoryUse this procedure if you want to change the default backup directory.

1. Create a directory to store the flow backup files. This can be any directory Central Governance can access. The external process for promoting flows must have access, too. Also, the user who starts Central Governance must have rights to write files to the directory.

2. Navigate to the file named com.axway.cmp.flow-default.cfg under:

<Central Governance install

directory>/runtime/com.axway.nodes.ume_<UUID2>/conf/

3. Edit the property to point it to your directory:

backup.dir=<path to the backup directory>

For example, on Linux the directory could be

/home/<user>/<mybackupdir>

4. Save the file. You do not have to restart Central Governance.

1Fine-grained access control (FGAC) is a way to manage users' access to objects or capacity to perform actions. For example, you could enable some users to view specific objects in the user interface, but prohibit other users from viewing the same objects.2A universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.

25 SecureTransport fields in flows

The following topics describe by protocol the send, file processing and receive fields for SecureTransport in flows defined in Central Governance.

Receive and send properties are different depending on direction of a flow segment: sender pushes file or receiver pulls file. File processing properties are the same regardless of direction.

When the direction is sender pushes files:

l Receive properties control the behavior of a transfer when files are pushed to SecureTransport. You can define receive properties when SecureTransport is used as a relay

l Send properties control the behavior of transfers when SecureTransport pushes files to the receiver.

When the direction is receiver pulls files:

l Receive properties control the behavior of a transfer when SecureTransport pulls files from the sender. You can define receive properties when SecureTransport is used as a relay.

l Send properties control the behavior of transfers when SecureTransport publishes files to a receiver that pulls them.

File processing properties control whether transferred files are compressed or decompressed, PGP1 encrypted or decrypted, or have specified line endings.

Source fields in flowsThe following describes the fields when SecureTransport is used as the source in a flow. See SecureTransport as source in flows on page 316 for an example of SecureTransport as the source in a flow.

Receive propertiesThe following are the receive properties when SecureTransport is the source in a flow.

Folder monitoringThe following fields specify how SecureTransport scans the application directory.

1Pretty Good Privacy (PGP) is a data encryption and decryption program for cryptographic privacy and authentication in data communication. PGP often is used for signing, encrypting, and decrypting texts, emails, files, directories and whole disk partitions, and to increase the security of email communications.



Directory to scan

The absolute path for the directory where the application puts files for SecureTransport.

File filter

The method for filtering the files in the directory to scan.

Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport Administrator Guide for details. For example, if you specify *\.(txt|xml), all TXT and XML files are filtered.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *.xml, all XML files are filtered.

Scan sub-directories

Specify whether files in subdirectories of the directory to scan are filtered.

Directory depth

When scan sub-directories is enabled, specifies the depth of subdirectories to scan.

Sub-directory filter

Specifies the names of subdirectories to scan. You can use regular expressions or file globbing.

Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport Administrator Guide for details. For example, if you specify (ORDERS|INVOICES), only ORDERS and INVOICES directories are scanned.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *PART*, all directories containing PART are scanned.

Scheduler

You can specify a schedule for retrieving files from the application directory. If not enabled, folder monitoring is triggered according to a global set of properties that is set externally and not in Central Governance. When enabled, you can set a one-time or recurring schedule for monitoring files. You can specify a frequency ranging from daily to annually and set specific times of day. You also can define a validity period by setting start and end dates.

File propertiesDirectory

The path of the directory where files retrieved via folder monitoring are moved. These files are processed for sending as defined in send properties.


The directory value is relative to the home folder of the generic account for monitoring application folders defined in SecureTransport.

For SecureTransport on Linux, the directory name cannot be equal to:

.. or .

The name also cannot contain:

/../ or /./ or // or : * ? " < > |

It cannot start with:

../ or ./ or ~

And it cannot end with:

/.. or /.

For SecureTransport on Windows, the directory name cannot contain drive letters or the following characters:

/ * ? " < > |

Receive file as

Name of the files scanned when files are retrieved form an application folder and moved on the SecureTransport side. The value is relative to the generic SecureTransport account home directory. It can contain any valid expression.

If a file name expression begins with /, the transformed file is put in the subfolder indicated by this file name expression relative to the subscription folder. Otherwise, the transformed file is put in the subfolder indicated by this file name expression relative to the source file folder.

Example 1. Append current date to the target file name:

${stenv['target']}_${date('yyyyddMMHHmmss')}

Example 2. Append a random ID to the file name:

${stenv['target']}_${random()}

Post-reception actionsOn failure

Specifies the action to take when transfers fail. A failure occurs when the transfer is incomplete and all retry attempts have failed. You can select:

No Action causes the files to stay in the original location. If another file with the same name is transferred to this location, the original file is overwritten.

Delete removes the files from the original location.

Move/Rename File requires you to specify a directory to move the files and an expression for renaming the files.

File processingSee File processing properties in flows on page 397.

Send propertiesThe send properties depend on the flow direction and the protocol between SecureTransport and the next participant in the flow. See Send properties in flows on page 380.

Target fields in flowsThe following describes the fields when SecureTransport is used as the target in a flow. See SecureTransport as target in flows on page 321 for an example of SecureTransport as the target in a flow.

Receive propertiesReceive properties depend on the exchange protocol and direction between SecureTransport and the preceding participant to the flow. See Receive properties in flows on page 389.

File processingSee File processing properties in flows on page 397.

Send propertiesUpload directory

The upload directory represents the absolute path where files are pushed. Validation is done only if Use expression language is No. Otherwise, you can use expressions like the following where the current date is appended to the target file's name.


For SecureTransport on Linux, the value cannot equal:

.. or .

And it cannot contain:

/../ or /./ or // or :*?"<>|


Nor two or more of the following characters in a sequence:

( ) _ - + = { } ~ ! @ # $ % ̂ & ; "

It also cannot start with:

../ or ./ or ~

Or end with:

/.. or /.

For SecureTransport on Windows the folder path cannot contain a drive letter.

Use expression language

When enabled the upload folder can contain expressions.

Create directory if not existent

An upload folder is created if it does not exist. The folder is owned by the user running the SecureTransport TM server process.

Upload file as

Use to rename the file to push. You can use an expression to specify a file name.

Post-sending sectionsOn failure












On success

Specifies the action to take when transfers succeed. The No action and Move/Rename actions are the same as for failure.

Send properties in flowsThe following are the send properties fields for all protocols in flows using SecureTransport. Fields are described when the direction is sender pushes file and receiver pulls file. Default values are provided in the user interface. Change values to meet your needs.


l SecureTransport is in the flow as a source, target or relay.

Multiple receiversIf a flow has multiple receivers, the user interface for send properties behaves differently depending on the protocol.

Protocol after SecureTransport is SFTP, FTP or HTTPIf the protocol after SecureTransport in the flow is SFTP, FTP or HTTP, the UI displays a table that enables you to edit the send properties for each receiver by clicking Edit next to the receiver's name. The Status column in the table indicates whether the properties for each receiver are configured properly.

Protocol after SecureTransport is PeSITIf the protocol after SecureTransport in the flow is PeSIT, the send properties, with one exception, are the same for all receivers, according to the flow direction set after SecureTransport. The file filter is the only property configured for each receiver.

If the receiver is a group of applications, a file filter is configured for each application in the group.

SFTP, FTP, HTTP: Send properties, sender pushes fileThe following are the send properties for SFTP, FTP and HTTP when SecureTransport is in the flow and the direction is sender pushes file.


File properties Remote directory

Represents the directory on the receiver where SecureTransport pushes files.

The directory value cannot contain:

\ * " < > |

File name sent

You can use the expression language to specify the criteria you want to match. The expression uses the criteria provided to create a new file name from the original file name.

If the field is not used, the name of the received file is unchanged when the file is sent.

See regular expressions topics in the SecureTransport Administrator Guide for details.

Example 1. New file name based on the current file name (since the transformation might have changed it):

${basename(currentfulltarget)}.sent

Example 2. New file name based on the original filename with a timestamp:

${basename(transfer.target)}..${timestamp}.${extension(transfer.target)}

File filter

Represents, when set, the filter on files SecureTransport pulls from the remote directory. You can select:

Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport Administrator Guide for details. For example, if you specify *\.(xml|txt), all XML and TXT files are downloaded.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *.xml, all XML files are downloaded.

If you do not use the field, all files in the remote directory are downloaded.

Post-sending actionsOn failure








On success

Specifies the action to take when transfers success. The actions are the same as for on failure.

SFTP, FTP, HTTP: Send properties, receiver pulls fileThe following are the send properties for SFTP, FTP and HTTP when SecureTransport is in the flow and the direction is receiver pulls file.

Transfer propertiesFile exists

Detects duplicate transfers on the remote directory. Actions you can specify for duplicates are:

Cancel refuses the transfer.

Overwrite replaces an existing file by overwriting it.

Rename allows the transfer but renames the existing file.

Rename transferred file leaves the existing file name as-is, but renames the transferred file.

Append renames the transferred file by appending it. The name is derived from the name specified in the Publish file as field. For example:

If file name is myFile.txt, the file is renamed myFile (new copy 1).txt.

However, if this file already exists, the file is renamed myFile (new copy 2).txt.

If the file doesn't have an extension, the name transformation is the same but without the extension. For example, myFile (new copy 1).


The directory where SecureTransport makes available files for the receiver to pull. The directory value cannot contain the following characters:

\ * " < > |

Publish file as

Represents the name of the published file. If this field is not used, the name used is the name of the file SecureTransport received from the sender.

You can use the regular expression language to specify creating a file name. See regular expressions topics in the SecureTransport Administrator Guide for details.

Example 1. New file name based on the current filename (since the transformation might have changed it):




File filter

Represents, when set, the filter on files SecureTransport publishes to the receiver. You can select:








On success


Post-download actionsOn success

Specifies the action to take after files are downloaded.

No Action specifies nothing is done.

no actions take place on the downloaded files.

Delete removes the file from the directory where SecureTransport received the it.

PeSIT: Send properties, sender pushes fileThe following are the send properties when SecureTransport is in the flow and the direction is sender pushes file over PeSIT.

Transfer propertiesUser message

Overrides the predefined user message (PI99) in the PeSIT transfer site. To preserve the predefined user message, leave the field blank or enter the expression language1 expression ${pesit.pi.serviceParam}. This field corresponds to the PARM2 in Transfer CFT.

1SecureTransport uses an expression language (EL) based on the Sun JSP Expression Language. See the SecureTransport documentation for details. The following SecureTransport features can use EL: transfer site post-transmission actions, subscription post-transmission actions, PGP, account templates.2A user parameter or parameter file in Transfer CFT.



File propertiesFile name sent

Overrides the file label (PI37) predefined in the transfer profile. If you select Custom, you must enter a string. This field corresponds to the NFNAME1 in Transfer CFT.

File filter

Select the method for filtering the files.

Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport Administrator Guide for details. For example, if you specify *\.(txt|xml), all TXT and XML files are processed.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *.xml, all XML files are processed.

File encoding file type

Specifies the file type. Select Binary to send a mix of file types and ensure there is no custom encoding or transcoding required for the text files. Select EBCDIC (native) for files that use EBCDIC LF (0x25) as the end-of-line character.

Record format record type

Indicates whether the records in the file are fixed or variable length.

Maximum record length

Specifies in bytes the maximum length of the records.

Archive filesOn failure

Specifies if files that are transferred unsuccessfully are archived.

If you select Default, the flow archiving setting inherits the account archiving setting. For flows deployed on Central Governance, the account and business units have the archiving set to Default. This means that flows inherit the global archiving setting: Setup > File archiving.If you set Setup > File archiving to:

l Disabled: The archive fields deployed from Central Governance are hidden in SecureTransport.

1In Transfer CFT, the name of the physical file at the receiver partner site.



l Enabled: And additionally you set On failure to Default in Central Governance, the actual value at the time of a file transfer is the value of the Global archiving policy. If you set On failure to Disabled, archiving is disabled at the time of the file transfer, regardless of the Global archiving policy setting.

The Setup > File archiving > Archive folder and Delete files older than options specify the location where the file is archived and the duration of the archiving, respectively.

On success

Specifies if files that are transferred successfully are to be archived. Possible actions are the same as for On failure.

For more information, please see Flow and transfer monitoring on page 72.











On success




PeSIT: Send properties, receiver pulls fileThe following are the send properties when SecureTransport is in the flow and the direction is receiver pulls file over PeSIT.

Transfer propertiesFile exists

Detects duplicate transfers on the remote directory. Actions you can specify for duplicates are:

Cancel refuses the transfer.

Overwrite replaces an existing file by overwriting it.

Rename allows the transfer but renames the existing file. For example, if the file is named myFile.txt, it is renamed myFile(old copy 1).txt. But if that file already exists, the new name is myFile (old copy 2).txt.

Rename transferred file leaves the existing file name as-is, but renames the transferred file. The name is derived from the name specified in the Publish file as field. If file name is myFile.txt, it is renamed myFile (new copy 1).txt. But if this file already exists, the file is renamed myFile (new copy 2).txt. If the file doesn't have an extension, the name transformation is the same but without the extension. For example, myFile (new copy 1).

Append renames the transferred file by appending it.

File propertiesFile name sent

Overrides the file label (PI37) predefined in the transfer profile. If you select Custom, you must enter a string. This field corresponds to the NFNAME1 in Transfer CFT.

Files to send

Indicates whether one or multiple files are transferred.

File filter


Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport Administrator Guide for details. For example, if you specify *\.(txt|xml), all TXT and XML files are processed.

1In Transfer CFT, the name of the physical file at the receiver partner site.




Publish file as

Represents the name of the published file. If this field is not used, the name used is the name of the file SecureTransport received from the sender.

You can use the regular expression language to specify creating a file name. See regular expressions topics in the SecureTransport Administrator Guide for details.

Example 1. New file name based on the current filename (since the transformation might have changed it):






















On success


Post-download actionsOn success

Specifies the action to take after files are downloaded.

No Action specifies nothing is done.

no actions take place on the downloaded files.

Delete removes the file from the directory where SecureTransport received the it.

Receive properties in flowsThe following are the receive properties fields for all protocols in flows using SecureTransport. Fields are described when the direction is sender pushes file and receiver pulls file. Default values are provided in the user interface. Change values to meet your needs.


l SecureTransport is in the flow as a source, target or relay.

Multiple sendersIf a flow has multiple senders, the user interface for receive properties behaves differently depending on the protocol.


Protocol preceding SecureTransport is SFTP, FTP or HTTPIf the protocol preceding SecureTransport in the flow is SFTP, FTP or HTTP, the UI displays a table that enables you to edit the receive properties for each sender by clicking Edit next to the sender's name. The Status column in the table indicates whether the properties for each sender are configured properly.

Protocol preceding SecureTransport is PeSITIf the protocol preceding SecureTransport in the flow is PeSIT, the receive properties are the same for all senders, according to the flow direction set before SecureTransport.

SFTP, FTP, HTTP: Receive properties, sender pushes fileThe following are the receive properties for SFTP, FTP and HTTP when SecureTransport is in the flow and the direction is sender pushes file.


The directory represents the path where the sender can push files to SecureTransport. Files received in this directory are handled as defined in Receive properties in flows on page 389 and processed for sending as defined in Receive properties in flows on page 389.

The directory value is relative to the home folder of the sender account defined in SecureTransport.


.. or .

The name also cannot contain:

/../ or /./ or // or : * ? " < > |

It cannot start with:

../ or ./ or ~


/.. or /.

/ * ? " < > |











SFTP, FTP, HTTP: Receive properties, receiver pulls fileThe following are the receive properties for SFTP, FTP and HTTP when SecureTransport is in the flow and the direction is receiver pulls file.

File propertiesRemote directory

Represents the folder on the sender where SecureTransport pulls files. The directory value cannot contain:

\ * " < > |

File filter

Represents, when set, the filter on files SecureTransport pulls from the remote directory. You can select:

Directory

The directory represents the path where the sender can push files to SecureTransport. Files received in this directory are handled as defined in Receive properties in flows on page 389 and processed for sending as defined in Receive properties in flows on page 389.


.. or .

Also, the name cannot contain:

/../ or /./ or // or : * ? " < > |

It also cannot start with:

../ or ./ or ~


/.. or /.


/ * ? " < > |

Scheduler

You can specify a schedule for retrieving files from the sender. If not enabled, files are pulled according to a definition that is set externally and not in Central Governance.

When enabled, you can set a one-time or recurring schedule for pulling files. You can specify a frequency ranging from daily to annually and set specific times of day. You also can define a validity period by setting start and end dates for a schedule.








On success

Specifies the action to take when transfers succeed. You can select:

No Action causes the files to stay in the original location. If the receiver trigger the transfer again, the original file is pulled again.


Move/Rename File requires you to specify a directory to move the files and an expression for renaming the files. This option is available only for SFTP and FTP.






PeSIT: Receive properties, sender pushes fileThe following are the receive properties for PeSIT when SecureTransport is in the flow and the direction is sender pushes file.

Receive properties in flows control the behavior of a transfer when files are pushed over PeSIT to SecureTransport. You can define receive properties when SecureTransport is used as relay.



File propertiesReceive file as

Name pf the files received when files are transferred to SecureTransport. The value is relative to the sender’s account home directory. It can contain any valid expression, including PeSIT expressions. The suggested default value is:

${basename(pesit.fileLabel)}-${timestamp}-${pesit.transferID}${extension(pesit.fileLabel)}
























PeSIT: Receive properties, receiver pulls fileThe following are the receive properties for PeSIT when SecureTransport is in the flow and the direction is receiver pulls file.

Receive properties in flows control the behavior of a transfer when SecureTransport pulls files from the sender over PeSIT. You can define receive properties when SecureTransport is used as relay.

File propertiesReceive file as

Name pf the files received when files are transferred to SecureTransport. The value is relative to the sender’s account home directory. It can contain any valid expression, including PeSIT expressions. The suggested default value is:

${basename(pesit.fileLabel)}-${timestamp}-${pesit.transferID}${extension(pesit.fileLabel)}






Files to receive

Indicates whether SecureTransport receives one file or multiple files.

One file means SecureTransport gets the first available file.

Multiple files mean SecureTransport gets all available files.









Scheduler

You can specify a schedule for retrieving files from the sender. If not enabled, files are pulled according to a definition that is set externally and not in Central Governance.

When enabled, you can set a one-time or recurring schedule for pulling files. You can specify a frequency ranging from daily to annually and set specific times of day. You also can define a validity period by setting start and end dates for a schedule.













File processing properties in flowsThe following are the file processing properties when SecureTransport is in the flow. The fields are the same regardless of direction or protocol.

If a flow has multiple senders and receivers, the user interface displays a table that enables you to configure the file processing properties for each sender-receiver pair by clicking Edit next to the pair's names. The Status column in the table indicates whether the properties for each pair are configured properly.

Condition

Represents, when configured, a set of comparison expressions, functions and logical operations for defining the files to route to the receiver. When no value is set, the trigger condition is always used. When a value is defined, the trigger condition is based on the entered expression. Use expression language1 to define the route trigger condition.

See regular expressions topics in the SecureTransport Administrator Guide for details.

Example 1. Files uploaded only through a specific protocol:

${extension(transfer.target) eq '.txt'}

Example 2. Files uploaded from specific partner over PeSIT:

${pesit.pi.senderID.toLowerCase() eq 'partner'}

Processing type

Select a processing type and see the fields and descriptions for the type. You can enter a description for the selected processing type.

PGP encryptionEnable to encrypt or sign files, or both, with PGP keys. The matching PGP keys for encrypting or signing are detected at runtime. The keys must exist on SecureTransport or transfers fail. Only keys in non-delimited ASCII (ASC) file format are supported.

File filter

Select the method for filtering the files to process.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *.xml, all XML files are compressed.

1SecureTransport uses an expression language (EL) based on the Sun JSP Expression Language. See the SecureTransport documentation for details. The following SecureTransport features can use EL: transfer site post-transmission actions, subscription post-transmission actions, PGP, account templates.



Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport documentation for details. For example, if you specify *\.(txt|xml), all TXT and XML files are compressed.

Operations

Select the encryption and signature settings.

Encrypt and sign means all files are encrypted and signed.

Encrypt only means all files are encrypted but not signed.

Sign only means all files are signed but not encrypted.

Encryption key

Specifies the SecureTransport public PGP key for encrypting files to partners, applications, unmanaged products or other relays.

You can select the alias of an existing public PGP key or upload a new key. For a new key, upload the key in an ASC file and specify an alias. The user interface warns if you try to add a duplicate alias. All aliases are unique on SecureTransport.

Signing key

Specifies the SecureTransport private PGP key for signing files to partners, applications, unmanaged products or other relays.

Once you provide a password, you can select the alias of an existing private PGP key or upload a new key. For a new key, upload the key in an ASC file and specify an alias. The user interface warns if you try to add a duplicate alias. All aliases are unique on SecureTransport.

Compression

Specifies the type of compression.

Use preferred uses recipient's PGP key to determine the compression method. If the data compression method you choose is not one of the recipient’s preferred methods, the recipient cannot access the data.

Compression level

Specifies the level of compression. Fast to Best represent the compression ratio. As compression file size decreases, the time to compress increases.

Encode using ASCII armor

Specifies whether ASCII armor encoding is used. ASCII armor refers to using binary-to-text encoding for plain text data.

Rename file as

Specifies a regular expression to name output files.

Example 1. New file name based on the current file name:

${basename(currentfulltarget)}.transformed



Example 2. New file name based on the original file name with a timestamp:

${basename(currentfulltarget)}.${timestamp}.${extension(currentfulltarget)}

Example 3. New file name based on its name after the transformation (for example, name

of the file as extracted from an archive) by appending a timestamp:

${transformedfilename}.${timestamp}

PGP decryptionEnable to decrypt files that were encrypted with PGP1 keys or verify signatures of files signed with PGP keys. You also can specify whether transfers fail if files are not encrypted and signed. The matching PGP keys for decryption and signature verification are detected at runtime. The keys must exist on SecureTransport or transfers fail. Only keys in non-delimited ASCII (ASC) file format are supported.

File filter

Select the method for filtering the files to process.



Decryption

Specifies when to decrypt files.

Always means all files are expected to be PGP-encrypted and will be decrypted. Transfers fail when SecureTransport receives or pulls unencrypted files.

Only if encrypted means only PGP-encrypted files are decrypted. Unencrypted files are processed normally.

Decryption key

Specifies the SecureTransport private PGP key for decrypting files from partners, applications, unmanaged products or other relays or picked up from an application via folder monitoring.

1Pretty Good Privacy (PGP) is a data encryption and decryption program for cryptographic privacy and authentication in data communication. PGP often is used for signing, encrypting, and decrypting texts, emails, files, directories and whole disk partitions, and to increase the security of email communications.



Once you provide a password, you can select the alias of an existing private PGP key or upload a new key. For a new key, upload the key in an ASC file and specify an alias. The user interface warns if you try to add a duplicate alias. All aliases are unique on SecureTransport.

Signature verification

Specifies when to verify signed files.

Always means all files are expected to be PGP-signed and will be verified. Transfers fail when SecureTransport receives or pulls files not signed with a trusted PGP key.

Only if signed means only PGP-signed files are verified. Unsigned files are processed normally.

Verification key

Specifies the public key for validating PGP signatures of files SecureTransport receives or pulls from a participant.

You can select the alias of an existing public PGP key or upload a new key. For a new key, upload the key in an ASC file and specify an alias. The user interface warns if you try to add a duplicate alias. Aliases are unique at the participant level.

PGP public keys used for signature verification belong to any of the following types of participants that send files or put files in SecureTransport: partners, applications, unmanaged products and products acting as relays.

A new PGP public key is linked to its owner when uploaded. You can use the same key in other flows where the key owner is involved.

Rename file as

Specifies a regular expression to name output files.





Example 3. New file name based on its name after the transformation (for example, name

of the file as extracted from an archive) by appending a timestamp:


DecompressionEnable to decompress ZIP, JAR, GZIP or TAR files. Then select a filter method and specify the name of the decompressed files.



File filter

When decompression is enabled, select the method for filtering the files to decompress.

Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport documentation for details. For example, if you specify *\.(zip|tar), all ZIP and TAR files are decompressed.

File globbing uses wildcard characters to specify a pattern. For instance, ? matches any single character and * matches any number of characters. For example, if you specify *.zip, all ZIP files are decompressed.

Use archive password

Specifies whether a password is required to decompress the archive. Enter the password in the provided fields.

Rename file as

You can use a regular expression to specify the name of the decompressed file.

CompressionEnable to compress files as ZIP, JAR, GZIP or TAR files. Then select a filter method and specify the name of the compressed files.

File filter

When compression is enabled, select the method for filtering the files to compress.



Algorithm

Specifies the algorithm to use for compression.

Level

Specifies the speed of the compression. For ZIP, JAR and GZIP the following compression levels are available: Store (level 0), Fast (level 1), Normal (level 3), Good (level 5), Best (level 6). TAR supports only Store.

Use archive password

Specifies whether a password is required to decompress the archive. Enter the password in the provided field.

Archives

Specifies whether to compress files singly or together in one archive.



Archive name

You can use a regular expression to name the archive file. If files are archived in a single file, specify the archive name or expression. If files are archived singly and no value is specified in the Archive name field, each file is archived in a different file containing the file name and the algorithm extension.

Line endingEnable to change line endings in files. Then select a filter method and specify the end of record characters in files.

File filter


Regular expression uses a regular expression for the filter. See regular expressions topics in the SecureTransport documentation for details. For example, if you specify *\.(txt|xml), all TXT and XML files are processed.


Source and Target

Specify line ending characters and encoding for source and target files.

The available line-ending formats are CRLF, LF and custom.

If custom, specify the hex encoded value of the line ending character. This is any character \n, \r, and the combination of both. The custom line ending char in Unicode notation:

Windows: \u000d\u000a

*nix, MacOS: \u000a

Mainframe: \u0025

Select the file encoding format from the available formats in the drop-down list.

Rename file as

You can use a regular expression to name output files.







Example 3. New file name based on its name after the transformation (for example, name of the file as extracted from an archive) by appending a timestamp:


Character replacementEnable to replace one or more sequences of characters in files. Then select a filter method and specify the encoding and transcoding of the files.

File filter




Find lines with

Specify a single or multiple sequences of characters to find in files, separated by commas.

Characters in ASCII and Unicode \uXXXX format are supported.

Delete found lines

Specify whether the lines with the found characters must be deleted in the file.

Yes means found lines are removed.

No means found lines are replaced with specific characters.

Replace with

Replace with one string or comma-separated strings in same respective order as find, in ASCII or Unicode \uXXXX format.

Example 1. Find is a,b,c. If replace is 123 and found text is axbxxc, after the file processing the text becomes 123x123xx123.

Example 2. Find is aaa,bbb,ccc. If replace is 123,456,789 and found text is aaaxbbbxxccc, after the file processing the text becomes 123x456xx789.

Source and Target encoding

Select the file encoding format from the available formats in the drop-down list for the source and target.

Rename file as










Line truncatingEnable truncating lines to a given line width. Then select a filter method and specify the encoding and transcoding of the files.

File filter




Truncate length

Specify the maximum length to which lines are truncated.



Rename file as










Line paddingEnable padding lines to a given line width. Then select a filter method and specify the encoding and transcoding of the files.

File filter




Line length

Specify the maximum length that lines must be padded to.

Padding character

Specify the Unicode character format \uXXXX used for padding lines.



Rename file as








External scriptEnable and manage external script execution as part of a SecureTransport flow.

Description

Optionally enter information about the script in this open field.



Filename

Enter an absolute path to the script. You can use regular expressions.

Linux example: /usr/bin/env bash -c $(FILEDRIVEHOME)/bin/agents/example.sh

Windows example: cmd /c $(FILEDRIVEHOME)binagentsexample.bat

Redirect output to server log

Select Yes to send the script output to the sever log.


26 Gateway fields in flows

The following topics describe by protocol the receive, local, routing criteria, transfer processing and send properties fields for Gateway in flows defined in Central Governance.

l Receive properties instruct Gateway how to read incoming files, where to store the incoming files (non-PeSIT protocols), and how to handle the pre-existing files (PeSIT protocol).

l Local properties instruct Gateway how to store incoming files locally.


l Transfer processing properties instructs Gateway as to what processing steps, for example running a batch script, to perform.

l Send properties instruct Gateway how to format outgoing files.

Note If an option applies to an Application object, use the syntax &(x_%parameter%) when entering a symbolic variable in the corresponding Central Governance field. If it applies to a Model or Exchmd object, use the syntax &(%parameter%).


Receive properties in flowsThe following are the receive properties fields for all protocols in flows using Gateway as relay. Fields are described when the direction is sender pushes file (receiver pulls file from sender is not supported). Default values are provided in the user interface. Change values to meet your needs.

Prerequisites l The flow is open in edit mode in the user interface.

l Gateway is in the flow as relay.

l Source and Target are selected.

l Protocol between Source and Gateway, Gateway and Target is selected.

Multiple sendersIf a flow has multiple senders, the user interface for receive properties behaves differently depending on the protocol.



Protocol preceding Gateway is SFTP, FTP or HTTPIf the protocol preceding Gateway in the flow is SFTP, FTP or HTTP, the UI displays a table that enables you to edit the receive properties for each sender by clicking Edit next to the sender's name. The Status column in the table indicates whether the properties for each sender are configured properly.

Protocol preceding Gateway is PeSITIf the protocol preceding Gateway in the flow is PeSIT, the receive properties are the same for all senders, according to the flow direction set before Gateway.

PeSIT fieldsThe following are the fields when PeSIT is the protocol between the source and the Gateway relay.

Receive properties

File propertiesOrganization

Specifies the type of organization of the incoming file.

Record format

Specifies the format of records in the incoming file.


If the record format is set with Fixed, it specifies the length of the records in the incoming file. If the record format is set with Variable, it specifies the maximum length of records in the incoming file.

Encoding

Specifies the encoding of the incoming file.

Enable truncating

Specifies if truncating is allowed despite the padding character.

Yes: The data transferred is truncated even if the removed data does not match the padding character

No: Records are truncated only if the padding character matches the data to remove (default)



Note In order for a transfer to work between Transfer CFT and Gateway, the properties for the file sent and the properties for how the file is received (and stored) should match.

Post-reception actionsThe following properties define the actions Gateway performs on a pre-existing file before receiving a file transfer with the same name.

File availability

Specifies if the Gateway server accepts incoming files with the same name as existing ones.

File action

Specifies the action Gateway takes if an incoming file has the same name as an existing one.

File availability

File action

File with same name as the incoming file

Transfer accepted

New Erase exists No

Delete exists No

Verify exists No

New Erase does not exist Yes

Delete does not exist Yes

Verify does not exist Yes

Old Erase exists Yes

Delete exists Yes

Verify exists Yes, if the existing file is empty

No, if the existing file is not empty

Old Erase does not exist No

Delete does not exist No

Verify does not exist No

Both Erase exists Yes

Delete exists Yes


File availability

File action

File with same name as the incoming file

Transfer accepted

Verify exists Yes, if the existing file is empty

No, if the existing file is not empty

Erase does not exist Yes

Delete does not exist Yes

Verify does not exist Yes

SFTP, FTP and HTTP fieldsThe following are the fields when SFTP, FTP or HTTP is the protocol between the source and the Gateway relay.

Receive propertiesReceive properties available when SFTP, FTP or HTTP is the protocol between the source and Gateway relay.

Default reception folderVirtual file directory path where the incoming files are stored. The directory path relates to "/%protocol%/%sender login id%". The following characters are not allowed in this field: * : ? "< > |

For flows with more than one sender, this field can be set for each sender, using the displayed table that enables you to edit the receive properties for each sender.

If the folder you specify does not exist in Gateway, it will be created at deployment.

A default directory field can be propagate for each receiver:

l if all sender entries are empty, they are filled with the default value

l if there are sender entries having values different then default value, user have the choice to update the values with the new default value or to keep the current values

l for sender entries set to the default value, they are updated with the new default value

Local properties in flowsThe following are the local properties fields for all protocols in flows using Gateway. Fields are described when the direction is sender pushes file. Default values are provided in the user interface. Change values to meet your needs.




l Protocol between Source and Gateway, Gateway and Target is selected.

PeSIT fields

Local propertiesDirectory

Specifies the storage directory for received files. This is a directory on the computer hosting Gateway. The following characters are not allowed in this field: * : ? "< > |

Central Governance does not verify if the folder you specify exists in Gateway. You must check to ensure that it does.

Receive file as

Specifies the name the incoming file gets when stored locally on a the computer hosting Gateway. This is the name Gateway uses to identify the file when transferring it further to the target. When this field is left blank, Gateway gives the incoming file a default name. The following characters are not allowed in this field: * : ? "< > |

Organization


Encoding


Record format


Padding character

If the record format is set to Fixed, it specifies the character to use to pad the record. This character is added to the end of the record until it reaches the maximum length as defined in Maximum record length. If you do not provide a value, the default character is a space. If the record format is set to Variable, it specifies the character or characters that are trimmed from the end of the records. For example, if the trimming character is a space and there are five spaces at the end of the record, all five spaces are removed. If you do not provide a value, the record is unchanged.



Note In order for a transfer to work between Transfer CFT and Gateway, the properties for the file sent and the properties for how the file is received (and stored) should match.

SFTP, FTP, or HTTP fields

Local properties

File propertiesOrganization


Encoding


Record format




Padding character

If the record format is set to Fixed, it specifies the character to use to pad the record. This character is added to the end of the record until it reaches the maximum length as defined in Maximum record length. If you do not provide a value, the default character is a space. If the record format is set to Variable, it specifies the character or characters that are



trimmed from the end of the records. For example, if the trimming character is a space and there are five spaces at the end of the record, all five spaces are removed. If you do not provide a value, the record is unchanged.

Routing criteriaThe following are the routing criteria properties for defining the files to route to the receiver, when Gateway is relay in a flow. The available fields are the same regardless of direction or protocol, even if certain fields apply only for a specific protocol.


l Gateway is the relay in the flow.

l Sources and Targets are selected.

l Protocol between Sources and Gateway, and then Gateway and Targets is selected.

Routing criteria propertiesYou can specify:

l 'Common routing criteria' sub-section: A set of routing criteria that applies to all pairs (Sender, Receiver).

l 'Specific routing criteria' sub-section: A set of routing criteria that applies to specific pairs (Sender, Receiver). If a property is in both sub-sections, the one from specific section is used to define the routing criteria.

Note If a flow has multiple senders and receivers, the user interface displays a table that enables you to configure the routing criteria properties for each sender-receiver pair by clicking Edit next to the pair's names.

AttributesA routing criteria consists of three non-empty attributes:

l Parameter: incoming transfer property used to decide if a file is routed to the receiver

l Operator: used to define the triggering criteria

l Value: the value you want to assign to the Parameter

See the tables for the complete list of parameters, operators, and values.

Parameters having a string value



originator alias, destination alias, remote agent, local agent, param1, param2, application, dir path, file component, file label, file name, originator, destination, file type, xfer ident, directory name, called address, called SAP, group, rcv user, rcv appli, rcv text, rcv msg

Parameters having a numeric value

rec length, padding, block size, xfer rec length, yday

Parameters having an enumeration value

Parameter Value Possible values in CG

Comment

protocol enum PHSE, FTP, HTTP, SFTP Protocol between Sender and Relay

type enum TRANS, RECEIPT Transfer type

direction Enum I, O Direction between Sender and Relay:

I (Incoming), O (Outgoing)

mode Enum R Mode for Relay:

always 'R (Responder)'

file organization Enum S, I, R File organization:

S (Sequential)I (Indexed)R (Relative)

rec format Enum F, V, S, FT, VT Record Format:

F (Fix)V (Variable)S (Stream)FT (Fix text)VT (Variable text)




Comment

data code Enum AEBISOOEMPCA1A2A3A4A5E1E2E3E4 E5U

Data code:

A (ASCII)E (EBCDIC)B (BINARY)ISOOEMPCA1 (ASCII1)A2 (ASCII2)A3 (ASCII3)A4 (ASCII4)A5 (ASCII5)E1 (EBCDIC1)E2 (EBCDIC2)E3 (EBCDIC3)E4 (EBCDIC4)E5 (EBCDIC5)U (Undefined)

xfer rec format Enum FVST

Transfer record format

F (Fix)V (Variable)S (Stream)T (text)

xfer data code Enum AEBISOOEMPCA1A2A3A4A5E1E2E3E4 E5U

v1=A (ASCII)v2=E (EBCDIC)v3=B (BINARY)ISOOEMPCA1 (ASCII1)A2 (ASCII2)A3 (ASCII3)A4 (ASCII4)A5 (ASCII5)E1 (EBCDIC1)E2 (EBCDIC2)E3 (EBCDIC3)E4 (EBCDIC4)E5 (EBCDIC5)U (Undefined)

newline convention Enum UW

Newline convention:

U (Unix)W (Windows)


Comment

text file Enum N, Y Text file:

N (No), Y (Yes)

The list of available operators depends on the parameter type:

l Numeric: all operators =, #, <, >, =<, >=, <>, ><, [], ][

l String: all operators, except ‘[]’ and ‘][’

l Enumeration: =, #, <>, ><

When no routing criteria is set, the trigger condition is always used. When a routing criteria is defined, the trigger condition is based on the entered expression. In case of several conditions are set, all conditions have to be matched.

Special characters and symbolic variables l wildcards are allowed: * (replaces a group of several characters) and ? (replaces one character).

l symbolic variables usage is allowed and is limited to the Gateway syntax and the list of variables known by Gateway in the context of a decision rule: &(<variable_name>). Please see Gateway configuration for details.

Note Some basic syntax validation is made on the routing criteria value, which depends on the type of the parameter and the operator used to define the condition:

For operators: =, #, <, >, <=, >=

type numeric: value should contain only numeric characters

type string: size of the input string should be no more than 1024 chars

type enumeration: only the options declared for the parameter are allowed

For operators: <>, ><

Value is actually a list that includes a set of values separated by a comma (,). The same rules as above apply for each value.

For operators: [], ][

Value is actually a list that includes/excludes two values separated by a comma (,). This applies only for numeric type values.

If the syntax is incorrect, the transfer is normally not executed.


Broadcast behaviorUpon execution, if the incoming file’s metadata matches the routing criteria for a pair (Sender, Receiver), the file reaches the corresponding receiver either pushed by the relay or pulled by the receiver.

If the incoming file’s metadata match routing criteria for multiple (Sender, Receiver), either pushed by the relay or pulled by receiver, the behavior in Gateway is similar to the current behavior of the transfers with diffusion lists. See Gateway documentation for more details.

Acknowledgment behaviorIn case of a file routed to multiple targets, when first of the targets sends acknowledgment back to Gateway, the parent transfer becomes acknowledged. Only the first acknowledgment is sent back to the source.

Transfer processing in flowsThis section describes how to configure the actions to perform, for example run a Perl script or a batch command, when an incoming exchange (Gateway is target) matches certain defined processing criteria.

Transfer processing fieldsSet the following properties when Gateway is relay in a flow, regardless of protocol selected between the relay and the target or source.

Name

Enter a name for the processing action.

Description

Optionally enter a description for the transfer processing having a maximum of 100 characters.

Active

Specifies if transfer processing is used, where Yes (default) is enabled.

Execution type

Specifies the type of processing, either a Batch command (default), or Perl script.

Batch command

Enter a batch command string or Perl script path having a maximum of 510 characters.



Processing criteria

Specifies the criteria for triggering transfer processing and works as Routing criteria on page 413 do, with the following two additional, mandatory fields:

l Transfer state - Ended (default).

l Transfer direction - Incoming (default).

l Parameter

Additionally, you can use the Add processing criteria option.

Add or remove processing actionsFrom the Common processing list, use the buttons Add transfer processing and Remove to create new actions or delete existing actions. Select the action or actions in the list, and click the appropriate button. Then click OK to confirm.

Transfer processing executionIf there are multiple transfer processing actions selected for a transfer state transition, only the first processing action is executed.

Note The order in which the processing action was created in Central Governance, in the Transfer processing section, determines the execution priority if there are multiple transfer processing actions that match the criteria.

The Transfer state change Gateway decision rules that match the criteria are not executed for Central Governance flows. If an error occurs when launching the transfer processing actions, all the future actions are canceled.

Send properties in flowsThe following are the send properties fields for all protocols in flows using Gateway. Fields are described when the direction is sender pushes file and receiver pulls file. Default values are provided in the user interface. Change values to meet your needs.




l The protocol between Source and Gateway, Gateway and Target is selected.



Multiple receiversIf a flow has multiple receivers, the user interface for send properties behaves differently depending on the protocol.

Protocol after Gateway is SFTP, FTP or HTTPIf the protocol after Gateway in the flow is SFTP, FTP or HTTP, the send properties, with one exception, are the same for all receivers, according to the flow direction set after Gateway. The remote directory, when sender pushed file, or the directory when receiver pulls file, is the only property configured for each receiver. To set this field for each receiver, the UI displays a table that enables you to edit the directory field for each receiver by clicking Edit next to the receiver's name. The Status column in the table indicates whether the properties for each receiver are configured properly.

A default directory field can be propagate for each receiver:

l if all receivers entries are empty, they are filled with the default value

l if there are receiver entries having values different than default value, user have the choice to update the values with the new default values or to keep the current values.

l for receivers entries set to the default value, they are updated with the new default value

Protocol following Gateway is PeSITIf the protocol after Gateway in the flow is PeSIT, the send properties are the same for all receivers, according to the flow direction set after Gateway.

PeSIT fields

Send properties, Gateway is relaySet the following properties when Gateway is relay in a flow and PeSIT protocol is selected between the relay and the target. Send properties are the same for both directions (sender pushes file or receiver pulls file).

Organization


Encoding


Record format






Enable truncating


Yes: The data transferred is truncated even if the removed data does not match the padding character

No: Records are truncated only if the padding character matches the data to remove (default)

Send properties, Gateway is targetSet the following properties when Gateway is the target in a flow.

Enable

Yes (default) activates the send properties configuration.

Upload directory

Configure the upload folder, where the incoming file is copied (mandatory).

Create directory if it does not exist

Allows you to decide if you want to create a new upload folder.

Upload file as

Optionally, you can upload the file under a specific name; if the file is not specified, the Gateway file name kept.

SFTP, FTP or HTTP fields

Send propertiesSet the following properties when Gateway is relay in a flow and SFTP, FTP or HTTP protocol is selected between the relay and the target. Send properties differ slightly depending on the exchange direction (sender pushes file or receiver pulls file), as follows:

l If direction is sender pushes file, you have to set the Remote directory and the File name sent.

l If direction is receiver pulls file, you have to set the Directory and the Publish file as.

l The rest of the fields are common for both directions.


File propertiesRemote directory

Represents the directory on the receiver side where Gateway sends the files. This field applies only for Direction = Sender pushes file. The following characters are not allowed:

: * ? "< > |

Central Governance does not verify if the folder you specify exists on the receiving computer. You must check to ensure that it does.

File name sent

Represents the name of the file that Gateway sends. If this field is not used, the file is sent with the original name that it was given by the sender. This field applies only for Direction = Sender pushes file. The following characters are not allowed:

: * ? "< > |

Directory

The directory where Gateway makes available files for the receiver to pull. This field applies only for Direction = Receiver pulls file. The following characters are not allowed:

: * ? "< > |

Central Governance does not verify if the folder you specify exists on Gateway. You must check to ensure that it does.

Publish file as

Represents the name of the published file. If this field is not used, the name used is the name of the file Gateway received from the sender. This field applies only for Direction = Receiver pulls file. The following characters are not allowed:

: * ? "< > |

Organization


Encoding


Record format


Enable truncating


l Yes: The data transferred is truncated even if the removed data does not match the padding character

l No: Records are truncated only if the padding character matches the data to remove (default)

Identification method (HTTP only, when sender pushes a file)

Select the identification method to use when transferring files:

CGI: adds user and password to the CGI parameters

Web: standard HTTP identification method (adds user and password to HTTP headers)

Cookies: adds user and password to CGI parameters of the login request.

If you select this option, complete the Login request fields:

Login path: Specify the URL path to the server CGI script that will identify Gateway and return the cookie. Specify the path to use with the login request. For example: /cgi-bin/login.cgi. This is not an absolute URL.

HTTP method: Select the HTTP method to use with the login request.

Login CGI parameters: Enter additional CGI parameters to add to the login requests

PeSIT file properties for interoperabilityWhen Gateway receives a file, the properties for the file sent and the properties for how the file is received, and stored, should match.

When Transfer CFT is the source of the transfer and Gateway is the relay or target, and Transfer CFT is using its default properties, Gateway's receive and local properties should correspond. The Maximum record length, for example, is 4096 for Linux, and 512 for Windows.

If Transfer CFT and Gateway are on different platforms, you must synchronize the Maximum record length field accordingly.

In conclusion, when Gateway is receiving data it should have the maximum record length greater than or equal to the maximum record length of the sender of the data, set in 'Receive properties' and 'Local properties' for the PeSIT protocol.


27 Transfer CFT fields in flows

The following topics describe the Transfer CFT fields in flows defined in Central Governance.

Source and target fields in flows control the behavior of transfers. You can define source or target properties when the source or target is applications or a group of applications associated with Transfer CFTs. Source and target properties have default values.

Transfer CFT source fields in flowsSource fields in flows control the behavior of a transfer. You can define source properties when the source is applications or a group of applications associated with Transfer CFTs. Source properties have default values.

If a flow has multiple applications as a source or target, you can customize properties for each source and target product respectively, for each property type. For instance, if a flow has two Applications each linked to a different Transfer CFT as target, one on Linux and the other on Windows, you can specify a different working directory and processing script files for each Transfer CFT. This option is disabled by default.

The following topics are related to source properties for Transfer CFT:

l Source transfer properties on page 424

l Source file properties on page 428

l Source processing scripts on page 436

The following are the steps to get started.

1. Open the flow in edit mode, if not already opened.



2. Add a source, if you haven't already done so.

3. Click the name of the source to display the menu of properties.

4. Click the type of property you want to change.

5. Optionally, for each property type you can configure specific parameters per source.



Source transfer propertiesDefault values are provided for source transfer properties in the user interface for Transfer CFT. Change values to meet your needs.

Prerequisites l General flow information is defined

l Source or sources are selected

l The source properties page is displayed. See Transfer CFT source fields in flows on page 423 for the procedure to access this page.

Fields Transfer priority

Transfer priorities are equivalent to integer values ranging from 0 (low) to 255 (high). If you select Custom, you must enter an integer between 0 and 255. Note that the integer value for medium priority is 128.

When Transfer CFT reaches the maximum number of transfers allowed, it queues transfers. When an ongoing transfer is finished and a slot is available for a new transfer, the system selects the one with the highest priority.

Transfer priority is available when the initiator is the source.

Bandwidth allocation

The amount of bandwidth allocated to this flow. The value you select determines the data transfer rate for this flow.

Transfer state

Indicates the state of the transfer request.

l Ready - Transfer is available and can start immediately.

l On hold - Transfer is deferred until a remote receive request is accepted, or until a local start command changes this transfer to the ready state.

l Kept - Transfer is deferred until a local start command changes this transfer to the ready state.

User ID

The identifier of the transfer owner.

Sending user ID

The identifier of the user sending the transfer.



Receiving user ID

The identifier of the user receiving the transfer.

Detect duplicate transfers

This field is used in detecting duplicate transfers and may contain a list of symbolic variables separated by a period ".". Duplicate transfers can occur, for example, if there is an error in a processing script. Possible variables include:

l &PART

l &IDF

l &DIRECT

l &MODE

l &SAPPL , &RAPPL

l &IDA

l &SUSER , &RUSER

l &FNAME, &NFNAME

l &SYSDATE, &SYSTIME

l &PARM

Example: &PART.&IDF.&IDA.&SAPPL

See Symbolic variables on page 370 for descriptions of the variables.

Compress file

Indicates whether files are compressed before transferred.

Do not enable compression if the type of files being transferred would not benefit from it and possibly result in longer processing times. For example, do not activate compression if transferring JPG or ZIP files.

On file not found

Specify what happens when files to transfer are not found.

l Abort transfer - Transfer fails and status is changed to Canceled.

l Ignore transfer - Transfer is successful and status is changed to Completed.

This parameter is available starting with Transfer CFT 3.1.3 Service Pack 4.

On file modification

Specify what happens if files are modified during the transfer.

l Continue transfer - Modified file is transferred.

l Stop transfer - Transfer status is changed to Kept.

Action after transfer

Specifies what happens to the file when the transfer has completed.



l Delete - Deletes the file.

l Delete file content - Removes the contents of the file but leaves the end-of-file mark at the beginning of the file.

l None - No action is performed on the file.

Delete file on purge

Indicates the transfer states of files that will be deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the associated transfers are removed from the transfer list.

l Ready (D) - Transfer is available and can start immediately.

l Transferring (C) - Transfer is being executed.

l On hold (H) - Transfer was interrupted due to an error, such as a network failure, or by a user.

l Kept (K) - Transfer was suspended by Transfer CFT or by a user.

l Transferred (T) - Transfer was completed successfully.

l Executed (X) - Transfer was ended by an application or user.

Purge completed transfer

Indicates whether a completed transfer is purged from the transfer list or kept.

l Yes - Transfer CFT purges the transfer from the transfer list when the status is Completed.

l No - Transfer CFT keeps completed transfers in the transfer list.


Use this field for any information you want to provide. For example, you can use this field to propagate some business identifiers or values from the source to the target at the protocol level (without having to open the files). Note that in this use case, the attribute must be populated dynamically at runtime for each file transfer.

Maximum transfer duration

The maximum time in minutes to complete a file transfer before the transfer is canceled. If a transfer times out, you can restart the transfer manually. A transfer will not restart automatically. A value of 0 indicates there is no time limit.

This field is only available for the flow initiator. That is, it is only available for the source when the source is the initiator and it is only available for the target when the target is the initiator.

Activation period

If enabled, you can define the interval when transfers can occur by setting a start date and time and an end date and time.




VisibilityOn file modification

Specify the level of transfer process step details that are sent as events to the Visibility service.

l Default – Events are sent as defined in the configuration of the source Transfer CFT.

l All – Events related to every step of the transfer process are sent.

l First and last – Events related to only the initial and final steps of each transfer process are sent.

l None – No events are sent.

l Error - Only error events are sent.

BroadcastingA broadcast list represents the list of targets in the flow. Using a broadcast list enables to you send a file to all targets in the list with a single command. See Transfer CFT broadcast and collect on page 336 for more information.

Broadcast list

Enables or disables the use of a broadcast list. If you enable broadcast list (choose either File or Partner list) and have fewer than two targets defined, a warning message is displayed.

l File – Using a file in which the list of partners is saved.

l Partner list – Explicitly using a list type parameter. If there are more than 200 targets defined, a warning message is displayed specifying that the File option should be used instead. Transfer CFT partner list is limited to 200 targets.

l None – Disable the broadcast list.

When you enable broadcast list, the following fields are displayed depending on whether you select File or Partner list.

Name

Identifier for the list of targets defined in the flow. The name must be unique among all flows for the source or sources.

This field displays when you select either File or Partner list.



File

Specifies if either a new broadcast list file is created, or an existing file is used.

l Create file (default) - Uses a file in which the list of partners is saved. The file is automatically generated based on the selected targets

l Use existing file - Uses an existing file, which contains the list of partners, that is located in an application directory outside of the Transfer CFT installation directory.

This field displays when you select File.

Filename

Name of the broadcast list file. The new file is available on Transfer CFT after the flow is deployed successfully. The new file is uploaded to Transfer CFT with the default path $(cft.runtime_dir)/conf/ws_upload. The file is overwritten if it already exists on Transfer CFT.

This field displays only when you select File.

Unknown target

Specifies the action to take when a target in the broadcast list is not found.

l Continue – Display an informational message and continue processing

l Ignore – Continue processing without an informational message

l Cancel – The transfer stops at the first error, but all transfers that were started before the error continue. For example, if you have 10 targets in the list and the fourth one is unknown, targets 1, 2 and 3 receive the file, but targets 4-10 do not.


Configure specific parameters for each source

Specifies whether to enable configuring different transfer properties values for each source product.

This field displays when you select multiple sources.

If you select Yes, a table listing all the source products is displayed. Click Edit to customize parameters for a source.

Source file propertiesDefault values are provided for source file properties in the user interface for Transfer CFT. Change values to meet your needs.






Fields

FilenameFiles

Indicates whether a single file or multiple files are being sent.

Filename

If you selected Single, specify the path to the file where the files to be transferred are located.

The value you enter must represent a single file.

The file name can include the following symbolic variables:

l &FDATE, &FTIME, &FYEAR, &FMONTH, &FDAY

l &SPART, &RPART, &PART, &NPART, &GROUP

l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF, &IDTU

l &BDATE, &BTIME, &BYEAR, &BMONTH, &BDAY

l &NFNAME, &NFVER


Path

If you selected Multiple, specify the path to the directory where the files to be transferred are located.

The value you enter can be:

l A directory name – All the files in this directory will be transferred.

l A generic file name, including wildcard characters – Only files that match are transferred. For example, mydirectory/toto*.



The maximum length of this field is 64 characters. Enclose the value in quotes to preserve case sensitivity.

This field is required if the target is the initiator of the flow.

File list

This field is displayed if you selected Multiple as the Files option.

Specify the name of the file that contains the list of files to be transferred. This file is also referred to as an indirection file. It must contain one file name per record, and that name must start in the first column of the file. The file names contained in the file must not contain an asterisk (*).

Archive name

Name of the file that contains the set of files to be transmitted. Archive files are sent between systems that have the same operating system (grouped mode). The archive file is created automatically by Transfer CFT at the time of the transfer. The file created is a ZIP file on Windows systems and a TAR file on Linux and UNIX systems. Because Windows systems do not have default compression utilities, Transfer CFT for Windows includes zip and unzip utilities.




l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF, &NFNAME, &IDT



Working directory

The path to the directory for sent files in process and temporary files. The working directory specifies a directory other than the default runtime directory for file transfer flows. All files related to the transfer flow — sent and temporary files and scripts — must be part of the working directory tree.

File name sent

Specify the name of the physical file that is to be used during transmission over the network.

If the file name is preceded by an asterisk (*), the target can keep the transmitted name or rename the file. The file name can include the following symbolic variables:





l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF



The file is transferred providing the following conditions are met:

l The target authorizes the source (requester or server) to set the physical name of the file to be received as defined in the Path field.

l The file name specified in this field exists or can be created at the target.

File encodingThe file encoding fields vary depending on the Transfer CFT operating system.

Windows and Linux

File type

Specifies whether the file is a binary or text file.

Select Binary to send a mix of file types and ensure there is no custom encoding or transcoding required for the text files. If the text files have custom encoding or transcoding requirements, you must define specific flows for them.

The following fields are displayed for the text file type.

End of record character

Indicates the end of record character used in the file.

Ignore end of file character

This field is displayed only if you selected CRLF as the end of record character and if the source Transfer CFT is on a Windows system.

l No - Transfer CFT ends the transfer when it encounters an end-of-file character.

l Yes - Transfer CFT continues the transfer until there is no more data.

Encoding

Represents how the data in the file to be sent is encoded.

If you select Custom, enter the character set in the provided field.

Transcoding

Represents how the data in the file is encoded while it is being sent to the target.




See Transcoding and character translation on page 434.

OS/400 (IBM i)

File type

The following describes the available options.

l Data file specifies the file is a PF-DTA file.

l Save file specifies the file is a SAVF file.

l Source specifies the file is a PF-SRC (with header) file.

l OS 400 specific specifies the file is a PF-SRC (no header) file.

Encoding


If you select Custom, the Encoding charset field is displayed where you can enter the character set.

Transcoding



z/OS

File type


l Autodetect specifies the file is sent in auto detection mode.

l Print file with ASA jump codes specifies the file is print file with ASA jump codes.

l Print file with machine jump codes specifies the file is print file with machine jump codes.

l Spanned variable format specifies the file is a spanned variable file.

l ARDSSU specifies the file is a ADRDSSU file.

l Binary specifies the file is a binary file.

l Text specifies the file is a text file.

l Stream text specifies the file is a text file sent in Stream CFT mode.

Select Binary to send a mix of file types, and make sure there is no custom encoding or transcoding required for the file types:

l Print file with ASA jump codes



l Print file with machine jump codes

l Text

If the text files have custom encoding or transcoding requirements, you must define specific flows for them.

Encoding



Transcoding



Record formatRecord type

Indicates whether the records in the file are fixed or variable length. Selecting Autodetect automatically identifies the record type.

Padding character

This field is displayed if Fixed is the selected record type. Specify the character to use to pad the record. This character is added to the end of the record until it reaches the maximum length as defined in the Maximum record length field. If you do not provide a value, the default character is a space.

Trimming character

This field is displayed if Variable is the selected record type. Specify the character to use to remove padding characters from the end of the record. For example, if the trimming character is a space and there are 5 spaces at the end of the record, all 5 spaces are removed. If you do not provide a value, the record is unchanged.


If you select Default OS value, Transfer CFT correctly interprets maximum record length as:

l On Windows, 512 characters

l On Linux or UNIX, 512 characters for text files; 4096 characters for binary files

If you select Custom, enter a value in the provided field.







Transcoding and character translationWhen defining source and target file properties, you specify how the data files are encoded on each end of the transfer. If the source and target require ASCII-encoded data, you specify ASCII encoding on both source and target file properties. In the source file properties, the Transcoding field defines how data are encoded during the transfer process. If None is set for transcoding, ASCII or EBCDIC is the value when the transfer is executed, depending on the partner's operating system. This is important when transferring files with different coding requirements on the source and target systems.

Custom encoding and transcodingWhen you specify Custom in the Encoding or Transcoding fields, you must also enter the character set (charset) needed to convert the data. Custom values rely on the iconv program and API on UNIX/Linux platforms and on GNU iconv on Windows. This means that the charset value you enter must correspond to a valid iconv value for the host. This value is passed to both the source and target systems when the data flow is deployed.

Most of the character sets supported by Transfer CFT can be used for transcoding. These include UTF-8, UTF-16, UTF-32, UCS-2, ISO8859-1, ASCII, BIG5, cp850, and EBCDIC.

Example 1: Source and target have same encoding requirementsThis example shows ASCII to ASCII transfers. For EBCDIC to EBCDIC transfers, enter EBCDIC in the Encoding and Transcoding fields. No character translation is required.

Source

Encoding – ASCII

Transcoding – ASCII

Target

Encoding – ASCII



Example 2: Source is ASCII and target is EBCDICThis example shows ASCII to EBCDIC transfers.

Source

Encoding – ASCII

Transcoding – Select ASCII if you want the target to perform the translation from ASCII to EBCDIC, or select EBCDIC if you want the source to do it.

Target

Encoding – EBCDIC

Example 3: Custom: UTF-8 to UTF-32The source sends a file encoded in UTF-8 and the target expects a file in UTF-32. Neither the source nor the target can directly translate from UTF-8 to UTF-32 because the source does not support UTF-32, and the target does not support UTF-8. However, both support UTF-16. Therefore, specify UTF-16 as the transcoding charset to have source convert the file to UTF-16 for the transfer. When the target receives the file, it converts it from UTF-16 to UTF-32.

Source

Encoding – Custom

Encoding charset – UTF-8

Transcoding – Custom

Transcoding charset – UTF-16

Target

Encoding – Custom

Encoding charset – UTF-32

Best practicesUse variable text files whenever possible because there is normally no shrinking or padding with this file type.

When dealing with multi-byte encoding on files with fixed or limited record size, be aware of the following:

l Shrinking a record may cause an unrecoverable error if it occurs in the middle of a multi-byte character.

l Record padding may cause an unrecoverable error if the number of characters to be padded is not a multiple of the pad character (by default, a blank for a text file and a zero for binary files).



l For streamed text files, either variable or fixed length, the CRLF characters used to separate records are from the encoding charset.

ErrorsThe following table describes some common transcoding errors and corrective actions.

Cause Action

The charset is incorrect or it is not installed on your local system

Check your local configuration. If the charset is not found, add the charset to your system.

The file you are sending might contain an invalid character sequence or it cannot be transcoded to the charset destination.

Check the file and your configuration.

The file format is incorrect. Verify the correct file format is defined.

Source processing scriptsThe source processing scripts section of the flow definition identify the scripts to execute at specific phases in the flow lifecycle. See Flow lifecycle on page 298 for detailed information.

For each phase, you can select whether to execute the default script or a custom script. Default scripts, with the exception of pre-processing scripts, are defined in the configuration of the Transfer CFT involved in the flow. For example, SalesApp1 running on CFT001 is defined as the source in the flow. The default post-processing script defined in the CFT001 configuration is exec/default_postprocessing.sh (the actual default value is exec/&IDF.sh). If that is the script you want executed in the flow, you select the Default option.

To execute a different script, you must select the Custom option. Default scripts are defined in the Transfer processing section of the Transfer CFT configuration. See Transfer processing on page 224.

Processing scripts are executed on the source during the following phases:

l Pre-processing – Before the file is transferred

l Post-processing – After the file is transferred

l Acknowledgment – After an acknowledgment is sent by the target

l Error – After an error occurs during a transfer

For setting a custom processing script, you can:

l Set an existing script already on the source Transfer CFT.

or



l Upload a new script. The new script is available on the Transfer CFT after the flow is deployed successfully on the Transfer CFT. The new script is uploaded to Transfer CFT with the default path $(cft.runtime_dir)/conf/ws_upload. If the file already exists on Transfer CFT, it is overwritten.





Source pre-processing scriptsA pre-processing script is executed before the file is transferred.




Fields Script

Indicates whether to execute a pre-processing script. There are no default pre-processing scripts.

File

If you select Custom, specify whether to use an existing file or upload a new file.

Filename

If you select Custom and select to use an existing file, specify the script to run. This name can include the following symbolic variables:

l &IDF, &PARM

l &PART, &RPART, &SPART, &GROUP

l &RUSER, &SUSER, &USERID

l &RAPPL, &SAPPL

l &NIDF




Choose file

If you select Custom and select to upload a new file, select the file. The destination path is configured on Transfer CFT by the parameter copilot.webservices.upload_directory.

State

Indicates the status of the transfer on the source. The script is run only if the transfer is in the specified state.


l On hold - Transfer is deferred until a remote receive request is accepted, or until a local START command changes this transfer to the ready state.

Apply to broadcast list

This field is displayed if you enabled a broadcast list in source transfer properties.

l On main request – Executes the script only on the main request.

l For each target in the list – Executes the script only for each target in the list.

l Both – Executes the script both for the main request and for each target in the list.

Source post-processing scriptsA post-processing script is executed after the file is transferred.




Fields Script

Indicate whether to execute the default or a custom post-processing script. The default script is defined in the configuration of the source Transfer CFT in the flow.

File




Filename

If you select Custom and select to use an existing file, specify the custom script to run. If the file does not exist, no post-processing is performed even if a default post-processing script is defined in the Transfer CFT configuration, and an error is raised.

This name can include the following symbolic variables:

l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


Apply to group of files

This field is displayed if you selected Multiple for the File parameter in source file properties.

Specify the rule for executing the script on the group of files. When sending a group of files, there are two types of request: a generic request that applies to the entire group, and a specific request. There will be one specific request if the transfer is done in grouped mode, and multiple specific requests (one for each file) if the transfer is done in file-by-file mode.

l On main request – Execute the script only on the main request

l For each file in group – Execute the script for each file in the group but not for the main request

l Both – Execute the script both for the main request and for each file in the group








Source acknowledgment scriptsAn acknowledgment script is executed after an acknowledgment is received for a sent file.




Fields Script

Indicates whether to execute the default or a custom acknowledgment script. The default script is defined in the configuration of the source Transfer CFT in the flow.

Filename

If you select Custom and select to use an existing file, specify the custom script to run. If the file does not exist, no processing is performed even if a default acknowledgment script is defined in the Transfer CFT configuration, and an error is raised.


l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


State

Indicates whether the transfer must wait for an acknowledgment.

l Require – Transfer must wait for an acknowledgment before it can be considered complete.

l Ignore – Transfer can be considered complete, even if an acknowledgment is not received.














Source error scriptsAn error script is executed after an error occurs during a transfer.




Fields Script

Indicates whether to execute the default or a custom error script. The default script is defined in the configuration of the source Transfer CFT in the flow, and an error is raised..

File




Filename

If you select Custom and select to use an existing file, specifies the custom script to run. If the file does not exist, the default error script defined in the Transfer CFT configuration is executed.


l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


Transfer CFT target fields in flowsTarget fields in flows control the behavior of a transfer. You can define target properties when the target is applications or a group of applications associated with Transfer CFTs. Target fields have default values.

The following topics are related to target property types for Transfer CFT:

l Target transfer properties on page 443

l Target file properties on page 448

l Target processing scripts on page 452

The following are the steps to get started.

1. Open the flow in edit mode, if not already opened.



2. Add a target if you haven't already done so.

3. Click the name of the target to display the menu of properties.

4. Click the type of property you want to change.



Target transfer propertiesDefault values are provided for target transfer properties in the user interface for Transfer CFT. You can edit the defaults to meet your needs.


l Target or targets are selected

l The target properties page is displayed. See Transfer CFT target fields in flows on page 442 for the procedure to access this page.

Fields Transfer priority



Transfer priority is available when the initiator is the target.



Transfer state





User ID


Sending user ID

The identifier of the user sending the transfer.



Receiving user ID

The identifier of the user receiving the transfer.



l &PART

l &IDF

l &DIRECT

l &MODE

l &SAPPL , &RAPPL

l &IDA

l &SUSER , &RUSER

l &FNAME, &NFNAME


l &PARM



On file not found

Specify what happens when files to transfer are not found.

l Abort transfer - Transfer fails and status is changed to Canceled.

l Ignore transfer - Transfer is successful and status is changed to Completed.

This parameter is available starting with Transfer CFT 3.1.3 Service Pack 4.

No file exists

Specifies the action taken if the received file does not already exist.

l Create – File is created.

l Cancel – Transfer is refused.

Invalid options are disabled. Note that you cannot select Cancel in this field and in the File exists field. If that was possible, all transfers would fail.

File exists

Specifies the action taken if the received file exists.

l Delete – Existing file is deleted.




l Overwrite – Existing file is overwritten.

l Overwrite only if empty – Existing file is overwritten only if it has no data.

l Overwrite after receiving temporary file – UNIX only: Existing file is overwritten after receiving the temporary file. This option is available only for Transfer CFT on Unix. The user who performs the transfer must have rights to rename the temporary file name into the file to overwrite.

l Retry renaming after receiving temporary file - After receiving the temporary file, multiple attempts are made to rename the temporary file with the file name.

Invalid options are disabled. You cannot select Cancel in this field and in the No file exists field. If that were possible, all transfers would fail.

Aborted transfer

Specifies the action taken if a transfer is terminated due to a file creation error on the target.

l Keep – Transfer remains in the transfer list.

l Delete – Transfer is removed from the transfer list.










Indicates whether a completed transfer is purged from the transfer list or kept.

l Yes - Transfer CFT purges the transfer from the transfer list when the status is Completed.

l No - Transfer CFT keeps completed transfers in the transfer list.


The maximum time in minutes to complete a file transfer before the transfer is canceled. If a transfer times out, you can restart the transfer manually. A transfer will not restart automatically. A value of 0 indicates there is no time limit.




Activation period

If enabled, you can define the interval when transfers can occur by setting a start date and time and an end date and time.


VisibilityOn file modification

Specify the level of transfer process step details that are sent as events to the Visibility service.

l Default – Events are sent as defined in the configuration of the target Transfer CFT.

l All – Events related to every step of the transfer process are sent.

l First and last – Events related to only the initial and final steps of each transfer process are sent.

l None – No events are sent.

CollectingA collect list represents a list of sources. Using a collect list enables to you receive a file from all sources in the list with a single command. See Transfer CFT broadcast and collect on page 336 for more information.

Collect list

Enables or disables the use of a collect list. If you enable the collect list (chose either File or Partner list) and have fewer than two sources defined, a warning message is displayed.

l File – Using a file in which the list of partners is saved. The file is automatically generated based on the selected sources.

l Partner list – Explicitly using a list type parameter. If there are more than 200 sources defined, a warning message is displayed specifying that the File option should be used instead. Transfer CFT partner list is limited to 200 sources.

l None – Disable the collect list.

When you enable collect list, the following fields are displayed depending on whether you select File or Partner list.



Name

Identifier for the list of sources defined in the flow. The name must be unique among all flows for the target or targets.


File

Specifies if either a new collect list file is created, or an existing file is used.

o Create file (default) - Uses a file in which the list of partners is saved. The file is automatically generated based on the selected sources.

o Use existing file - Uses an existing file, which contains the list of partners, that is located in an application directory outside of the Transfer CFT installation directory.

Filename

Name of the collect list file. The new file is available on Transfer CFT after the flow is deployed successfully. The new file is uploaded to Transfer CFT with the default path $(cft.runtime_dir)/conf/ws_upload. The file is overwritten if it already exists on Transfer CFT.

This field displays only when you select File.

Unknown source

Specifies the action to take when a source in the collect list is not found.

l Continue – Display an informational message and continue processing

l Ignore – Continue processing without an informational message

l Cancel – Transfer stops at the first error, but all transfers that were started before the error continue. For example, if you have 10 sources in the list and the fourth one is unknown, the file is received from sources 1-3, but not from sources 4-10.


Configure specific parameters for each target

Specifies whether to enable configuring different transfer properties values for each target product.

This field displays when you select multiple targets.

If you select Yes, a table listing all the target products is displayed. Click Edit to customize parameters for a target.



Target file propertiesDefault values are provided for target file properties in the user interface for Transfer CFT. Modify the defaults to meet your needs.




Fields Filename

Specify the file name or full path name for the received file or files. This field is required if the initiator of the flow is the source. Default value: pub\&IDF.&IDTU.&FROOT.RCV



l &SPART, &RPART, &PART, &IPART, &NPART, &GROUP

l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF, &IDTU, &IDT


l &NFNAME

l &NFVER


Working directory

The path to the directory for received files in process and temporary files. The working directory specifies a directory other than the default runtime directory for file transfer flows. All files related to the transfer flow — received and temporary files and scripts — must be part of the working directory tree.

Temporary file

Specify the name of the temporary file used during the transfer. When the transfer is complete, the temporary file is renamed using the name defined in the Filename field. If you do not specify a value, Transfer CFT creates the file with the name specified in the



Filename field. If the File exists parameter is set to Overwrite after receiving temporary file, Temporary file becomes required.




l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA




Receiving file size

The file size in kilobytes allocated when receiving the file. When the value is 0, the file size is specified by the sender. The parameter is available only for Transfer CFT on z/OS computers.

File encodingThe file encoding fields vary depending on the Transfer CFT operating system.

Windows and Linux

File type

Specify whether the file is a text or binary file, or opt to use autodetect.

The following fields are displayed for the text file type only.




This field is displayed only if you selected CRLF as the end-of-record character and if one of the source Transfer CFTs is on Windows.



Encoding

Represents how the data is stored/encoded on the Transfer CFT side upon reception.




Transcoding

Represents how the data in the file is decoded on reception (how the data is received from the network).



The following field is displayed for the stream text file type.

Encoding


OS/400 (IBM i)

File type







Encoding



Transcoding




z/OS

File type












l PDSE specifies the file is a PDSE file.




l Text


Encoding



Transcoding

Represents how the data in the file is decoded on reception (how the data is received from the network.



Record formatRecord type


Padding character




Trimming character











Target processing scriptsThe target processing scripts section of the flow definition identify the files to execute at specific phases in the flow lifecycle. See Flow lifecycle on page 298 for detailed information.

For each phase, you can select whether to execute the default script or a custom script. Default scripts are defined in the configuration of the Transfer CFT involved in the flow. For example, ProdCat1 running on CFT100 is defined as the target in the flow. The default post-processing script defined in the CFT100 configuration is exec/default_postprocessing.sh (the actual default value is exec/&IDF.sh). If that is the script you want executed in the flow, you select the Default option.


Processing scripts are executed on the target during the following phases:

l Post-processing – Executed after the file was received

l Acknowledgment – Executed after the file is transferred

l Error – Executed if an error occurs when a file is received




l Set an existing script already on the target Transfer CFT.

or






Target post-processing scriptsA target post-processing script is executed after a file is received.




Fields Script

Indicate whether to execute the default or a custom post-processing script. The default script is defined in the configuration of the target Transfer CFT in the flow.

File


Filename



l &IDF, &PARM





l &RAPPL, &SAPPL

l &NIDF


Choose file


Apply to collect list


This field is displayed if you enabled a collect list in target transfer properties.


l For each source in the list – Executes the script only for each source in the list.

l Both – Executes the script both for the main request and for each source in the list.

Target acknowledgment scriptsA target acknowledgment script is executed after the file is received and post-processing is complete.




Fields Script

Indicate whether to execute a custom acknowledgment script.

Filename





l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


State





This field is displayed if you enabled a collect list in target transfer properties.


l For each source in the list – Executes the script only for each source in the list.

l Both – Executes the script both for the main request and for each source in the list.

Target error scriptsA target error script is executed if an error occurs when a file is received.






Fields Script

Indicate whether to execute the default or a custom error script. The default script is defined in the configuration of the target Transfer CFT in the flow.

File

Filename

If you select Custom and select to use an existing file, specify the custom script to run. If the file does not exist, no processing is performed even if a default error script is defined in the Transfer CFT configuration, and an error is raised.


l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file



28 Transfer CFT legacy flows

Legacy flows for Transfer CFTs are a feature for enabling long-time users of Transfer CFT to transition flow management to Central Governance. Legacy flows address the following use cases:

l Flows can be managed in Central Governance for individual Transfer CFTs. In the Central Governance user interface, users can manage partners and send and receive templates for a specific Transfer CFT.

l Users can employ an established procedure to migrate Transfer CFT flow definitions to the Central Governance flow-management process.

Central Governance validates the uniqueness of legacy flow objects against Central Governance flows when Central Governance flows are deployed. Objects must be unique across all types of flows.

Legacy flows are added to the Central Governance user interface when Transfer CFTs register with Central Governance. However, Central Governance does not support some values in legacy flows. If Central Governance cannot map some legacy flow values to available values in legacy flows objects, the values are replaced with default values.

In Central Governance, the objects available in the legacy flows user interface are not part of the flows user interface.

Corresponding Transfer CFT objectsThe following table describes how legacy flows in Central Governance correspond to objects in Transfer CFT.

Central Governance object

Transfer CFT object

Description

Partner CFTPART, CFTTCP

A transfer partner.

Distribution list CFTDEST A pseudo-partner referencing a list of partners for performing broadcasting and collecting in a single command.

Send template CFTSEND Specifies default values for sending data.

Receive template

CFTRECV Specifies default values for receiving data.



Flow migration exampleIn the following example of migrating a legacy flow to a flow in Central Governance, there are two Transfer CFTs, identified as CFT-1 and CFT-2. Both begin as version 2.7.1 and are not registered in Central Governance.

1. CFT-1 and CFT-2 are upgraded to Transfer CFT 3.1.3.

2. CFT-1 and CFT-2 are registered in Central Governance.

3. The following legacy flows are in Central Governance for each Transfer CFT:

l CFT-1:

o Send template: FL001

o Partner: CFT-2

l CFT-2:

o Receive template: FL001

o Partner: CFT-1

4. In Central Governance the user adds a flow with the identifier FL001. The user selects CFT-1 as the source and CFT-2 as the target. The user defines the flow properties and protocol.

5. When the user deploys FL001 Central Governance determines that:

l FL001 already is defined on CFT-1 and CFT-2.

l Partners CFT-2 and CFT-1 exist on the Transfer CFTs involved in the flow.

6. Central Governance prompts the user to confirm whether to update the flow on the Transfer CFTs. If the user confirms the FL001 deployment, the send and receive templates for CFT-1 and CFT-2 are no longer available in the legacy flows user interface in Central Governance.

Legacy flow partner objects can conflict with the flow configuration if any of the legacy flow fields have the same value as the corresponding flow field.

Central Governance legacy flow field

Central Governance flow field

CFTUTIL parameter

Name Transfer CFT name CFTPART.IDCFTTCP.ID

Partner Access – Remote partner name Transfer CFT name CFTPART.NRPART

Partner objects CFTPART and CFTTCP are updated with the information defined in the flow. Alternatively, you can choose to keep the values from the legacy flow partner object by setting the property migrate.legacy.part.to.flows=true in the com.axway.cmp.cgcft-


default.cfg configuration file at <install directory>/runtime/com.axway.nodes.ume.<UUID1>/conf. All parameters except those in the following table keep the value from the legacy flow object.

Central Governance legacy flow field

Central Governance field which replaces the legacy flow value

CFTUTIL parameter

Partner Access – Host

Host of the partner Transfer CFT. CFTTCP.HOST

Protocol – Protocol Protocol name defined on the current Transfer CFT for the flow protocol options: network protocol/security.

CFTPART.CFTPROT ID

Protocol – Port in Port defined in the partner Transfer CFT for the flow protocol options: network protocol/security.

CFTPART.SAP

Migration of flows is completed when there are no more legacy flows objects defined on the Transfer CFTs in Central Governance.

Legacy flows lifecycleThe changing statuses in the lifecycle of legacy flows are displayed for Transfer CFTs in the user interface. The statuses are described in the following tables.

Global statusesThe following global statuses are displayed at the top of the Legacy Flows page for each Transfer CFT.

The global status is for all legacy flows for a specific Transfer CFT. Legacy flows are comprised of objects that include send and receive templates, partners and distribution lists.

If at least one object has a status of The displayed global status is

Saved, not deployed Saved, not deployed

Deploying Deploying

Deployed with errors Deployed with errors

If at least one object has a status of The displayed global status is

Removing Removing

Removed with errors Removed with errors

If no legacy flow objects meet these conditions, the displayed global status is Deployed.

Object statusesThe following are the statuses for each object in a legacy flow. The objects are send and receive templates, partners and distribution lists.

Status Status messages Description

Saved not deployed

Saved at <time> today, not deployedSaved on <date>, not deployed

An object has been added or changed, but has not been deployed.

Deploying Deploying since <time> todayDeploying since <date>

An object is being deployed.

Deployed with errors

Deployed at <time> todayDeployed on <date>

An object has been deployed, but errors occurred.

Deployed Deployed at <time> todayDeployed on <date>

An object has been deployed successfully.

Removing Removing since <time> todayRemoving since <date>

An object is being removed from Central Governance and Transfer CFT.

Removed with errors

Removed at <time> todayRemoved on <date>

An object has been removed, but errors occurred.

Deploy and remove actionsThe following table indicates when the status of a legacy flow object enables you to perform deploy and remove actions.


Status Deploy Remove

Saved not deployed Yes Yes

Deploying No No

Deployed with errors Yes Yes

Deployed Yes, but only after you change the object Yes

Removing No No

Removed with errors No Yes

Manage templatesUse the following procedures to manage send and receive templates. This includes listing, adding, viewing, deploying and removing templates.

Note You can define templates on Transfer CFT directly or by defining flows in Central Governance.

List templatesThe following are the steps to navigate to send or receive templates on the Transfer CFT Legacy Flows page for a selected Transfer CFT.

1. Click Products on the top toolbar to open the Product List page.

2. Find the Transfer CFT you want and click its name to open its details page.

3. Click Legacy flows to open the Transfer CFT Legacy Flows page for the selected Transfer CFT.

4. Select Send templates or Receive templates to list the names, statuses, file names and descriptions of the templates for the Transfer CFT.

Add templateThe starting point for the following steps is when send or receive templates for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click Add send template or Add receive template to open the add template page for the selected Transfer CFT.

2. Complete the fields. See Send template fields on page 462 or Receive template fields on page 474 for information.

3. Click Save send template or Save receive template to add the template.



Deploy templateThe starting point for the following steps is when send or receive templates for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Select a template with a status of Saved, not deployed.

2. Click Deploy to deploy the template to the Transfer CFT.

View, edit templateThe starting point for the following steps is when send or receive templates for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click the name of a template to open its details page.

2. Click Edit to change the template. See Send template fields on page 462 or Receive template fields on page 474 for information.

3. Click Save changes to save changes to the template.

Remove templateThe starting point for the following steps is when send or receive templates for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

Do one of the following to remove a template from the selected Transfer CFT:

l Select a template and click Remove.

l Click the name of a template to open its details page. Click Remove.

If the template you remove is deployed on Transfer CFT, the template also is removed from it.

Send template fieldsThe following are the fields to use when adding or editing a send template for Transfer CFT in the Central Governance user interface. See Manage templates on page 461 for actions you can perform.

A send template defines:

l The name and local physical characteristics of the file to send.

l The network characteristics of the file to send to a partner.

l The actions to perform locally during and after a transfer. For example, translation, compression, call to a user exit, an end-of-transfer procedure, and so on.

l A default user associated with the transfers




Name

The template name. The name must be unique across all CFTSEND objects defined on the Transfer CFT.

There cannot be a Central Governance flow with the same identifier that uses the Transfer CFT as a source.

Initiator

The party that initiates the transfer.

l Source - Source system initiates the transfer.

l Target - Target system makes a request to initiate the transfer.

Description

A description of the template

Transfer propertiesTransfer priority





Transfer state





User ID






l &PART

l &IDF

l &DIRECT

l &MODE

l &SAPPL , &RAPPL

l &IDA

l &SUSER , &RUSER

l &FNAME, &NFNAME


l &PARM



Compress file




Specify what happens if files are modified during the transfer.

l Continue transfer - Modified file is transferred.

l Stop transfer - Transfer status is changed to Kept.


Specifies what happens to the file when the transfer has completed.

l Delete - Deletes the file.

l Delete file content - Removes the contents of the file but leaves the end-of-file mark at the beginning of the file.

l None - No action is performed on the file.


Indicates the transfer states of files that will be deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the



associated transfers are removed from the transfer list.








Use this field for any information you want to provide. For example, you can use this field to propagate some business identifiers or values from the source to the target at the protocol level (without having to open the files). Note that in this use case, the attribute must be populated dynamically at runtime for each file transfer.

File properties > filenameFiles

Indicates whether a single file or multiple files are being sent.

Filename

Specify the path to the file or to the directory where the files to be transferred are located.

If you selected Single, the value you enter must represent a single file.




l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF, &IDTU


l &NFNAME, &NFVER


If you selected Multiple, the value you enter can be:

l A directory name – All the files in this directory will be transferred.

l A generic file name, including wildcard characters – Only files that match are transferred. For example, mydirectory/toto*.



The maximum length of this field is 64 characters. Enclose the value in quotes to preserve case sensitivity.

This field is required if the target is the initiator of the flow.

File list

This field is displayed if you selected Multiple as the Files option.

Specify the name of the file that contains the list of files to be transferred. This file is also referred to as an indirection file. It must contain one file name per record, and that name must start in the first column of the file. The file names contained in the file must not contain an asterisk (*).

Archive name

Name of the file that contains the set of files to be transmitted. Archive files are sent between systems that have the same operating system (grouped mode). The archive file is created automatically by Transfer CFT at the time of the transfer. The file created is a ZIP file on Windows systems and a TAR file on Linux and UNIX systems. Because Windows systems do not have default compression utilities, Transfer CFT for Windows includes zip and unzip utilities.




l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA




File name sent

Specify the name of the physical file that is to be used during transmission over the network.

If the file name is preceded by an asterisk (*), the target can keep the transmitted name or rename the file. The file name can include the following symbolic variables:



l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF





The file is transferred providing the following conditions are met:

l The target authorizes the source (requester or server) to set the physical name of the file to be received as defined in the Path field.

l The file name specified in this field exists or can be created at the target.

File properties > file encodingThe file encoding fields vary depending on the Transfer CFT operating system.

Windows and LinuxFile type

Specifies whether the file is a binary or text file.

Select Binary to send a mix of file types and ensure there is no custom encoding or transcoding required for the text files. If the text files have custom encoding or transcoding requirements, you must define specific flows for them.

Text file typeThe following fields are displayed for the text file type.




This field is displayed only if you selected CRLF as the end of record character and if the source Transfer CFT is on a Windows system.



Encoding



Transcoding






Stream text file typeThe following fields are displayed for the stream text file type.

Encoding


Transcoding


OS/400 (IBM i)File type






Encoding

Represents how the data is stored/encoded upon reception.


Transcoding

Represents how the data in the file is decoded on reception (how the data is received from the network)..

If you select Custom, the Transcoding charset field is displayed where you can enter the character set.


z/OSFile type















l Text


Encoding



Transcoding




File properties > record formatRecord type


Padding character




Trimming character







Processing scriptsThe source processing scripts section of the flow definition identify the scripts to execute at specific phases in the flow lifecycle. See Flow lifecycle on page 298 for detailed information.

For each phase, you can select whether to execute the default script or a custom script. Default scripts, with the exception of pre-processing scripts, are defined in the configuration of the Transfer CFT involved in the flow. For example, SalesApp1 running on CFT001 is defined as the source in the flow. The default post-processing script defined in the CFT001 configuration is exec/default_postprocessing.sh (the actual default value is exec/&IDF.sh). If that is the script you want executed in the flow, you select the Default option.


Processing scripts are executed on the source during the following phases:

l Pre-processing – Before the file is transferred

l Post-processing – After the file is transferred

l Acknowledgment – After an acknowledgment is sent by the target

l Error – After an error occurs during a transfer


l Set an existing script already on the source Transfer CFT.

or




Pre-processingScript

Indicates whether to execute a pre-processing script. There are no default pre-processing scripts.

File


Filename

If you select Custom and select to use an existing file, specify the script to run. This name can include the following symbolic variables:

l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


State

Indicates the status of the transfer on the source. The script is run only if the transfer is in the specified state.


l On hold - Transfer is deferred until a remote receive request is accepted, or until a local START command changes this transfer to the ready state.

Post-processingScript

Indicate whether to execute the default or a custom post-processing script. The default script is defined in the configuration of the source Transfer CFT in the flow.

File




Filename



l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file








AcknowledgmentScript

Indicates whether to execute the default or a custom acknowledgment script. The default script is defined in the configuration of the source Transfer CFT in the flow.



Filename



l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


State












ErrorScript

Indicates whether to execute the default or a custom error script. The default script is defined in the configuration of the source Transfer CFT in the flow, and an error is raised..

File


Filename

If you select Custom and select to use an existing file, specifies the custom script to run. If the file does not exist, the default error script defined in the Transfer CFT configuration is executed.


l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


Receive template fieldsThe following are the fields to use when adding or editing a receive template for Transfer CFT in the Central Governance user interface. See Manage templates on page 461 for actions you can perform.

A receive template defines:

l The default name and local physical characteristics of the file to receive.

l The default actions to perform locally during and after the transfer. For example, translation, compression, call to a user exit, an end-of-transfer procedure, and so on.

l The default time slot and default user associated with the transfers.




Name

The template name. The name must be unique across all CFTRECV objects defined on the Transfer CFT.

There cannot be a Central Governance flow with the same identifier that uses the Transfer CFT as a target.

Description

A description of the template.

Transfer propertiesTransfer priority





Transfer state





User ID




l &PART

l &IDF

l &DIRECT



l &MODE

l &SAPPL , &RAPPL

l &IDA

l &SUSER , &RUSER

l &FNAME, &NFNAME


l &PARM



Compress file



No file exists

Specifies the action taken if the received file does not already exist.

l Create – File is created.


Invalid options are disabled. Note that you cannot select Cancel in this field and in the File exists field. If that was possible, all transfers would fail.

File exists

Specifies the action taken if the received file exists.

l Delete – Existing file is deleted.


l Overwrite – Existing file is overwritten.

l Overwrite only if empty – Existing file is overwritten only if it has no data.

l Retry renaming after receiving temporary file - After receiving the temporary file, multiple attempts are made to rename the temporary file with the file name.

Invalid options are disabled. You cannot select Cancel in this field and in the No file exists field. If that were possible, all transfers would fail.

Aborted transfer

Specifies the action taken if a transfer is terminated due to a file creation error on the target.



l Keep – Transfer remains in the transfer list.

l Delete – Transfer is removed from the transfer list.









File propertiesFilename

Specify the file name or full path name for the received file or files. This field is required if the initiator of the flow is the source. Default value: pub\&IDF.&IDTU.&FROOT.RCV



l &SPART, &RPART, &PART, &IPART, &NPART, &GROUP

l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA

l &NIDF, &IDTU, &IDT


l &NFNAME

l &NFVER


Temporary file

Specify the name of the temporary file used during the transfer. When the transfer is complete, the temporary file is renamed using the name defined in the Filename field. If you do not specify a value, Transfer CFT creates the file with the name specified in the Filename field. If the File exists parameter is set to Overwrite after receiving temporary file, Temporary file becomes required.






l &SUSER, &RUSER

l &SAPPL, &RAPPL

l &IDF, &PARM, &IDA




File properties > file encodingThe file encoding fields vary depending on the Transfer CFT operating system.

Windows and LinuxFile type

Specify whether the file is a text or binary file, or opt to use autodetect.

Text file typeThe following fields are displayed for the text file type only.




This field is displayed only if you selected CRLF as the end-of-record character and if one of the source Transfer CFTs is on Windows.



Encoding





Transcoding




Stream text file typeThe following field is displayed for the stream text file type.

Encoding


OS/400 (IBM i)File type






Encoding



Transcoding

Represents how the data in the file is decoded on reception (how the data is received from the network)..



z/OSFile type












l PDSE specifies the file is a PDSE file.




l Text


Encoding



Transcoding




File properties > record formatRecord type




Padding character


Trimming character







Processing scriptsThe target processing scripts section of the flow definition identify the files to execute at specific phases in the flow lifecycle. See Flow lifecycle on page 298 for detailed information.

For each phase, you can select whether to execute the default script or a custom script. Default scripts are defined in the configuration of the Transfer CFT involved in the flow. For example, ProdCat1 running on CFT100 is defined as the target in the flow. The default post-processing script defined in the CFT100 configuration is exec/default_postprocessing.sh (the actual default value is exec/&IDF.sh). If that is the script you want executed in the flow, you select the Default option.


Processing scripts are executed on the target during the following phases:

l Post-processing – Executed after the file was received

l Acknowledgment – Executed after the file is transferred

l Error – Executed if an error occurs when a file is received


l Set an existing script already on the target Transfer CFT.

or




Post-processingScript

Indicate whether to execute the default or a custom post-processing script. The default script is defined in the configuration of the target Transfer CFT in the flow.

File


Filename



l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


AcknowledgmentScript

Indicate whether to execute a custom acknowledgment script.

Filename





l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF


Choose file


State




ErrorScript

Indicate whether to execute the default or a custom error script. The default script is defined in the configuration of the target Transfer CFT in the flow.

File

Filename

If you select Custom and select to use an existing file, specify the custom script to run. If the file does not exist, no processing is performed even if a default error script is defined in the Transfer CFT configuration, and an error is raised.


l &IDF, &PARM



l &RAPPL, &SAPPL

l &NIDF




Choose file


Manage partnersUse the following procedures to manage partners. This includes listing, viewing, adding, editing, deploying and removing partners.

List partnersThe following are the steps to navigate to partners on the Transfer CFT Legacy Flows page for a selected Transfer CFT.




4. Select Partners to list the names, statuses and descriptions of the partners for the Transfer CFT.

Add partnerThe starting point for the following steps is when partners for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click Add partner to open the Add Partner page for the selected Transfer CFT.

2. Complete the fields. See Partner fields on page 485 for information.


Deploy partnerThe starting point for the following steps is when partners for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Select a partner with a status of Saved, not deployed.

2. Click Deploy to deploy the partner to the Transfer CFT.



View, edit partnerThe starting point for the following steps is when partners for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click the name of a partner to open its details page.

2. Click Edit to change the partner. See Partner fields on page 485 for information.

3. Click Save to save changes to the partner.

Remove partnerThe starting point for the following steps is when partners for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

Do one of the following to remove a partner from the selected Transfer CFT:

l Select a partner and click Remove.

l Click the name of a partner to open its details page. Click Remove.

If the partner you remove is deployed on Transfer CFT, the partner also is removed from it.

Partner fieldsThis topic describes the fields when adding or editing a partner1 in legacy flows. See Manage partners on page 484 for actions you can perform.

The user interface specifies default values for fields with them. You can change default values as needed.

Note Partners and distribution lists can be defined directly on Transfer CFT or on Central Governance via flows.

Name

The partner identifier. The name must be unique for all partners and distribution lists defined on Transfer CFT.

Description

Optionally, a description of the partner.

1In Transfer CFT a partner is a logical entity such as a bank, a government agency or trading partner, that can be the sender or receiver of data. A partner corresponds to a remote file-transfer controller.



Partner accessRelay

Local identifier of a relay partner.

Local partner name

Identifier Transfer CFT uses to identify itself to a partner.

The partner name must be unique across all partners and broadcast and collect lists on Transfer CFT.

There cannot be a Central Governance flow with the same broadcast list name that uses the instance of Transfer CFT as the source.

There cannot be a Central Governance flow with the same collect list name that uses the instance of Transfer CFT as the target.

Local partner passwordConfirm local partner password

Password Transfer CFT uses to identify itself to a partner.

Remote partner name

Identifier of the remote partner Transfer CFT. If you do not enter a value, the remote partner name defaults to the partner name entered previously.

The remote partner name must be unique among all nrpart partner values for the instance of Transfer CFT.

Remote partner passwordConfirm remote partner password

Password of the remote partner Transfer CFT.

Host

Host of the remote partner Transfer CFT. See Operating systems and deployment correspondence on page 597.

Operating system

Operating system of the remote partner Transfer CFT.

ProtocolSecurity profile

Local security profile used for transfers with the remote partner.



Protocol

Local protocol used for transfers with the remote partner.

Port

Port of the remote partner Transfer CFT.

Network sessionsThe following fields are for customizing sessions allocated to the partner. A value must be set in the Host field to enable editing these fields. The value of each field is independent of the other fields.

Incoming connections

Maximum number of sessions for inbound connections (server mode).

Outgoing connections

Maximum number of sessions for outbound connections (requester mode).

Total connections

Maximum number of communication sessions for the partner.

Manage distribution listsUse the following procedures to manage distribution lists. This includes viewing, adding, editing, deploying and removing lists.


List distribution listsThe following are the steps to navigate to distribution lists on the Transfer CFT Legacy Flows page for a selected Transfer CFT.




4. Select Distribution lists to list the names, statuses and descriptions of the distribution lists for the Transfer CFT.



Add distribution listThe starting point for the following steps is when distribution lists for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click Add distribution list to open the Add Distribution List page for the selected Transfer CFT.

2. Complete the fields. See Distribution list fields on page 489 for information.


4. Optionally, click Deploy to deploy the list to the Transfer CFT. You can skip this step and deploy the list later if you prefer.

Deploy distribution listThe starting point for the following steps is when distribution lists for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Select a distribution list with a status of Saved, not deployed.

2. Click Deploy to deploy the list to the Transfer CFT.

View, edit distribution listThe starting point for the following steps is when distribution lists for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

1. Click the name of a distribution list to open its details page. If the list has not been deployed, you can click Deploy to do so.

2. Click Edit to change the distribution list. See Distribution list fields on page 489 for information.

3. Click Save to save changes to the distribution list.

4. Optionally, click Deploy to deploy the list to the Transfer CFT. You can skip this step and deploy the list later if you prefer.

Remove distribution listThe starting point for the following steps is when distribution lists for a selected Transfer CFT are displayed on the Transfer CFT Legacy Flows page.

Do one of the following to remove a distribution list from the selected Transfer CFT:

l Select a distribution list and click Remove.

l Click the name of a distribution list to open its details page. Click Remove.



If the removed list had been deployed on Transfer CFT, the list also is removed from the Transfer CFT.

Distribution list fieldsThis topic describes the fields when adding or editing a distribution list1 in legacy flows. See Manage distribution lists on page 487 for actions you can perform.


Name

The distribution list identifier. The name must be unique for all partners and distribution, broadcast and collect lists defined on the Transfer CFT.

There cannot be a Central Governance flow that uses the Transfer CFT as a source and has a broadcast list with same name.

There cannot be a Central Governance flow that uses the Transfer CFT as a target and has a collect list with same name.

Type

Defines the partner list as one of the following:

l Partner list - Explicitly using a list type parameter.

l File - Using a file in which the list of partners is saved.

These methods are mutually exclusive. A partner included in a list cannot itself be a broadcasting list.

If you select file as the type, you can do one of the following:

l Use existing file - Specify a file already on the Transfer CFT.

l Upload new file - The new file is available on Transfer CFT after the distribution list is deployed successfully on it. The new file is uploaded to Transfer CFT with the default path $(cft.runtime_dir)/conf/ws_upload. The file is overwritten if it already exists on Transfer CFT.

Unknown partner

Specifies the action to take when a target in the distribution list is not found.

l Continue – Display an informational message and continue processing.

l Ignore – Continue processing without an informational message.

1In Transfer CFT, a distribution list manages the list of partners for distribution and collection operations. Use of a distribution list enables, with a single command, sending or receiving a file to all targets or sources in the list.



l Cancel – The transfer stops at the first error, but all transfers started before the error occurred continue. For example, if there are 10 targets in the list and the fourth one is unknown, targets 1-3 receive the file, but targets 4-10 do not.

Processing scripts submissionApply pre-processingApply post-processingApply acknowledgment scripts

These fields specify when to apply processing scripts.


l For each partner in the list – Executes the script only for each partner in the list.

l Both – Executes the script both for the main request and for each partner in the list.


29 Environment promotion and staging

This documentation provides guidelines and examples for environment promotion and staging in Central Governance, with a focus on flows.

Environment promotion and staging relies on the import and export commands of CLI1. Before reading this documentation, see Command line interface on page 88 and review the following commands:

l appExport

l appImport

l partnerExport

l partnerImport

l flowExport

l flowImport

l flowDeploy

GuidelinesWhile reviewing the following promotion and staging guidelines, keep in mind that Central Governance does not have environment awareness and that an instance of a product can register with only one instance of Central Governance.

These guidelines provide the ideal deployment pattern for staging. Applying them assures the simplest possible promotion without the need for external tooling or manual actions to adapt the export files. Some of these guidelines might not apply to you, because of your existing product infrastructure or the nature of your business. For example, typically, a retailer cannot have as many stores in testing as in production.

l Install one instance of Central Governance per environment. For example, if you have development, testing, pre-production and production environments, you need four instances of Central Governance.

l The same applies for registered products. If you have four instances of Central Governance, install and register one instance of a product per Central Governance environment. Do not register the same instance of a product in multiple Central Governance environments.




l Have one-to-one mapping in the number and names of applications between environments. For instance, the General Ledger application should have the same name in all environments, but all other details, including the host name, can differ from one environment to another.

l If, in the case of Transfer CFTs, application groups are used in flows, typically in a corporate-to-store pattern, have one-to-one mapping in the number and names of application groups between environments. For instance, the group containing all stores should have the same name in all environments, but all other details can differ from one environment to another.

l Have one-to-one mapping in the number, names and identifiers of flows between environments.

l Have one-to-one mapping in the number and names of partners between environments. For instance, your food supplier should have the same name in all environments, but all other details, such as communication profiles, can differ from one environment to another.

l It is strongly recommended to:

o Use the same communication profile aliases between environments and ensure that communication profile properties are compatible.

o Use the same credential aliases for certificates and SSH keys.

o Use the same PGP keys aliases used by SecureTransport processing steps.

Having one-to-one mapping in the number and names of products between environments is not required or recommended. The only recommendation relates to when relays are used. In such cases, having the same name across environments is strongly recommended.

Flow promotion use casesAll of the following use cases presume product parameters within a flow are identical in the source and the target environments. If not, the flow should be edited manually in the target Central Governance after import or the export file should be adapted outside of Central Governance, manually or via automated tooling.

Application to applicationSample flows:

l Application 1 (Transfer CFT 1) > Application 2 (Transfer CFT 2)

l Application 1 (Transfer CFT 1) > Application Group 1

l Application 2 (Transfer CFT 2), Application 3 (Transfer CFT 3) > Application 1 (Transfer CFT 1)

New flow: Same application and Transfer CFT namesAssuming applications and Transfer CFTs exist and have the same names in both Central Governance instances, but the flow doesn’t exist in the target Central Governance.

l Export the flow from the source Central Governance with the following command:


flowExport –n <flow name>

l Import the flow in the target Central Governance with the following command:

flowImport –f <file name>

The flow is imported, but not deployed, in the target Central Governance.

The same logic applies if promoting multiple flows at once. In such case provide the list of flow names, separated by commas, or provide a name pattern matching the flows to export. This comment also applies to all of the following use cases.

Existing flow: Same application and Transfer CFT namesAssuming the flow exists in the target Central Governance, the only difference from the preceding case is to overwrite the flow upon import.




flowImport –f <file name> -o


New flow: Same application names, different Transfer CFT namesAssuming applications and Transfer CFTs exist in both Central Governance instances, but the Transfer CFTs have different names, and the flow doesn’t exist in the target Central Governance.




flowImport –f <file name> -ai.

Without the –ai (--allowincomplete) option, the flow cannot be imported correctly because its definition points to an instance of Transfer CFT that does not exist in the target Central Governance. With this option, the target Central Governance ignores the Transfer CFTs referenced in the file and instead includes in the flow the Transfer CFTs linked to the applications already defined in the target Central Governance.

Existing flow: Same application names, different Transfer CFT namesAssuming the flow exists in the target Central Governance, the only difference from the preceding case is to overwrite the flow upon import.




flowImport –f <file name> -ai -o


Different number of applications and Transfer CFTs Both of the following cases assume the number of applications and Transfer CFTs in the flow are different in the source and target environments. The typical use case is corporate-to-store, with many stores in the production environment and few stores in other environments. Best practice in is to rely on application groups in flows.

New flowAssuming the application groups exist in both Central Governance instances and the flow doesn’t exist in the target Central Governance.





Thanks to the abstraction layer provided by the application groups, it doesn't matter that the application groups differ in number or names in the source and target instances. The imported flow points to the existing application groups in the target Central Governance.


Existing flowAssuming the flow exists in the target Central Governance, the only difference from the preceding case is to overwrite the flow upon import.

Application to application with relaysSample flow:

l Application 1( Transfer CFT 1) > Transfer CFT relay >Application 2 (Transfer CFT 2)

For applications, use the cases in Application to application on page 492.

Relays are linked correctly if relay names match existing Transfer CFTs. You need to use the –ai (--allowincomplete) option if you have a different Transfer CFT relay names or a different number of relays or both.

Application to business and business to applicationSample flows:

l Application (SecureTransport) > Partner 1

l Partner 1 > Application (SecureTransport)

Note An application with SecureTransport in an application group is not a supported use case.

PartnersWhen imported flows have partners that exist in the target environment, the flows are relinked to the partners based on the partner names. Partners in the source and target environments should have the same names and the same or compatible server communication profiles (see Prerequisites for promoting flows on page 498). Credentials can differ provided aliases are the same.

Best practice is using the same partner names between the environments. If partner names differ between environments, change SecureTransport configuration in imported flows to match the target partners. You must check and update receive, file processing and send properties.

One of the following cases applies when partners do not exist in the target environment. You must first import partners to the target environment because flow import does not support importing partners.

New partnersAssuming partners do not exist in the target environment.

l Export the partners from the source Central Governance with the following command:

partnerExport –n <partner names>

Or export all partners with:

partnerExport

l Import the partner in the target Central Governance with the following command:

partnerImport –f <filename>

The partners are imported in the target Central Governance

Existing partnersAssuming partners exist in the target Central Governance, the only difference from the preceding case is to overwrite the partner upon import.

l Export the partners from the source Central Governance with the following command:

partnerExport –n <partner names>


partnerImport –f <file name> -o

The partners are imported and updated in the target Central Governance.

ApplicationsThe following cases apply when application names are the same, but names of SecureTransports are the same or different.

New flow: Same application and SecureTransport namesAssuming applications and SecureTransport exist and have the same names in both Central Governance instances, but the flow doesn’t exist in the target Central Governance.






The same logic applies if promoting multiple flows at once. In this case provide the list of flow names, separated by commas, or provide a name pattern matching the flows to export. This comment also applies to all of the following use cases.

Existing flow: Same application and SecureTransport namesAssuming the flow exists in the target Central Governance, the only difference from the preceding case is to overwrite the flow upon import.

New flow: Same application names, different SecureTransport namesAssuming applications and SecureTransports exist in both Central Governance instances, but the SecureTransports have different names and the flow doesn’t exist in the target Central Governance.

l Export the Flow from the source Central Governance with the following command:



flowImport –f <file name> -ai.

Without the –ai (--allowincomplete) option, The flow cannot be imported correctly because its definition points to an instance of SecureTransport that does not exist in the target Central Governance. With this option, the target Central Governance ignores the SecureTransports referenced in the file and instead includes in the flow the SecureTransports linked to the applications already defined in the target Central Governance.


Existing flow: Same application names, different SecureTransport namesAssuming the flow exists in the target Central Governance, the only difference from the preceding case is to overwrite the flow upon import.




flowImport –f <file name> -ai -o


Application to business and business to application with SecureTransport relaySample flows:

l Application (Transfer CFT) > SecureTransport relay > Partner 1, Partner 2

l Partner 1, Partner 2 > SecureTransport relay > Application (Transfer CFT)

For partners see the use cases in Partners on page 495.

For applications see the use cases in Applications on page 496.

For relays you must use the same SecureTransport relay name.

Deploying promoted flowsYou can deploy promoted flows in the Central Governance user interface. However, the preferred method is via the command-line if there is a policy to avoid using the UI in a production environment. If so, the only remaining operation is to run the command:

flowDeploy –n <flow names>

Prerequisites for promoting flowsThere are prerequisites for exporting and importing flows when promoting flows from one Central Governance environment to another. Promotion is when, for example, you export flows from a development or staging environment and import them to a production environment. The promoted flows remain in the source environment unless you remove them after promoting to the target environment.

Review these topics before promoting flows using CLI1 or the user interface. For CLI see flowExport on page 95 and flowImport on page 95. For the UI see Back up flows from UI on page 373. As usual, users must have roles with proper privileges to run specific actions. See Permissions enforcement on page 90.

The import algorithmCentral Governance uses an algorithm that imports objects in the following sequence:

1. Application groups

2. Participants (all sources and targets in flows, including partners, applications, application groups, unmanaged products)

3. Credentials

4. Profiles

5. Flows

The first two steps are triggered when using parameters like importapplications or importunmanagedproducts with flowImport on page 95. If the parameters are not used, it is presumed participants already exist in Central Governance, and links to them are made as described in Conditions about participants on page 501 and Conditions about file-transfer middleware on page 501. If conditions are unmet, import fails unless the allowincomplete parameter is used. If allowincomplete is used, participants that do not exist are removed as flow sources, targets and relays and flow status is recalculated.

Next, import of credentials and profiles is attempted. Lastly, flows are imported. For profiles:


l Existing client communication profiles are checked for compatibility. Client communication profiles that do not exist are created if compatible.

l Existing server communication profiles are checked for compatibility. Importing stops if server communication profiles do not exist or are not compatible.

The compatibility checks Central Governance performs are described in the next topic.

Conditions about protocols and communication profilesCommunication profiles in exported flow files must be compatible with profiles in the instance of Central Governance that imports the flows. This applies to client and server communication profiles when, upon importing, Central Governance finds a client or server communication profile with the same name.

When a flow is imported, Central Governance creates client communication profiles when they do not exist in the target environment. Conversely, server communication profiles are never created upon importing flows; they are reused if they exist with the same name.

Central Governance checks for compatibility when it detects a communication profile in an imported flow with the same name of an existing profile. The type of communication profile (client or server) must match and the protocol must be the same. The profiles must have the same protocol details, as outlined in the following tables.

HTTP details

Property Property value



SSL/TLS None

Client optional

Server only


Enable SSL/TLS = No

Enable SSL/TLS = Yes ; Client authentication

required: Optional


required: No


required: Yes

Enable SSL/TLS = No

Enable SSL/TLS = Yes ; No certificate authentication or certificate

Enable SSL/TLS = Yes ; No certificate authentication

Enable SSL/TLS = Yes ; certificate

HTTP method

PUT

POST

GET

Must support PUT

Must support POST

Must support GET

PUT

POST

GET

FIPS YES

NO

YES

NO

YES

NO



PeSIT details




Network protocol

TCP

pTCP

UDT

TCP

pTCP

UDT

TCP

pTCP

UDT

SSL/TLS None

Client optional

Server only


Enable SSL/TLS = No


required: Optional


required: No


required: Yes

Enable SSL/TLS = No




FIPS YES

NO

YES

No

YES

NO

SFTP details

Property Property value Server communication profile



Public key

Password

Password or public key

Public key

Password


Public key

Password


FIPS YES

NO

YES

NO

YES

NO

FTP details




Connection mode

Active

Passive

Active or Both

Passive or Both

Active

Passive



FTP details




SSL/TLS None

Client optional

Server only


Enable SSL/TLS = No


required: Optional


required: No


required: Yes

Enable SSL/TLS = No




FIPS YES

NO

YES

NO

YES

NO

When a server communication profile for a partner, product or unmanaged product is used by a protocol in a flow, the profile, based on name, must exist in Central Governance. If not the flow import fails, except when the allowincomplete parameter is used, which results in the protocol becoming undefined in Central Governance.

Conditions about participantsParticipants in a flow to be imported must exist in the target environment. Participants are used as sources and targets in flows, including partners, applications and application groups. The following rules are enforced upon importing:

l An application exists in Central Governance if an application with the same name and host exists.

l An application group or partner exists in Central Governance if an application group or partner with the same name exists.

These conditions can be bypassed by using the allowincomplete option. In this case the participants are removed from the source or target of the flow, and the flow status is recalculated according to the new flow content.

Conditions about file-transfer middlewareFile-transfer middleware — products or unmanaged products used in flows as sources, relays or targets — must exist in the target environment when flows are imported. Central Governance enforces the following rules upon importing:



l A product exists in Central Governance if a product with the same name and same product type exists and if the product status indicates the product is registered successfully.

l An unmanaged product exists in Central Governance if an unmanaged product with the same name exists.

These conditions can be bypassed by using the allowincomplete option. In this case the file-transfer middleware is removed from the source, target or relay of the flow, and the flow status is recalculated according to the new flow content.

Summary of export and import actionsThe following table is a summary of export and import actions with CLI1. Note that FGAC2 is sometimes required. See Fine-grained access control on page 157 for more about FGAC.

Action Option used Required privilege

Comment

Export a flow

View Flow and FGAC

Export an application

View Application and FGAC

If the user exports a flow linked to an application and does not have the View Application privilege, or does not the right to view this application, the flow is exported with the reference to this application, but not its definition.

Export a group

View Group and FGAC

If the user exports a flow linked to a group and does not have the View Group privilege, or does not have the right to view this group, the flow is exported with the reference to this group, but not its definition.

Export an unmanaged product

View Unmanaged Product

If the user exports a flow linked to an unmanaged product and does not have the View Unmanaged Product privilege, the flow is exported with the reference to this unmanaged product, but not its definition.

1Command line interface (CLI) is a tool for performing actions on products and services.2Fine-grained access control (FGAC) is a way to manage users' access to objects or capacity to perform actions. For example, you could enable some users to view specific objects in the user interface, but prohibit other users from viewing the same objects.




Comment

Export a partner

View Partner

If the user exports a flow linked to a partner and does not have the View Partner privilege, the flow is exported with the reference to this partner, but not its definition.

Import a flow

Create and View Flow and FGAC and View {object}

If the user imports a flow linked to an object (application, group, partner, unmanaged product) on which the user has no rights, the flow is not imported.

Import a flow

allowincomplete Create and View Flow and FGAC

If the user imports a flow linked to an object on which the user has no rights, the flow is imported, but without this object, and the flow is incomplete.

Import an application

importapplications Create and View Application and FGAC

If the user tries to import a flow containing an application on which the user has no rights, both the flow and the application are not imported.

Import an application

allowincomplete Create and View Application and FGAC

If the user tries to import a flow containing an application on which the user has no rights:

- The flow is imported but without the application (due to the allowincomplete option).

- The application is not imported.

Import a partner

importpartners Create and View Partner

If the user tries to import a flow containing a partner but does not have the create permission, both the flow and the partner are not imported.




Comment

Import a partner

allowincomplete Create and View Partner

If the user tries to import a flow containing a partner but does not have the create permission:

- The flow is imported but without the partner (due to the allowincomplete option)

- The partner is not imported

Import a group

importapplications Create and View Group and FGAC

If the user tries to import a flow containing a group on which the user has no rights, both the flow and the group are not imported.

Import a group

allowincomplete Create and View Group and FGAC

If the user tries to import a flow containing a group on which he has no right: - the flow is imported but without the group (due to the allowincomplete option) - the group is NOT imported

Import an unmanaged product

importunmanagedproducts Create and View Unmanaged Product

If the user tries to import a flow containing an unmanaged product but does not have the create permission, both the flow and the unmanaged product are not imported.

Import an unmanaged product

allowincomplete Create and View Unmanaged Product

If the user tries to import a flow containing an unmanaged product but does not have the create permission:

- The flow is imported but without the unmanaged product (due to the allowincomplete option).

- The unmanaged product is not imported.

Overwrite an existing flow

overwrite Modify and View Flow and FGAC


30 Alert rules

An alert is an event that occurs in Central Governance, such as a registration failure for a product. An alert rule can be triggered when the alert event matches the conditions in the alert rule. All alert rules send email notifications to the recipients defined in the rule.

An alert rule consists of conditions and notification sections:

l Conditions section defines the conditions for triggering the alert rule.

l Notification section contains the message to be sent to the specified recipients.

See Edit alert rule messages, recipients on page 509 for more information about conditions and notifications.

You can make copies of predefined alert rules and change conditions and notification information.

Note Although you can edit predefined alert rules, best practice is to make copies of predefined rules and change the copies. Copies of predefined rules are recognized as user-defined rules. If you change predefined rules and later install an upgrade for Central Governance, the rules revert to their default configurations. However, your user-defined rules are unaffected when you apply an upgrade.

Central Governance provides the following predefined alert rules.

Flow errorA flow error alert is triggered when errors occur during the execution of a flow. The alert message contains the following information:

l Flow name

l Reason for the failure, which includes a return code and message

l Source application

l Target application

l Source product

l Target product

l File name

l A link to view transfer details


30 Alert rules

Product configuration deployment errorTriggered when a configuration deployment fails on a product. The alert message contains the following information:

l Name of the product and product type

l Name of the host where the product is installed

l Date and time of the deployment

l Reason for the failure

l A link to view configuration details

Flow deployment errorTriggered when a flow deployment fails on a product. The alert message contains the following information:

l Name of affected flow



l Date and time of the deployment


l A link to view flow details

Product failureTriggered when a product is not running. The alert message contains the following information:


l Name of the host where product is installed

l Status of the product


l A link to view the product details

Product registration errorTriggered when a product fails to register successfully. The alert message contains the following information:


30 Alert rules



l Status of the product, which is always "registered in error."


l A link to view the product details

Certificate expiration Triggered when a certificate is about to expire, as set in the initial configuration. The alert is triggered again every n days divided by 2, for example if the initial configuration is 30 days, then 15 days prior to expiration another email is sent, then 7 days, and so on until expiration is reached or the certificate is replaced. An alert message is sent for each individual certificate that is due to expire and contains the following information:

l Certificate alias

l Number of days until expiration

l Component type and component instance

Use Alert Rule List pageClick Alert Rules on the top toolbar to open the Alert Rule List page. Use the page to perform the following actions.

Sort rulesClick a column heading to sort rules by name, subscription, status or source in ascending or descending order.

Filter rulesUse the Filter Add drop-down list to filter the list of displayed rules by name, subscription, status, source or description.

Activate or deactivate a ruleSelect one or more alert rules and click Activate or Deactivate. All rules are inactive by default.

Activating and deactivating also are available options when you click the name of a rule to open its details page.

See Why deactivate an alert rule on page 509.


30 Alert rules

Subscribe or unsubscribe to a ruleThis adds or removes your email address to the list of recipients of alert messages. Your user account must include your email address to subscribe.

l To subscribe, select one or more alert rules and click Subscribe. An envelope icon is displayed next to the alert rule name to indicate you are subscribed. A user with the proper privilege can verify by clicking the alert rule name and checking for the email address in the To field under the Notification section.

l To unsubscribe, select one or more subscribed rules and click Unsubscribe. The envelope icon disappears and your email address is removed from the To field under the Notification section.

Users with the default IT Manager and Middleware Manager roles can subscribe and unsubscribe. Both roles let users view or edit the list of email recipients for an alert.

Subscribing and unsubscribing also are available options when you click the name of a rule to open its details page.

Copy a ruleSelect one or more rules and click Copy to duplicate the rule or rules. The names of copied rules are appended with Copy [n] to indicate they are copies of the original. For example, Flow error - Copy 1.

You can make a copy of a copy. The name of such a copy is appended with Copy [n] - Copy [n].

A copied rule is identified on the Alert Rule List page as user defined under the Source column. A copied rule is inactive by default. You can edit a user defined rule just as you can a predefined rule. See Edit alert rule messages, recipients on page 509 for more information.

Copying a rule also is an available option when you click the name of a rule to open its details page.

Edit a ruleClick the name of a rule to open its details page and then click Edit. See Edit alert rule messages, recipients on page 509 for more information.

Remove a ruleYou can remove only copies of alert rules, which are identified as user-defined rules. You cannot remove original rules, which are identified as predefined rules.

Select one or more copies of a rule, click Remove and click the Remove option in the confirmation window.


30 Alert rules

Removing a copy of a rule also is an available option when you click the name of a rule to open its details page.

Why deactivate an alert ruleThe following explains why you might want to deactivate a rule.

As the IT Manager, you have scheduled network maintenance on Saturday and know Central Governance and a product will have communication problems for about one hour. If the product failure alert rule remains active during the maintenance period, you will receive many meaningless notifications. To avoid this, deactivate the rule before starting the maintenance. Reactivate it after maintenance is completed. If you remove the rule instead of deactivating it, you would have to reconfigure it entirely.

If Central Governance detects an alert while the rule is disabled, no email notifications are sent. When you reactivate the rule, email notifications are sent only for the alerts detected after the rule is reactivated.

You can activate and deactivate alert rules on the Alert Rule List page or when viewing the details of a specific alert. See Use Alert Rule List page on page 507.

Edit alert rule messages, recipientsYou can view or edit the messages Central Governance sends to recipients of triggered alert rules and view or change lists of message recipients.

A recipient can be any person with an email address.

Note Although you can edit predefined alert rules, best practice is to make copies of predefined rules and change the copies. Copies of predefined rules are recognized as user-defined rules. If you change predefined rules and later install an upgrade for Central Governance, the rules revert to their default configurations. However, your user-defined rules are unaffected when you apply an upgrade.

Rule editing stepsThe following are the steps for editing an alert rule.

1. Click Alert Rules on the top toolbar to open the Alert Rule List page.

2. Click a rule name to open its details page.

3. Click Edit.

4. Enter the changes you want and click Save changes when done.

See:

l Conditions fields on page 510 for information about the Conditions section.

l Notification fields on page 511 for information about the Notifications section


30 Alert rules

Conditions fieldsThe following are the conditions for each default alert. Except for the Status condition of the product failure alert, all conditions are set to Any by default, but can be reset to specific single or multiple values.

Flow errorApplication name

Name of one or more applications, source or target.

File name

Name of one or more file names or a pattern using the asterisk (*) wildcard character.

Flow name

Name of one or more flows.

Product name

Name of one or more products.

Product configuration deployment errorProduct name


Product type

The types of products the rule applies to.

Flow deployment errorFlow name

Name of one or more flows.

Product name


Product type

The types of products the rule applies to.


30 Alert rules

Product failureProduct name


Product type

The type of products the rule applies to.

Status

One or more of the following statuses: stopping, stopped, unreachable, partially started, started in error, stopped in error, in progress.

Product registration errorThere are no conditions defined for this alert.

Certificate expirationCertificate alias

Defines the alias for the certificate affected by the alert. Any includes all certificate aliases. Alternatively, you can specify specific certificate aliases. Enter the value in the field, and use Add values to add additional aliases.

Component type

Select one or more of the following components that are impacted by the alert:

l Product server communication profile

l Product client communication profile

l Partner server communication profile

l Partner client communication profile

l Unmanaged product

Notification fieldsThe following describes the fields in the Notification section.

From

An email address for the message sender. The default value is an invalid no-reply address.


30 Alert rules

To

One or more recipient addresses. If multiple addresses, separate each address with a comma. For example:

[email protected],[email protected]

An alert message is sent to each address. The default is blank.

Subject

The subject line of the alert message. You can use values derived from the context of the rule itself. See Use context values in notifications on page 512.

Message

The alert message. A full-featured HTML editor is provided for composing the body of the notification email. You can use values derived from the context of the rule itself. See Use context values in notifications on page 512.

Use context values in notificationsWhen editing an alert rule you can use values derived from the context of the rule, including the functions and data associated with the rule, in the subject and message of your email notifications. The INSERT drop-downs to the right of the Subject and Message fields are for inserting these values, which are comprised of attributes, conditions and variables.

When you click the INSERT drop-down for the subject or message, an additional drop down and a scrollable list are displayed. The first drop down enables you to select the type of context value to add: attributes, conditions or variables.

If you select attributes, a second drop down enables you to select the Tracked Object associated with the rule from which the attributes are retrieved. The list has the available attributes.

If you select conditions or variables, the available conditions or variables are displayed. No other drop-down menus are displayed.

When you select a context value item, it is displayed in the subject or message of the notification.

Central Governance replaces the attributes, conditions and variables in the subject and message with values just before sending alert messages.

The Visibility user documentation describes how to use these. To access the documentation, select Flows > Monitoring to open the Visibility user interface. Select Help > Help and go to Event processing rules > View the rules and edit rules details > Use context values in alert rule notifications.


31 Deployment monitoring

The Deployment List page is for reviewing the status of objects in the process of deploying or updating, have deployed or updated successfully, or have failed. You can use a retry action for failed deployments and updates.

Deployment monitoring conceptsCentral Governance monitors as objects are being deployed and updated. Never-deployed objects are not tracked on the Deployment List page.

When objects deployed previously are changed, you must redeploy them to update the page. For example, you change a port in the configuration of one Transfer CFT, but the change is reflected on the Deployment List page only when the configuration is redeployed.

Monitoring for SecureTransportOn the Deployment List page you can monitor deployments of flows on each SecureTransport involved in the flow.

Central Governance does not deploy the following objects to SecureTransport and monitoring is not applicable: configurations, policies, legacy flows and updates.

Flows have global statuses not represented on the Deployment List page. Global statuses are listed in the Status columns on the Flow List page. In contrast, the specific status of a policy or flow for each linked product is displayed on the Deployment List page.

Monitoring for GatewayFor Gateway you can monitor deployments of:

l Flows – The state of a flow deployment on each Gateway instance the flow uses.

l Configurations – The state of the last deployment of configuration on a Gateway instance.

Flow deployment monitoringFlows have global statuses not represented on the Deployment List page. For example, global statuses are listed in the Status columns on the Flow List pages. In contrast, the specific status of a flow for each Gateway instance involved is displayed on the Deployment List page.



The deployment is first reported when the Gateway instance is registered successfully in Central Governance.

Configuration deployment monitoringThe status of a Gateway instance is not the same as the deployment status of its configuration. For example, the status of a Gateway instance might be Stopped on the Product List page, but the status of its configuration might be Deployed on the Deployment List page.

When a user triggers the configuration deployment on a Gateway instance, the corresponding table row is updated with the deployment state, date and time, and status on the Deployment List page.

If Gateway configuration deployment is unsuccessful, Central Governance does not roll back to the last successfully deployed configuration. This may leave Gateway in an inconsistent state. However, Central Governance retains the new configuration that failed to deploy. This enables you to try to redeploy the new configuration after fixing the problem. The objects already created on Gateway are ignored and only the objects that were not deployed during the failed deployment are created on Gateway.

When a Gateway instance is removed from the Product List page, Central Governance deletes the record of its configuration deployment from the Deployment List page.

Monitoring for Transfer CFTFor Transfer CFT you can monitor deployments of:

l Configurations – The state of the last deployment of the Transfer CFT configuration on an instance of Transfer CFT.

l Policies – The state of a Transfer CFT policy deployment on each Transfer CFT linked to the policy.

l Flows – The state of a flow deployment on each Transfer CFT the flow uses.

l Updates - The state of an update applied to a product.

Policies, flows and updates have global statuses not represented on the Deployment List page. For example, global statuses are listed in the Status columns on the Policy List and Flow List pages. In contrast, the specific status of a policy or flow for each linked Transfer CFT is displayed on the Deployment List page.

Transfer CFT configuration deployment monitoringOnly one table row is displayed for each Transfer CFT configuration on the Deployment List page. The deployment is reported when the instance of Transfer CFT is registered successfully in Central Governance.

The status of an instance of Transfer CFT is not the same as the deployment status of its configuration. For example, the status of an instance of Transfer CFT might be Stopped on the Product List page, but the status of its configuration might be Deployed on the Deployment List page.



When a user deploys a configuration for an instance of Transfer CFT, the deployment state, date and time, and status are updated for the Transfer CFT on the Deployment List page.

Changing a configuration affects reporting on the Deployment List page only when the changed configuration is deployed on Transfer CFT.

If the Transfer CFT is linked to a policy and the policy has not been deployed on it, the policy is deployed when a user deploys its configuration, and this is reported on the Deployment List page. Moreover, if a policy deployment fails (deployed in error status), the record associated with the policy on the Transfer CFT also is updated on the Deployment List page.

If Central Governance deploys a configuration to Transfer CFT and tries unsuccessfully to restart it, Central Governance rolls back to the last successfully deployed configuration. At the same time, Central Governance retains the new configuration that failed to deploy. This enables you to try again to redeploy the new configuration.

If Transfer CFT is stopped or a user deploys a configuration to it using the Deploy, no restart option, an invalid configuration is detected only when attempting to start the product. If invalid, a rollback is not performed and the product remains in Stopped status. Review the product's logs for clues to resolve the problem.

When an instance of Transfer CFT is removed from the Product List page, Central Governance deletes the record of its configuration deployment from the Deployment List page. If the removed Transfer CFT was linked to a policy, Central Governance also deletes those records from the page.

Transfer CFT policy deployment monitoringWhen a policy is deployed, its configuration is deployed on all instances of Transfer CFT linked to the policy. Central Governance adds a table row on the Deployment List page for each Transfer CFT. Central Governance also updates the configuration deployment of each Transfer CFT affected by the deployed policy. For example, if the policy is deployed to three instances of Transfer CFT:

l A table row of type Policy is added for each of the three Transfer CFT targets.

l A table row of type Configuration is updated for each of the three Transfer CFT targets.

Changing a policy affects reporting on the Deployment List page only when the changed policy is deployed on Transfer CFT.

When linking a policy to a new instance of Transfer CFT, the page is updated when the policy is deployed on it.

When unlinking a policy from an instance of Transfer CFT, Central Governance deletes the row for the policy on the Transfer CFT target. When a policy is deleted, Central Governance deletes all table rows associated with it.

Flow deployment monitoringWhen a flow is deployed, its configuration is deployed on all instances of registered products linked to the flow. A table row of type Flow is added on the Deployment List page for each affected product.



Changing a flow affects reporting on the page only when the changed flow is deployed on the product. For example, when an instance of Transfer CFT is added or removed as a source, target or relay in a flow, the changes are reported on the page when the changed flow is deployed or removed.

If Transfer CFTs, Gateways, or SecureTransports are removed as sources or targets in flows, the flow configuration also is removed from the affected product If the configuration on the removed product fails, the flow status becomes Deployed in error, and on the Deployment List page the target product has the status Removed in error.

When a flow is deleted, Central Governance deletes all table rows associated with it on the Deployment List page. If a flow is Removed in error, all deployment entries remain on the Deployment List page until the flow is removed successfully from all targets.

Product updatesCentral Governance can apply updates remotely to products that have been registered successfully. Updates are files containing service packs, patches and version upgrades for products.

See Product updates on page 204 for details.

Predefined filters for deployment monitoringSelect a predefined filtered view by clicking a category on the left side of the Deployment List page. The default sorting is the most recent by date. The predefined views are:

l All is an unfiltered view of all deployments.

l In Error (n) is a view of all failed deployments with a status of Deployed in error, with n the number that failed. The error reason in the Message column is the same as the popup text for deployments with Deployed in error status in the All view.

l Flows is a view of all deployments of the type Flow.

l Policies is a view of all policy deployments.

l Configurations is a view of all configuration deployments.

l Updates is a view of updates applied to products.

The following describes the columns in the tables for monitoring deployments on the page. The columns are common to the predefined filtered views you can select on the left side of the page. You can click Filter to apply filters by column headings, date/time, target and so on.

Date/Time

The date and time when the deployment process was completed. However, for a deployment with a Deploying status, this is the starting date and time of the deployment.

Status

The most recent status of the deployment.



For an error status, place the cursor over the status to view a popup description of the error and reasons for failure. You can attempt to redeploy failed deployments or updates by selecting an item in this state and clicking Retry.

The Configurations view also can display a status of Deployed, needs restart for a product that needs to be restarted after its configuration was changed and deployed with the Deploy, no restart option. The option lets you restart a product when you want rather than at the same time a configuration is deployed. Restarting is required for the configuration changes to become effective on the product. Go to the Product List page and restart the product when you are ready. Select Products on the top toolbar to open the page.

Target

The name of the product where the configuration or update is deployed. Click the value to open the details page for the product.

Item

The name of the deployed item. Click the value to open the details page for it. The details page that is displayed depends on the value in the Type column.

Type

The type of deployment or update.

Message

For deployments with an error status, a message provides reasons for the failure.

Retry configurations, policies, flows, updatesYou can redeploy a failed deployment, with the statuses Deployed in error and Removed in error, on the Deployment List page. This includes failed flows, policies, configurations and product updates. The retry action is available for deployments and updates with error statuses.

The status Removed in error identifies a failure to remove a flow configuration from a product. It can occur when a flow is removed from Central Governance or when a flow is deployed after a product was deleted from the flow. A flow is removed from Central Governance only when the flow configuration has been removed successfully from all the targeted products.

For failed deployments of type:

l Configuration, the action deploys the configuration again.

l Policy, the action redeploys the policy only on the selected instances of Transfer CFT. Redeploying a policy also redeploys the configuration of the associated Transfer CFT. See Policies on page 271.

l Flow, the action redeploys the flow only on the selected instances of products. See Defining flows on page 349.

l Update, the action tries again to install an update on the target products. See Product updates on page 204.



The following steps do not apply to products in the Configurations view that have a status of Deployed, needs restart. You need to restart such products for their most recently deployed configurations to become effective. Go to the Product List page and restart the products when you are ready. Select Products on the top toolbar to open the page.

1. Select Administration > Deployments to open the Deployment List page.

2. Select one or more table rows with a status of Deployed in error or Removed in error. For failed product updates, the status is Uploaded in error or Updated in error.

3. Click Retry.

Note that the retry action on a failed deployment does not re-deploy everything, just the selected part. For deployments, the status changes to Deploying before changing to Deployed for a successful deployment.

For failed flow removals, the status changes to Removing. The target product is removed from the Deployment List page when the removal succeeds. If the flow removal triggered the initial action and there are no more targets to remove, the flow also is removed from Central Governance.

For product updates, Updated indicates success.


Appendix A: Transfer CFT capacity planning

The following topics provide guidelines to help you perform capacity planning for implementing Transfer CFTs in a Central Governance environment. Also provided are results of Axway performance tests for Central Governance when managing Transfer CFTs.

The guidelines are based on results of specific performance and scalability tests of Central Governance and on knowledge gained during testing and development of Central Governance. Many untested factors, including network performance and various workload characteristics, can affect the performance of a production deployment. Use this documentation to plan your deployment, but it is essential to test your plan to verify it handles your workload and satisfies your performance objectives.

Planning stepsThe following are recommended high-level steps for Transfer CFT capacity planning in a Central Governance environment.

1. Identify and document your Transfer CFT workload and topology.

2. Determine your performance objectives.

3. Relate your workload, topology and objectives to the characteristics of the general guidelines in this capacity planning documentation.

4. Develop a deployment plan based on the guidelines and test results.

5. Implement a Central Governance test environment and load-test it to validate your deployment plan.

Performance factorsAxway has determined key factors for Central Governance performance. The following describes these performance factors and their roles in capacity planning.

For capacity planning with Central Governance you need to:

l Know the number of Transfer CFTs.

l Analyze the complexities of the Transfer CFT flows, or topologies, that Central Governance manages.

l Determine your performance objectives.



You can then relate your requirements and objectives to the Axway capacity planning guidelines and performance test results.

Workload characteristicsYou can determine or estimate workload characteristics by measuring your current workload and projecting future workload based on plans for business services that use Central Governance.

Factors to define or estimate include:

Number of Transfer CFTs

Each Transfer CFT is an object in the Central Governance database. The object requires memory for storage and processor time for status updates. Memory and processor time also are required when deploying Transfer CFT configuration.

Complexity of flows

The logical link between a source and destination Transfer CFT is defined as a path. Each path in a data flow is an object in the Central Governance database. The object requires memory for storage and consumes processor and network resources during deployment.

The complexity of your flows is a function of the number of paths. This affects the performance of Central Governance when deploying the flows on Transfer CFTs. To accurately plan the capacity of your Central Governance deployment, you must characterize your organizational needs and create Transfer CFT flows that provide the desired balance of performance, scalability and maintainability.

Performance objectivesYour performance objectives are defined by the level of service you provide to your business partners. Business requirements typically drive service objectives.

Use your performance objectives to evaluate your capacity plan. You must define these objectives to have the criteria for determining whether your capacity plan is sufficient.

Performance objectives can include:

Transfer CFT flow configuration deployment duration

The time required to deploy a flow configuration can be affected by the number of the Transfer CFTs included in the flow and the number of paths in the flow. Complex flows with many paths might take longer to deploy when compared to simple flows with fewer paths.

Transfer CFT policy deployment duration

The time required to deploy policy configuration can be affected by the number of Transfer CFTs managed by Central Governance.



Planning guidelinesThe following are guidelines for capacity planning. These are based on Axway's performance and scalability tests of Central Governance. See Performance benchmarks on page 522 for results of the Axway tests. Use these guidelines to develop your own capacity plan based on your processing requirements and deployment infrastructure.

Performance of Central Governance is affected by:

l Processing power of servers

l Transfer CFT topology

Transfer CFT topology is embodied in flows in a Central Governance environment. Axway tested a type of flow to collect performance characteristics and establish benchmarks. The corporate-to-store flow mirrors a common use case. Note that flows with the fewest paths result in faster performance and greater scalability.

A common corporate-to-store flow involves:

l Stores sending daily sales and inventory data to corporate headquarters

l Headquarters sending daily updated prices lists to stores

Details of such data exchanges are:

l At headquarters, a corporate application is integrated with a single instance of Transfer CFT

l The corporate application can exchange data, via Transfer CFT, with all stores

l Each store has a single instance of Transfer CFT on premise

l The stores can exchange data with the corporate application

l The stores cannot exchange data among themselves

This corporate-to-store flow is scalable because the number paths for n stores is n.

The following graphic illustrates a simple corporate-to-store flow.



Performance benchmarksAxway executes test scenarios to evaluate performance characteristics and establish benchmarks for Central Governance. The scenarios attempt to replicate common and extreme use cases. These are starting points for performance planning and cannot substitute for thorough performance evaluation of your environment.

Test environmentThe test environment for executing performance scenarios is managed in an isolated virtual environment.

All virtual machines in the test environment communicate on a private network. This ensures collected performance benchmarks reflect the performance of Central Governance, unaffected by the state of the network. This is an important consideration when evaluating performance in real-world installations.

All tests were executed on the cloud via Amazon Web Services (AWS) for scalability. Amazon Elastic Compute Cloud (Amazon EC2) c3.4xlarge was used. See http://aws.amazon.com/ec2/instance-types/ for more info about EC2 instances.

The following illustrates the test environment.


http://aws.amazon.com/ec2/instance-types/

http://aws.amazon.com/ec2/instance-types/


Central Governance Central Governance is installed on a virtual machine with the following specifications.

Specification Value

Number of virtual CPUs 16

CPU frequency 15 GHz

Memory 30 GB

Storage 2 x 160 GB SSD solid-state drive (SSD)

The following software is running on the VM.

l Red Hat Enterprise Linux 6.5 operating system

l JRE 1.8 update 40

In addition, the ulimit environment variables on each VM are:

l ulimit -n 4096 (number of opened files)

l ulimit -s unlimited (stack size)

l ulimit –u unlimited (number of processes)



Transfer CFT Transfer CFTs 3.2.2 are installed on virtual machines. Up to 250 Transfer CFTs are on each VM.

Test scenariosThe following describes the performance test scenarios and benchmarks.

Transfer CFT flow configuration deploymentsFlow deployment duration is the time required to deploy the configuration of flows. The Transfer CFTs are registered in Central Governance with a stopped status. The flows are created, saved, and deployed in Central Governance. The representational state transfer application programming interface (REST API) is used to deploy the flow configuration on the Transfer CFTs. The time between issuing the deploy command and when the flow has a deployed status is recorded as the deployment duration.

The following table shows the results of deploying flows. Times (duration) are minutes. All durations have ±1 second margin of error. The Transfer CFTs are not started.

Number of Transfer CFTs

Transfer CFTs per machine

Flow deployment duration

100 100/1 0.02

500 250/2 0.18

2000 250/4 2.18

5000 250/20 5.23

10,000 250/40 26.46

The following graph illustrates the scalability of flow deployments by comparing deployment time for different numbers of Transfer CFTs.



Transfer CFT policy configuration deploymentPolicy deployment duration is the time required to deploy the configuration to Transfer CFTs. The Transfer CFTs are registered in Central Governance with a stopped status. The policy is created and saved in Central Governance, but not deployed. The web API is used to deploy the policy configuration on the Transfer CFTs. The time between issuing the deploy command and when the policy has a deployed status is recorded as the deployment duration.

The following table and chart show the results of deploying a policy to Transfer CFTs. Times are minutes. All durations have ±1 second margin of error. The Transfer CFTs are not started.

Number of Transfer CFTs * Minutes

100 0.09

500 0.50

2000 2.21

3500 6.63

5000 13.30

* Transfer CFTs are not started.



RecommendationsThe following table provides recommendations for RAM in GB (gigabytes) for Central Governance based on the number of Transfer CFTs it manages.

Number of Transfer CFTs RAM GB

Up to 250 3

251 to 500 5

501 to 750 7

751 to 1,000 9

1,000 to 3,500 15

More than 3,500 30

The following ulimit settings are required for Linux:

l ulimit -n 4096 (number of opened files)

l ulimit -s unlimited (stack size)

l ulimit –u 65536 or higher (number of processes)

When installing Central Governance, the installer exits if these requirements are not met.


Appendix B: Transfer CFT corresponding parameters

The following topics have tables that list and describe fields in Central Governance that correspond to parameters in Transfer CFT.

Transfer CFT configuration in Central Governance and CFTUTIL

The following tables describe the Transfer CFT fields that can be configured in the Central Governance user interface and the corresponding Transfer CFT CFTUTIL parameters. Default Central Governance values are underlined.

See Transfer CFT command list and syntax in the Transfer CFT user guide for a list of Transfer CFT commands, syntax and parameters.

Network > protocols

CG field CG values CFTUTIL parameter Description

Interface Any | Any IPv4 | Any IPv6 | Address

CFTNET - HOST = INADDR_ANY | IN6ADDR_ANY | IN4ADDR_ANY | string

Networking IP address of the local resource (an entity through which connections can be established).


Network protocol

Enable | Disable

CFTPARM - NET (network) Shows whether the corresponding network protocol is active.

Once a network protocol section is available in Central Governance, a NET object of type TCP is created on Transfer CFT with:

ID=<name of the network protocol:TCP/PTCP or UDT>1

CLASS= the class corresponding to the selected network type:

l for TCP, class =1

l for UDT, class=2

l for pTCP, class=3

If the network protocol is enabled, the CFTNET object is referenced in the list of active networks of the current CFTPARM and it is taken into account during transfers execution.

UDT and pTCP are not supported on Transfer CFTs running on z/OS or IBM i computers.

Ports out 5000-65535 (5000-65535)

CFTNET - SRCPORTS = (6000-6009,6010-6019,6020-6030)

Definition of outgoing port ranges. The list of ports can contain up to 16 ranges.

Connections 1-2000 (128)

CFTNET - MAXCNX The maximum number of simultaneous connections that Transfer CFT accepts to establish on a given network resource.

PeSIT / SSL No security | SSL _DEFAULT

CFTPROT - SSL The security profile for a given protocol definition.

Protocol Enable | Disable

CFTPARM - PROT ('prot' list)

Once a protocol section is available in Central Governance, a PROT object of type PeSIT is created on Transfer CFT with:

ID=<ID_CFTNET>+<if No security:1;2>

NET=<ID_CFTNET>

If the protocol is enabled, the CFPROT object is referenced in the list of active protocols of the current CFTPARM and it is taken into account during transfers execution.

Port in 1025-65535

CFTPROT - SAP Number of the local monitoring port on which the monitor can be called.

Network > general


Maximum simultaneous transfers

Linux and Windows: 2-1000 (128)

z/OS and OS/400: 2-990 (128)

CFTPARM - MAXTRANS The maximum number of simultaneous connections that Transfer CFT accepts to establish for a network resource.

Disconnect timeout

0-3600 (60) CFTPROT - DISCTR, DISCTC

The wait timeout for either a response to the protocol connection request or to the partner in the connection, before disconnecting.

Attempts to restart transfer

0-32767 (5) CFTPROT - RESTART The maximum number of times that Transfer CFT attempts to restart a transfer.

IPv6 mode Client | Server | Both | None

UCONF - ipv6.disable_connect, ipv6.disable_listen

IPv6 resolution for host names when Transfer CFT is acting as a client, a server, both, or none.

Network > general > keep alive between transfers


Client 0-3600 (10)

CFTPROT - DISCTD The time to keep the session active between transfer activity on the client.

Server 0-3600 (60)

CFTPROT - DISCTS The time to keep the session active between transfer activity on the server.

Network > pTCP


Number of parallel connections

1-1024 (10)

UCONF - acceleration.ptcp.<netid>.nb_connections

The maximum number of striped connections.

Packet size (3000) UCONF - acceleration.ptcp.<netid>.packet_size

pTCP packet size in bytes

Buffer size (10) UCONF - acceleration.ptcp.<netid>.buffer_size

Internal acceleration buffer size in MB.

Network > UDT


Buffer size (10) UCONF - acceleration.udt.<netid>.buffer_size Internal acceleration buffer size in MB.

Network > PeSIT tuning > transmission


Compression Yes | No CFTPROT - SCOMP, RCOMP

Yes - 15

No - 0

Use compression on file transfers.

Inactivity timeout

0-3600 (60)

CFTPROT - rto Network monitoring timeout in seconds, excluding the protocol connection/disconnection/break phase. 0 means infinite.

Network > PeSIT tuning > synchronization


Acknowledgment window size

0-16 (3) CFTPROT - SCHKW, RCHKW

The window size setting the number of sync points that can occur.

Data transferred between sync points

0-32767 (32767)

CFTPROT - SPACING, RPACING

The number of KB transferred between sync points.


PeSIT password


PeSIT password

String of max 8c

CFTPART – NSPASSW

(CFTPART – NRPASSW)

Indicates the PeSIT password for the local partner. If the current Transfer CFT sends files or receives files from another Transfer CFT, the latter will contain this value in the CFTPART – NRPASSW parameter for the partner that corresponds to the current Transfer CFT.



Enable Yes | No UCONF - cft.server.bandwidth.enable

Manage data rates and the network bandwidth used for incoming and outgoing data in your flows.

Global data rate Unlimited | Limited

UCONF - cft.server.bandwidth.cos.0.max_rate_in, cft.server.bandwidth.cos.0.max_rate_out

Specifies limits on the rates of incoming and outgoing data. Allows setting, in kilobytes per second, the maximum for the rates of incoming and outgoing data.

Maximum incoming (global data rates is limited)

UCONF - cft.server.bandwidth.cos.0.max_rate_in

The maximum limit for incoming data transfer rates.

Maximum outgoing (global data rates is limited)

UCONF - cft.server.bandwidth.cos.0.max_rate_out

The maximum limit for outgoing data transfer rates.

Bandwidth allocation > priorityBandwidth allocation per priority level.

CG field CG values CFTUTIL parameter

High 80% UCONF -

cft.server.bandwidth.cos.1.weight_in

cft.server.bandwidth.cos.1.weight_out




Medium 15% UCONF -



Low 5% UCONF -



Transfer processing


User for file access

Transfer CFT system account | USERID variable

CFTPARM - USERCTRL = NO | YES Specifies the account that is used to read/write files transferred.

User for script execution

Transfer CFT system account | USERID variable

UCONF - cft.server.exec_as_user = NO | YES

Specifies the account that is used to execute scripts.

This parameter is not supported on Transfer CFTs running on z/OS or IBM i computers.

For an unknown flow

Use the system default | Reject request

UCONF - cft.default_idf.enable = YES | NO

The action to take if the flow is unknown.

Transmit files individually

Always | When necessary

UCONF - cft.server.force_heterogeneous_mode = YES | NO

Whether the transmission of a group of files is done by individual file, or grouped when possible.

When requesting all files

Stop on error | Continue

CFTPARM - RCVALLER = STOP (Stop on error) | CONTINUE (Continue)

The action to take if any of the transfers fail.

Transfer processing > When file existsConfigure post-transfer file renaming on the receiver side of a flow.



CG field UCONF parameter Description

Retry frequency

cft.server.transfer.rrename.retry_delay

Delay in seconds between two retries for renaming. If the file is not successfully renamed after the first retry_delay, the time doubles for the next retry period. For example, if the file is not renamed after 60 seconds (when using the default value), the next retry occurs in 120 seconds, and so on.

Maximum number of retries

cft.server.transfer.rrename.max_retries

Maximum number of retries.

Transfer processing > default scripts > source | targetAcknowledgment is only for source.

CG field CFTUTIL parameter Description

Post-processing CFTPARM – EXECSF | EXECRF The file to execute after the file is sent | received.

Acknowledgment CFTPARM - EXECSFA The file to execute after an acknowledgement is received for a sent file.

Error CFTPARM – EXECSE | EXECRE The file to execute after an error occurs during a file transfer

Transfer request mode > asynchronous


Description

Time between scans

1-6 (60) CFTCOM

- TYPE = FILE

- WSCAN

Interval in seconds to scan the transfer request communication file.

Transfer request mode > synchronous


Enable Yes | No CFTCOM - TYPE = TCPIP Add a communication media of type synchronous.




Host string, max 64, 127.0.0.1 by default

CFTCOM - HOST The host receiving commands. If HOST is updated at deployment, ADDRLIST is set to the empty value.

Port 1025-65535 (1765) CFTCOM - PORT The port to receive commands on.

Maximum connections

1-1024 (256) UCONF - cft.server.cftcoms.max_connection

Number of connections for the media communication.

Secured connections

Enable | Disable CFTCOM - PROTOCOL = XHTTP (Disable) | XHTTPS (Enable)

Use security for the request/reply protocol on the network.

Session timeout

0-86400 seconds or 0-1440 minutes (60 seconds)

CFTCOM - DISCTS Interval in seconds or minutes the Transfer CFT waits before closing an idle connection.

Transfer list


Number of entries in memory

1-32000 (1000) UCONF - cft.server.catalog.cache_size

The maximum number of entries in the memory buffer.

Update during transfer

Enabled | Disabled CFTCAT - UPDAT = 0 (Disabled)| 1..32767 (Enabled)

Update the transfer list while a transfer is occurring

(Update during transfer is Enabled)

1-32000 (1) sync points between updates

CFTCAT - UPDAT The number of synchronization points that occur during a transfer before updating the transfer list.

Synchronize list file when written

Yes | No UCONF - cft.server.catalog.sync.enable

Force the transfer list file to synchronize when Transfer CFT processes write to it.



Transfer list > entry retention


Purge Automatic | Manual

UCONF - cft.purge.periodicity Periodically remove older entries in the transfer list. The transfer list will grow indefinitely if manual purge is selected and start-up purge is disabled.

Purge is manual

UCONF - cft.purge.periodicity,value=0

Purge is automatic

1-999 (1) days between purges

UCONF - cft.purge.periodicity

Purge at startup

Yes | No UCONF - cft.purge.enable_on_start

Defines if the system should purge the transfer list at start up.

Purge increment

10 (minimum 10)

UCONF - cft.purge.quantity Defines how many transfers to delete from the transfer list file per step.

Keep aborted transfers

Yes | No CFTCAT - RKERROR (keep | delete)

Automatically delete aborted transfers without waiting for a purge.

Transfer list > entry retention > retention periodThe period is expressed in number of days, hours or minutes.


Completed incoming transfers

1-999 (10 UCONF -cft.purge.rx cft.purge.rt

Period after which the entries of incoming transfers that were successfully executed are purged.

Incomplete incoming transfers

1-999 (10 UCONF - cft.purge.rh, cft.purge.ry

Period after which the entries of uncompleted incoming transfers are purged.

Completed outgoing transfers

1-999 (10 UCONF - cft.purge.sx cft.purge.st

Period after which the entries of outgoing transfers that were successfully executed are purged.

Incomplete outgoing transfers

1-999 (10 UCONF - cft.purge.sh, cft.purge.sy

Period after which the entries of uncompleted outgoing transfers are purged.



CRONJOBs

CG field CG value CFTUTIL parameter

Description

Name string, max 32, empty by default

CFTCRON, id

Status Active / Inactive CFTCRON, state

To activate CRONJOB, State should be ACTIVE. To disable a CRONJOB, State should be NOACTIVE.

Description string, max 80, empty by default

CFTCRON, comment

Free comment. This comment is displayed and can be used to indicate a specific item of information (e.g. customer name, etc.)

Filename string, max 512, empty by default

CFTCRON, exec

Upload / Specify the script to be executed.

Schedule string, max 512, empty by default

CFTCRON, time

CRONJOB schedule syntax on page 234

User ID string, max 32, empty by default

CFTCRON, userid

The user for this job procedure.

Additional Information

string, max 512, empty by default

CFTCRON, parm

The PARM to be used in the job execution.

Cipher


Description

Minimum TLS version

SSL v3.0 | TLS v1.0 | TLS v1.1 | TLS v1.2 cft.ssl.version_min

The minimum version of TLS to be used by Transfer CFT in secured flows.


Description

TLS cipher suites

(49200) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

(49199) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

(49192) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

(49191) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

(157) TLS_RSA_WITH_AES_256_GCM_SHA384

(156) TLS_RSA_WITH_AES_128_GCM_SHA256 (61) TLS_RSA_WITH_AES_256_CBC_SHA256

(60) TLS_RSA_WITH_AES_128_CBC_SHA256

(53) TLS_RSA_WITH_AES_256_CBC_SHA

(47) TLS_RSA_WITH_AES_128_CBC_SHA

CFTSSL - CIPHLIST

List of TLS cipher suites to be used by Transfer CFT in secured flows.

Access and security > access management


Access type

None | Transfer CFT internal | Central Governance

am.type = none (None) | internal (Transfer CFT internal) | passport (Central Governance)

Type of access management to use in Transfer CFT.

Create process as user

Yes | No copilot.misc.createprocessasuser Specifies whether Transfer CFT Copilot user must have system rights.

Access type set to Central Governance


Organization <any organization from Central Governance>

am.passport.cg.organization Central Governance organization with users who can operate Transfer CFT.

Superusers am.passport.superuser List of users separated by comma with unlimited privileges on Transfer CFT.



Check permission for transfer execution

Yes | No am.passport.userctrl.check_permissions_on_transfer_execution

Check whether the user has permissions to execute transfers.

Access type set to Transfer CFT internal

CG field CG values

CFTUTIL parameter Description

Group database

SYSTEM | XFBADM

am.internal.group_database Type of database where group members are defined. On Windows, only SYSTEM group database is supported. This parameter is not supported on Transfer CFTs running on z/OS and IBM i computers.

Admin am.internal.role.admin List of groups mapped to the administrator role.

Application am.internal.role.application List of groups mapped to the application role.

Designer am.internal.role.designer List of groups mapped to the designer role.

Helpdesk am.internal.role.helpdesk List of groups mapped to the helpdesk role.

Partner manager

am.internal.role.partnermanager List of groups mapped to the partner manager role.

Access and security > security > FIPS


Enable Yes | No cft.fips.enable_compliance Activate FIPS security.

Visibility


Enable Yes | No UCONF - sentinel.xfb.enable


Visibility > servers

CG field CG values


Enable SSL/TLS Yes | No sentinel.xfb.use_ssl = yes | no

Specify if the connection to the monitoring server is secured.

Certificate

(Enable SSL/TLS is set to Yes, and Main server or Backup server is External)

<browse certificate>

Specify the trusted certificate for the External Visibility server. The certificate is imported in the PKI database.

Certificate alias

(Enable SSL/TLS is set to Yes, and Main server or Backup server is External)

sentinel.xfb.ca_cert_id Specify the trusted certificate alias as referred to in the PKI database. A “_<index>” is added at the end of the alias to avoid overlapping with existing certificates.

Main server Internal | External

sentinel.trkipaddr = <CG visibility host>

sentinel.trkipport =

l If Enable SSL/TLS = Yes, sentinel.trkipport = <CG visibility SSL server port>

l If Enable SSL/TLS = No, sentinel.trkipport = <CG visibility server port>

Host (Main server is External)

UCONF - sentinel.trkipaddr

Host for the main Sentinel server.

Port (Main server is External)

1-65535 (1305)

UCONF - sentinel.trkipport

Port for the main Sentinel server.

Backup server Internal | External | None

UCONF - sentinel.*


CG field CG values


Host (Backup server is External)

UCONF - sentinel.trkipaddr_bkup

Host for the backup Sentinel server.

Port (Backup server is External)

1-65535 (1305)

UCONF - sentinel.trkipport_bkup

Port for the backup Sentinel server.

Visibility > events


Transfer steps reported

All | First and last | None

UCONF - sentinel.xfb.transfer = ALL (All) sentinel.xfb.transfer = SUMMARY (first and last) sentinel.xfb.transfer = NO (None)

Level of detail for message content.

Transfer status frequency (transfer steps reported is All)

Every 60 seconds

UCONF - sentinel.xfb.transfer_progress_period in seconds

Specify how often the transfer status is updated in seconds or minutes.

Minimum log level Error | Fatal | Warning | Info | No log events

UCONF - sentinel.xfb.log = EF (Error) | F (Fatal) | WEF (Warning) | IWEF (Info) | empty (no logs)

Minimum severity level of the messages to display.

Buffer capacity 10000 UCONF - sentinel.xfb.buffer_size (in number of messages)

Maximum number of messages in Sentinel buffer

When buffer is full Drop new messages | Shut down

UCONF - sentinel.xfb.shut sentinel.xfb.shut = 0 => Drop new messages sentinel.xfb.shut = 95 => Shut down

Discard messages that exceed the buffer capacity, or shut down Transfer CFT when the visibility buffer is full



Logging


Entry size Linux, Windows and z/OS: 28-1024 (160) bytes

OS/400: 28-256 (160) bytes

CFTLOG - length Size of each entry in the logging file in bytes.

Timestamp precision

1 second | 10 ms | 100 ms UCONF - cft.cftlog.time_precision

The preciseness of the time displayed in the log, in seconds, 10 milliseconds or 100 milliseconds.

Logging > file rotation


Number of files in rotation

1-999 (3) UCONF - cft.cftlog.backup_count

Number of log files used in the rotation process. This parameter is not supported on Transfer CFTs running on z/OS computers.

Daily rotation time

00:00:00 daily time

CFTLOG - switch Time of day to rotate files.

Rotate based on size

Yes | No CFTLOG - maxrec = 0 (No) | 1..9999 KB (Yes)

Rotate log files when they reach a specific size.

(Rotate based on size is Yes)

Every 1-9999 ( 1024) KB

CFTLOG - maxrec The size based on which the file rotates.

Rotate on stop

Yes | No UCONF: cft.cftlog.switch_on_stop

Rotate files when Transfer CFT stops.


Folder monitoring

CG field CG value CFTUTIL parameter Description

Enable Yes | No UCONF - folder_monitoring.enable = NO | YES

Specifies whether folder monitoring is enabled.

Folder name string max 100, <empty>

UCONF - folder_monitoring.folders =1,2,…(each index corresponds to a Folder name in Central Governance)

Specifies the friendly name of each folder monitoring as identified in Central Governance. For each Folder name, an incremented index is added in the folders list. The index is referred for all parameters under a given folder monitoring instance.

Directory to scan

String max 512, <empty>

UCONF - folder_monitoring.folders..scan_dir

Path to the top-level directory to monitor.

Directory where files are tracked


UCONF - folder_monitoring.folders..work_dir

Path to the top-level directory for transferred files.

Flow identifier

First sub-folder | Second sub-folder | Custom

UCONF - folder_monitoring.folders..idf = <CFTSEND ID>(0) - First sub-folder(1) - Second sub-folder<value> - Custom

Identifier of the flow used in the transfer.

Partner First sub-folder | Second sub-folder | Custom

UCONF - folder_monitoring.folders..part = <CFTPART ID>(0) - First sub-folder(1) - Second sub-folder<value> - Custom

Partner who receives the file.

Scan sub-directories

Yes | No UCONF - folder_monitoring.folders..enable_subdir = YES | NO

Monitor the directory tree starting with the top-level directory.

Number of files to scan

Unlimited | Limited

UCONF - folder_monitoring.folders..file_count = -1

Whether the transmission of a group of files is done by individual file or grouped when possible.

(Number of files to scan is limited)

1 – 2147483647 (100)

UCONF - folder_monitoring.folders..file_count

Maximum number of files to scan for submission.

Time between scans

1 - 3600 (60 seconds)

UCONF - folder_monitoring.folders..interval

Seconds between scans.

Time before scanned files are submitted

0 – 3600 (5 seconds)

UCONF - folder_monitoring.folders..file_idle_delay

Files that have not changed during this interval can be submitted.

Method Move | File UCONF - folder_monitoring.folders..method

Specifies whether submitted files are moved or kept in the scan directory and tracked with a state file.

Append timestamp to submitted files(Method is Move)

Yes | No UCONF - folder_monitoring.folders..renaming_methodYes – TIMESTAMPNo - NONE

After the submission, the file is moved and renamed by appending the timestamp.

Resubmit changed files (Method is File)

Yes | No UCONF - folder_monitoring.folders..resubmit_changed_file = YES | NO

Specifies whether a file is submitted again if a change is detected.

Include file template


UCONF - folder_monitoring.folders..file_include_filter

Only files matching this pattern are monitored.

Exclude file template


UCONF - folder_monitoring.folders..file_exclude_filter

Files matching this pattern are excluded.

Minimum size Unlimited | Limited

UCONF - folder_monitoring.folders..file_size_min = -1 (Unlimited)

No minimum size limit for files to be submitted.

(Minimum size is limited)

1 - 2147483647 (1024)

UCONF - folder_monitoring.folders..file_size_min

Minimum size of files that can be submitted.

Maximum size

Unlimited | Limited

UCONF - folder_monitoring.folders..file_size_max = -1 (Unlimited)

No maximum size limit for files to be submitted.

(Maximum size is limited)

1 - 2147483647 (1024)

UCONF - folder_monitoring.folders..file_size_max

Maximum size of files that can be submitted.

Transfer CFT legacy flows in Central Governance and CFTUTIL

The following tables describe the Transfer CFT fields that can be configured in the Central Governance legacy flows user interface and the corresponding Transfer CFT CFTUTIL parameters.

Distribution list


Description

Name String, max 32 c. CFTDEST, ID Identifier of the distribution list.

Type -> Partner list 200 partners, each one has maximum 32 c.

CFTDEST, PART Explicit list of the identifiers of the various partners.

Type -> File -> Use existing file string, max 512 CFTDEST, FNAME Name of the file containing the list of partner identifiers. The file already exists on Transfer CFT.

Type -> File -> Upload new file file not empty, filename max 512,

CFTDEST, FNAME Name of the file to upload on Transfer CFT containing the list of partner identifiers.

Unknown partner Cancel (default) ; Continue ; Ignore

CFTDEST, NOPART Cancel -> Abort ;

Continue-> Continue;

Ignore-> Ignore

Select the action to perform when one of the partners is not defined.



Description

Processing scripts submission -> Apply pre-processing

On main request (default) ;

For each target in the list ;

Both

CFTDEST, EXECPRE

On main request -> DEST ;

For each target in the list -> CHILDREN ;

Both -> PART

Pre-processing procedure submit mode type:

On main request – Executes the script only on the main request.

For each target in the list – Executes the script only for each target in the list.

Both – Executes the script both for the main request and for each target in the list.

Processing scripts submission -> Apply post-processing



Both

CFTDEST, EXEC



Both -> PART

End of transfer procedure submit mode type:




Processing scripts submission -> Apply acknowledgement processing



Both

CFTDEST, EXECA



Both -> PART

Acknowledgment procedure submit mode type:




Partners


Description

Name String, 32 CFTPART.IDCFTTCP.ID

Description String, 80 CFTPART.COMMENT

Partner Access - Relay

String, 32 CFTPART.IPART If IPART is not empty, IMAXTIME = 0




Description

Partner Access --Local partner name

String, 24 CFTPART.NSPART Represents the identifier the Transfer CFT uses to identify itself to a partner.

Partner Access --Local partner password

String, 8 CFTPART.NSPASSW

Partner Access – Remote partner name

String, 24 CFTPART.NRPART Represents the identifier of the remote partner Transfer CFT.

Partner Access – Remote partner password

String, 8 CFTPART.NRPASSW

Partner Access – Host String : a list of entries separated by comma. Maximum 4 entries. Each entry can have maximum 50 characters.

CFTTCP.HOST

Partner Access – Operating system

List with values. See Operating systems and deployment correspondence on page 597.

CFTPART.SYST

Protocol – Security profile

String, 32 CFTPART.SSL

Protocol – Protocol CFTPART.CFTPROT ID

Protocol – Port in STRING LIST max_length=32 max_entries=4

CFTPART.SAP

Protocol > Network sessions > Incoming connections

Unix, Windows, IBM i: 0-1000z/OS: 0 - 990

CFTTCP.CNXIN Maximum number of sessions for input connections

Protocol > Network sessions > Outgoing connections


CFTTCP.CNXOUT Maximum number of sessions for output connections

Protocol > Network sessions > Total connections


CFTTCP.CNXINOUT Maximum number of communication sessions




Description

Hidden field n/a CFTTCP.CLASS The network protocol selected.1 - TCP2 - UDT3 - pTCP

Send template > transfer properties


Transfer priority

LOW, MEDIUM, HIGH, CUSTOM

CFTSEND, pri

LOW ->0 MEDIUM->128 HIGH-> 255 CUSTOM-> integer between 0...255

Transfer priorities are equivalent to integer values ranging from 0 (low) to 255 (high).When Transfer CFT reaches the maximum number of transfers allowed, it queues transfers. When an ongoing transfer is finished and a slot is available for a new transfer, the system selects the one with the highest priority.


LOW, MEDIUM, HIGH

CFTSEND, cosLOW ->3 MEDIUM->2 HIGH-> 1


Transfer state

Ready, On hold, Kept

CFTSEND, state

Ready (D) -> DISP On hold (H) ->HOLD Kept (K) ->KEEP

Indicates the state of the transfer request.: Ready, On Hold, Kept.Field is available in UI only if the Initiator is the source.If Target is the initiator, in source side the transfer state is ready and the field cannot be configured in Central Governance UI.

User id string, max 32, empty by default

CFTSEND, userid Identifier of the transfer owner. If this parameter is not defined, its default value is the system userid of the Transfer CFT.


string max 512, empty by default

CFTSEND, duplicat This field is used in detecting duplicate transfers and may contain a list of symbolic variables separated by a period ".".

Compress file

Yes, No

CFTSEND, ncomp

Yes → 15No → 0

Indicates whether files are compressed before they are transferred.





Continue transfer, Stop transfer

CFTSEND , fdispContinue transfer -> SHR Stop transfer-> CHECK

Available only in send template.Specify what happens if files are modified during the transfer.


Delete file ,Delete file content, None

CFTSEND, faction

Delete file -> Delete Delete file content -> Erase None-> None: default

Specifies what happens to the file in source side when the transfer is complete.Delete file – Deletes the file.Delete file content – Removes the contents of the file but leaves the "end of file" mark at the beginning of the file.None – No action is performed on the file.


Ready (D) ,Transferring (C), On Hold (H), Kept (K), Transferred (T), Executed (X)

CFTSEND, fdelete

Ready (D) ->D Transferring (C) -> C On Hold (H) -> H Kept (K) -> K Transferred (T) -> T Executed (X) -> X

Indicates the transfer states of files that is deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the associated transfers are removed from the transfer list.Ready – The transfer is available and can start immediately. Transferring – The transfer is being executed.On hold – The transfer was interrupted due to an error, such as a network failure, or by a user.Kept – The transfer was suspended by Transfer CFT or by a user.Transferred – The transfer was successfully completed.Executed – The transfer was ended by an application or user.



CFTSEND, parm Use this field for any information you want to provide.

Send template > file properties > filesIndicates whether you are sending one or more files.


Single - > Path

string max 512

CFTSEND, fname Indicate the single file to be sent.




Multiple -> Path

string max 512

CFTSEND, fname If you selected Multiple, the value you enter can be:A directory name – All of the files in this directory are transferred.A generic file name, including wildcard characters – Only files that match are transferred. For example, mydirectory/toto*.

Multiple -> File list

string max 512

CFTSEND, selfname This field is displayed if you selected Multiple in the Files field.Specify the name of the file that contains the list of files to be transferred. This file is also referred to as an indirection file. It must contain one file name per record, and that name must start in the first column of the file. The file names contained in the file must not contain an asterisk (*).When specifying a file here, the Path field is also required.

Multiple -> Archive name

string max 512

CFTSEND, wfname Name of the file that contains the set of files to be transmitted. Archive files are sent between systems that have the same operating system (grouped mode). The archive file is created automatically by Transfer CFT at the time of the transfer. The file created is a zip file on Windows systems and a tar file on Linux/UNIX systems. Because Windows systems do not have default compression utilities, Transfer CFT for Windows includes zip and unzip utilities.

File name sent

string max 512

CFTSEND, nfname Specify the name of the physical file that is to be used during transmission over the network.

Send template > file properties > file type (Linux and Windows)


Binary CFTSEND, ftype=B, fcode=BINARY, ncode=BINARY Specify whether the file is a binary file.

Text CFTSEND, see Transfer CFT configuration for FTYPE on Windows and Linux on page 585

Specify whether the file is a text file.

Stream text

CFTSEND, ftype = J Specify whether the file is a text file sent in Stream CFT mode.


Send template > file properties > file type (IBM i)


Data file CFTSEND, ftype=D, fcode=BINARY, ncode=BINARY

Specify whether the file is a PF-DTA file.

Save file CFTSEND, ftype=Z, fcode=BINARY, ncode=BINARY

Specify whether the file is a SAVF file.

Source CFTSEND, ftype=S Specify whether the file is a PF-SRC (with header) file.

OS 400 specific

CFTSEND, ftype=E Specify whether the file is a PF-SRC (no header) file.

Send template > file properties > file type (z/OS)


Autodetect CFTSEND, ftype= "", fcode=<empty>, ncode=<empty>

Specify whether the file is sent in auto detection mode.

Print file with ASA jump codes

CFTSEND, ftype= A Specify whether the file is Print file with ASA jump codes.

Print file with machine jump codes

CFTSEND, ftype= M Specify whether the file is Print file with machine jump codes.

Spanned variable format CFTSEND, ftype= S, fcode= BINARY, ncode= BINARY

Specify whether the file is a spanned variable file.

ARDSSU CFTSEND, ftype= 1, fcode= BINARY, ncode= BINARY

Specify whether the file is a ADRDSSU file.

Binary CFTSEND, ftype= B, fcode= BINARY, ncode= BINARY

Specify whether the file is a binary file.

Text CFTSEND, ftype= T Specify whether the file is a text file.

Stream Text CFTSEND, ftype= J Specify whether the file is a text file sent in Stream CFT mode.


Send template > file properties > record format

CG value CFTUTIL parameter Description

Record type

CFTSEND, see Transfer CFT configuration for record format on page 588

Specify whether the records in the file are fixed or variable length. Selecting Autodetect automatically identifies the record type.

Send template > processing scripts > pre-processing


Script -> Filename

Upload new file -> script to upload

Use existing file -> Filename field: string of max 512c

CFTSEND, preexec Specify the script to be executed before the file is transferred.

l z/OS: Filename length not to exceed 10 chars

l IBM i: Filename name must contain the sequence of blocks 8 chars + "."

l IBM i + z/OS: Upload only EBCDIC-encoded files. Upload of other files results in deployment failure.

State Ready,On hold

CFTSEND, prestateReady ->DISP : default On hold -> HOLD

Indicate the status of the transfer on the source. The script is run only if the transfer is in the specified state.Ready – Indicates that the transfer is available and can start immediately.On hold – Indicates that the transfer is deferred until a remote receive request is accepted, or until a local START command changes this transfer to the ready state.

Send template > processing scripts > post-processing


Script -> Filename

Upload new file -> script to uploadUse existing file -> Filename field: string of max 512c

CFTSEND, exec Specify the script to be executed after the file is transferred.








On main request, For each file in group,Both

CFTSEND, execsubOn main request -> LISTFor each file in group -> SUBF Both -> FILE

This field is displayed if you configure multiple files in send template transfer properties.

Send template > processing scripts > acknowledgment


Script -> Filename


CFTSEND, ackexec Specify the script to be executed after an acknowledgement is received for a sent file.




State Require,Ignore

CFTSEND, ackstateRequire -> REQUIRE Ignore -> IGNORE

Indicate if the transfer must wait for an acknowledgement.Require – The transfer must wait for an acknowledgement before it can be considered complete.Ignore – The transfer can be considered complete, even if an acknowledgement is not received.




This field is displayed if you configure multiple files in send template transfer properties.



Send template > processing scripts > error


Script -> Filename


CFTSEND, exece Specify the script to be executed after an error occurs during a transfer.




Receive template > transfer properties


Transfer priority


CFTRECV, pri

LOW ->0 MEDIUM->128 HIGH-> 255 CUSTOM-> integer between 0...255

Empty by default

Transfer priorities are equivalent to integer values ranging from 0 (low) to 255 (high).When Transfer CFT reaches the maximum number of transfers allowed, it queues transfers. When an ongoing transfer is finished and a slot is available for a new transfer, the system selects the one with the highest priority.


LOW, MEDIUM, HIGH

CFTRECV, cos

LOW ->3 MEDIUM->2 HIGH-> 1


Transfer state

Ready, On hold,Kept

CFTRECV, state

Ready (D) -> DISP On hold (H) ->HOLD Kept (K) ->KEEP

Indicates the state of the transfer request.: Ready, On Hold, Kept.


CFTRECV, userid Identifier of the transfer owner. If this parameter is not defined, its default value is the system "userid" of the Transfer CFT.






CFTRECV, duplicat This field is used in detecting duplicate transfers and may contain a list of symbolic variables separated by a period ".".

Compress file

Yes, No

CFTRECV, ncomp

Yes → 15No → 0

Indicates whether files are compressed before they are transferred.

No file exists

Create,Cancel

CFTRECV, see Transfer CFT configuration for no file exists, file exists on page 560

Specifies the action taken if the received file does not already exist.Create – The file is created.Cancel – The transfer is refused.

File exists Delete,Cancel,Overwrite, Overwrite only if empty,

Retry renaming after receiving temporary file


Specifies the action taken if the received file exists.Delete – The existing file is deleted.Cancel – The transfer is refused.Overwrite – The existing file is overwritten.Overwrite only if empty – The existing file is overwritten only if it contains no data.

Retry renaming after receiving temporary file - If no file exists, the file is created. If the file exists, after receiving a temporary file renaming the temporary file name is retried multiple times. After reaching the max retries the transfer is aborted.

Aborted transfer

Keep,Delete

CFTRECV, rkerror Specifies the action taken if a transfer is terminated due to a file creation error on the target.Keep – The transfer remains in the transfer list.Delete – The transfer is removed from the transfer list.



CFTRECV, fdelete

Ready (D) ->D Transferring (C) -> C On Hold (H) -> H Kept (K) -> K Transferred (T) -> T Executed (X) -> X

Indicates the transfer states of files that are deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the associated transfers are removed from the transfer list.Ready – The transfer is available and can start immediately. Transferring – The transfer is being executed.On hold – The transfer was interrupted due to an error, such as a network failure, or by a user.Kept – The transfer was suspended by Transfer CFT or by a user.Transferred – The transfer was successfully completed.Executed – The transfer was ended by an application or user.


Receive template > file properties > filesIndicates whether you are sending a single file or multiple files.

CG field CG values CFTUTIL-parameter Description

Filename string max 512,

for CFT hosted on z/OS and IBM i: defaulted to blank;

for other Linux and Windows:pub\&IDF.&IDTU.&FROOT.RCV

CFTRECV, fname Specify the file name or full path name for the received file or files.

Default value:

for CFT hosted on z/OS and IBM i defaulted to: blank;

for other Linux and Windows: pub\&IDF.&IDTU.&FROOT.RCV

Temporary file

string max 512 CFTRECV, wfname Specify the name of the temporary file used during the transfer. When the transfer is complete, the temporary file is renamed using the name defined in the Filename field. If you do not specify a value, Transfer CFT directly creates the file with the name specified in the Filename field.

Receive template > file properties > file type


Binary CFTRECV, ftype=B, fcode=BINARY Specify whether the file is a binary file.

Text CFTRECV, see Transfer CFT configuration for FTYPE on Windows and Linux on page 585


Stream text

CFTRECV, ftype = J Specify whether the file is a text file sent in Stream CFT mode.

Autodetect CFTRECV ftype= " " (not set), fcode=<empty>, ncode=<empty>


Note Commented out implies that the value is ignored.

Receive template > file properties > record format


Record type



Receive template > file properties > file type (IBM i)


Data file CFTRECV, ftype=D, fcode=BINARY Specify whether the file is a PF-DTA file.

Save file CFTRECV, ftype=Z, fcode=BINARY Specify whether the file is a SAVF file.

Source CFTRECV, ftype=S Specify whether the file is a PF-SRC (with header) file.

OS 400 specific CFTRECV, ftype=E Specify whether the file is a PF-SRC (no header) file.

Receive template > file properties > file type (z/OS)


Autodetect CFTRECV, ftype= " " (not set), fcode=<empty>




CFTRECV, ftype= A Specify whether the file is Print file with ASA jump codes.


CFTRECV, ftype= M Specify whether the file is Print file with machine jump codes.

Spanned variable format CFTRECV, ftype= S, fcode= BINARY Specify whether the file is a spanned variable file.

ARDSSU CFTRECV, ftype= 1, fcode= BINARY Specify whether the file is a ADRDSSU file.

Binary CFTRECV, ftype= B, fcode= BINARY Specify whether the file is a binary file.

Text CFTRECV, ftype= T Specify whether the file is a text file.



Stream Text CFTRECV, ftype= J Specify whether the file is a text file sent in Stream CFT mode.

Receive template > processing scripts > post-processing


Script -> Filename

if Custom, Filename field: string of max 512c

CFTRECV, exec Specify the script to be executed after the file is received.




Receive template > processing scripts > acknowledgment


Script -> Filename


CFTRECV, ackexec Specify the script to be executed after the file is received and post-processing is complete.





CFTRECV, ackstateRequire -> REQUIRE Ignore -> IGNORE

Indicate if the transfer must wait for an acknowledgement.Require – The transfer must wait for an acknowledgement before it can be considered complete.Ignore – The transfer can be considered complete, even if an acknowledgement is not received.


Receive template > processing scripts > error


Script -> Filename


CFTRECV, exece Specify the script to be executed if an error occurs when a file is received.




Transfer CFT configuration for FTYPE=TEXTAccording to the following flow settings table, CFTSEND and CFTRECV FTYPE can have different values: O, F, X or T for FTYPE=TEXT.

CG fields and Transfer CFT OS/ ftype value

O O F X T

File type Text Text Text Text Text

End of record character CRLF CRLF CRLF LF BOTH

Transfer CFT OS Linux WINDOWS WINDOWS doesn’t matter

doesn’t matter

Ignore end of file character doesn’t matter

NO YES doesn’t matter

doesn’t matter

Transfer CFT configuration for encoding/transcodingAccording to the following flow settings table, four fields from CFTSEND and CFTRECV are configured for each Transfer CFT selected in flow target: fcode, ncode, fcharset, ncharset.

CG field CFTSEND / CFTRECV CG value -> CFTSEND/CFTRECV field value

Encoding fcode ASCII -> ASCII EBCDIC -> EBCDIC CUSTOM -> <empty>

CG field CFTSEND / CFTRECV CG value -> CFTSEND/CFTRECV field value

Encoding charset fcharset For file type Text:

if Encoding=ASCII/EBCDIC => fcharset is not set else fcode is not set and fcharset= the value set in field and string max 32

For file type Stream Text:

fcharset is not set

Transcoding ncode None -> <empty>

ASCII -> ASCII EBCDIC -> EBCDIC CUSTOM -> <empty>

Transcoding charset ncharset For file type Text:

if Transcoding =None/ASCII/EBCDIC => ncharset is not set else ncode is not set and ncharset= the value set in field and string max 32


ncharset is not set

CG field CFTRECV CG value -> CFTRECV field value

Transcoding ncharset For file type Text:None -> “”ASCII -> ASCIIEBCDIC -> EBCDICCUSTOM -> else, the value set in field, string max 32

For file type Stream Text:ncharset = “”

Transcoding charset ncharset The value set in field, string max 32

Transfer CFT configuration for record format

CG field CFTSEND/CFTRECV

CG value -> CFTSEND/CFTRECV field value

CG default value

Comment

Record type

frecfm Fixed -> F Variable -> V

Autodetect -> “ " on CFTSEND and null on CFTRECV

Undefined -> U (on z/OS only)

Autodetect CFTSEND/CFTRECV frecfm might have the values U or <empty> and null, which are not available on CG. After the Transfer CFT registration these values are mapped in CG as follows:

l U - No value is set. You must set a value and deploy.

l Empty on CFTSEND -> Autodetect

l Null on CFTRECV -> Autodetect

Padding character/

Trimming character

fpad 16 characters <empty>


flrecl If the option is checked then the value 0 must be set in Transfer CFT. Otherwise, the next input text is enabled and the user can enter a value between 0...32767

Default OS value, flrecl=0

If this option is checked, then at deployment the value set in CFTSEND is 0 and Transfer CFT interprets it as:

l Transfer CFT on Windows: 512

l Transfer CFT on Unix:

o 512 for text files (FTYPE=T, O or X)

o 4096 for binary files (FTYPE=B)

Transfer CFT configuration for no file exists, file existsTwo CFTRECV fields correspond to the two CG fields.

The Comments column are remarks about file creation rule on receiver side regarding the existence of the file in the same location with the same name.

CG values CFTRECV, fdisp

CFTRECV, faction

Comments

No file exists=CREATE File exists=DELETE

both delete If no file exists, the file is created. If file exists it is deleted and recreated (no matter if it is empty or not).



CFTRECV, faction

Comments

No file exists=CREATE File exists=OVERWRITE

both erase If no file exists, the file is created. If file exists it is overwritten (no matter if it is empty or not).

No file exists=CREATE File exists=OVERWRITE ONLY IF EMPTY

both verify If no file exists, the file is created. If file exists and it is not empty, the transfer is aborted. If file exists but it is empty, the file is overwritten.

No file exists=CREATE

File exists= RETRY RENAMING AFTER RECEIVING TEMPORARY FILE

both retryrename If no file exists, the file is created. If the file exists, after receiving the temporary file, multiple attempts are made to rename the temporary file with the file name. Once the defined number of retries is reached, the transfer is aborted.

No file exists=CREATE File exists=CANCEL

new verify If no file exists, the file is created. If file exists the transfer is aborted (no matter if it is empty or not).

No file exists=CANCEL File exists=DELETE

old delete If no file exists, the transfer is aborted. If file exists the file is deleted and recreated (no matter if it is empty or not).

No file exists=CANCEL File exists=OVERWRITE

old erase If no file exists, the transfer is aborted. If file exists the file is overwritten (no matter if it is empty or not).

No file exists=CANCEL File exists=OVERWRITE ONLY IF EMPTY

old verify If no file exists, the transfer is aborted. If file exists and it is not empty, the transfer is aborted. If file exists but it is empty, the file is overwritten.

Flow configurations in Central Governance and CFTUTIL

The following tables list and describe corresponding flow configurations in Central Governance and Transfer CFT. Default Central Governance values are underlined.



Flow definition: SourceThe following tables describe the fields and parameters available in flow definition, source side, in Central Governance and CFTUTIL.

Transfer properties

CG

field

CG

values

API

flow

CFTUTIL

parameter

Description

Transfer priority


transferPriority

Integer 0 .. 255 customTransferPriorityEnabled TRUE, FALSE

CFTSEND, pri

LOW >0 MEDIUM>128 HIGH> 255 CUSTOM> integer between 0...255

Transfer priorities are equivalent to integer values ranging from 0 (low) to 255 (high).When Transfer CFT reaches the maximum number of transfers allowed, it queues transfers. When an ongoing transfer is finished and a slot is available for a new transfer, the system selects the one with the highest priority.Transfer priority is available when the source is the initiator.


LOW, MEDIUM, HIGH

bandwidth

LOW,

MEDIUM,

HIGH

CFTSEND, cosLOW >3 MEDIUM>2 HIGH> 1


Transfer state Ready, On hold, Kept

transferState

DISP,

HOLD,

KEEP

CFTSEND, state

Ready (D) > DISP On hold (H) >HOLD Kept (K) >KEEP

Indicates the state of the transfer request.: Ready, On Hold, Kept.Field is available in UI only if the initiator is the source.If target is the initiator, in source side the transfer state is ready and the field cannot be configured in the Central Governance UI.



CG

field

CG

values

API

flow

CFTUTIL

parameter

Description


userId CFTSEND, userid Identifier of the transfer owner. If this parameter is not defined, its default value is the system userid of the Transfer CFT.

Sender User id string, max 32, empty by default

idOfFileSender CFTSEND, suser Identifier of the user sending the file.

Receiver User id


idOfFileReceiver CFTSEND, ruser Identifier of the user receiving the file.



detectDuplicateTransfers CFTSEND, duplicat This field is used in detecting duplicate transfers and may contain a list of symbolic variables separated by a period ".".

On file not found

Abort transfer, Ignore transfer

fileNotFound

ABORT,

IGNORE

CFTSEND, filenotfound

Abort transfer > ABORT

Ignore transfer > IGNORE

Specify whether the flow fails if the file to transfer is not found.


Continue transfer, Stop transfer

fileModificationDuringTransfer

SHR,

CHECK

CFTSEND , fdispContinue transfer > SHR Stop transfer> CHECK

Available only in source side.Specify what happens if files are modified during the transfer.



CG

field

CG

values

API

flow

CFTUTIL

parameter

Description


Delete file ,Delete file content, None

actionAfterTransfer

NONE,

DELETE,

ERASE

CFTSEND, faction

Delete file > Delete Delete file content > Erase None> None: default

Specifies what happens to the file in source side when the transfer is complete.Delete file – Deletes the file.Delete file content – Removes the contents of the file but leaves the "end of file" mark at the beginning of the file.None – No action is performed on the file.



fileDeletionOnPurge

D,

C,

H,

K,

T,

X

CFTSEND, fdelete

Ready (D) >D Transferring (C) > C On Hold (H) > H Kept (K) > K Transferred (T) > T Executed (X) > X

Indicates the transfer states of files that will be deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the associated transfers are removed from the transfer list.Ready – The transfer is available and can start immediately. Transferring – The transfer is being executed.On hold – The transfer was interrupted due to an error, such as a network failure, or by a user.Kept – The transfer was suspended by Transfer CFT or by a user.Transferred – The transfer was successfully completed.Executed – The transfer was ended by an application or user.



CG

field

CG

values

API

flow

CFTUTIL

parameter

Description


Yes, No purgeCompletedTransfer

YES,

NO

CFTSEND, delete Indicates whether a completed transfer is purged from the transfer list or kept.



additionalInformation CFTSEND, parm Use this field for any information you want to provide.


[0; 32767] maxDuration CFTSEND, MAXDURATION

Zero (0) indicates a file transfer never times out.

Start date minDate CFTSEND, MINDATE Example of the mapping: 01 Apr 2014 --> CFT: 20140401 11 Jan 2017 --> CFT: 20170111

If the value is not indicated, Transfer CFT populates it with 10000101.

Start time minTime CFTSEND, MINTIME Example of the mapping: 3:12:11 --> CFT : 13121100 00:00:01 --> CFT : 00000100

MINTIME default 00:00:00

End date maxDate CFTSEND, MAXDATE If a value is not specified, Transfer CFT uses 99991231.

End time maxTime CFTSEND, MAXTIME MAXTIME default 23:59:59


Default, All, First and last,

None

visibilityMessageLevel

DEFAULT,

ALL,

FIRST_AND_LAST,

NONE

CFTSEND, trk

Default > UNDEFINED

All > ALL

First and last > >

SUMMARY

None > NO

Specify the level of transfer process step details to send as events to the Visibility service.



PeSIT properties

CG field CG values API

flow


Compress file

Yes, No

Protocols → properties → compression 15, 0

CFTSEND, ncomp

Yes → 15No → 0

Indicates whether files are compressed before they are transferred. Same value will be used for the compression on target side for the field CFTRECV, ncomp.

File properties > filesIndicates whether you are sending one or more files.

CG field CG values CG Flow API


Single - > Path

string max 512 sentFileName CFTSEND, fname Indicate the single file to be sent.

Multiple > Path

string max 512 Path CFTSEND, fname If you selected Multiple, the value you enter can be: A directory name – All of the files in this directory are transferred. A generic file name, including wildcard characters – Only files that match are transferred. For example, mydirectory/toto*.

Multiple > File list

string max 512 fileList CFTSEND, selfname This field is displayed if you selected Multiple in the Files field. Specify the name of the file that contains the list of files to be transferred. This file is also referred to as an indirection file. It must contain one file name per record, and that name must start in the first column of the file. The file names contained in the file must not contain an asterisk (*). When specifying a file here, the Path field is also required.



CG field CG values CG Flow API


Multiple > Archive name

string max 512, &IDF.&idtu.rcv

archiveName CFTSEND, wfname Name of the file that contains the set of files to be transmitted. Archive files are sent between systems that have the same operating system (grouped mode). The archive file is created automatically by Transfer CFT at the time of the transfer. The file created is a zip file on Windows systems, and a tar file on Linux/UNIX systems. Because Windows systems do not have default compression utilities, Transfer CFT for Windows includes zip and unzip utilities.

File name sent

string max 512 physicalFile CFTSEND, nfname Specify the name of the physical file that is to be used during transmission over the network.

Working directory

string max 512 Workingdir CFTSEND/WORKINGDIR Indicates the path to the directory for sent files in process and temporary files.

File properties > file type (Linux and Windows)Note The corresponding Transfer CFT flow API parameter is fileType.


Binary CFTSEND, ftype=B, fcode=BINARY, ncode=BINARY Specify whether the file is a binary file.

Text CFTSEND, see Transfer CFT configuration for FTYPE on Windows and Linux on page 585

section 4. Transfer CFT Configuration for FTYPE=TEXT


Stream text

CFTSEND, ftype=J Specify whether the file is a text file sent in Stream CFT mode.

File properties > record format


Record type





Processing scripts > pre-processing

CG field CG values CG Flow API CFTUTIL parameter Description

Script > Filename

Upload new file > script to uploadUse existing file > Filename field: string of max 512c

For GUI Script=None

preProcessingFileName=””

preProcessingFileUsage=existing_file

preProcessingFileContent_button=Browse

preScript=none

preProcessingFileContent=””

For GUI Script=Custom

preProcessingFileName=existing_file_name preProcessingFileUsage=existing_file preProcessingFileContent_button=Browse preScript=none preProcessingFileContent=””

For GUI Script=Custom preProcessingFileName=uploaded_file_name preProcessingFileUsage=”upload_file” preProcessingFileContent_button=Browse preScript=custom preProcessingFileContent=file_b64_encoded

CFTSEND, preexec Specify the script to be executed before the file is transferred.




State Ready,On hold

preProcessingState

DISP,

HOLD

CFTSEND, prestateReady >DISP : default On hold > HOLD

Indicate the status of the transfer on the source. The script is run only if the transfer is in the specified state.Ready – Indicates that the transfer is available and can start immediately.On hold – Indicates that the transfer is deferred until a remote receive request is accepted, or until a local START command changes this transfer to the ready state.



CG field CG values CG Flow API CFTUTIL parameter Description


On main request,For each target in the list,Both

preProcessingApplyToDistribList

DEST,

CHILDREN,

PART

CFTDEST, execpre

On main request > DEST For each target in the list > CHILDRENBoth > PART

This field is displayed if you enabled a broadcast list in source transfer properties.On main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.



Processing scripts > post-processing


flow


Script > Filename


For GUI Script=None

postProcessingFileName=””

postProcessingFileUsage=existing_file

postProcessingFileContent_button=Browse postScript=none

postProcessingFileContent=””


postProcessingFileName=existing_file_name postProcessingFileUsage=existing_file

postProcessingFileContent_button=Browse

postScript=none

postProcessingFileContent=””

For GUI Script=Custom postProcessingFileName=uploaded_file_name postProcessingFileUsage=”upload_file” postProcessingFileContent_button=Browse postScript=custom

postProcessingFileContent=file_b64_encoded

CFTSEND, exec Specify the script to be executed after the file is transferred.







flow




postProcessingApplyToGroup

LIST,

SUBF,

FILE


This field is displayed if you configure multiple files in source transfer properties.Values – On main request | For each target in the list | BothOn main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.



postProcessingApplyToDistribList

DEST,

CHILDREN,

PART

CFTDEST, exec


This field is displayed if you configure multiple files in source transfer properties.On main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.



Processing scripts > acknowledgment


flow


Script > Filename


For GUI Script=None acknowledgementFileName=”” acknowledgementFileUsage=existing_file

acknowledgementFileContent_button=Browse acknowledgementScript=none acknowledgementFileContent=””

For GUI Script=Custom acknowledgementFileName=existing_file_name acknowledgementFileUsage=existing_file

acknowledgementFileContent_button=Browse acknowledgementScript=none acknowledgementFileContent=””

For GUI Script=Custom acknowledgementFileName=uploaded_filename acknowledgementFileUsage=”upload_file”

acknowledgementFileContent_button=Browse acknowledgementScript=custom acknowledgementFileContent=file_b64encoded

CFTSEND, ackexec Specify the script to be executed after an acknowledgement is received for a sent file.





acknowledgementState

REQUIRE,

IGNORE

CFTSEND, ackstateRequire > REQUIRE Ignore > IGNORE

Indicate if the transfer must wait for an acknowledgment.Require – The transfer must wait for an acknowledgment before it can be considered complete.Ignore – The transfer can be considered complete, even if an acknowledgment is not received.




flow




acknowledgementApplyToGroup

LIST,

SUBF,

FILE


This field is displayed if you configure multiple files in source transfer properties.Values – On main request | For each target in the list | BothOn main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.



acknowledgementApplyToDistribList

DEST,

CHILDREN,

PART

CFTDEST, execa


This field is displayed if you enabled a broadcast list in source transfer properties.On main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.



Processing scripts > error


flow


Script > Filename


For GUI Script=None

errorFileName=””

errorFileUsage=existing_file

errorFileContent_button=Browse

errorScript=none errorFileContent=””


errorFileName=existing_file_name



errorScript=none

errorFileContent=””


errorFileName=uploaded_filename errorFileUsage=”upload_file”

errorFileContent_button=Browse errorScript=custom errorFileContent=file_b64encoded

CFTSEND, exece Specify the script to be executed after an error occurs during a transfer.




Flow definition: TargetThe following tables describe the fields and parameters available in flow definition, target side, in Central Governance and CFTUTIL.



Transfer properties


flow


Transfer priority


transferPriority

Integer 0 .. 255 customTransferPriorityEnabled TRUE,

FALSE

CFTRECV, pri

LOW >0 MEDIUM>128 HIGH> 255 CUSTOM> integer between 0...255

Transfer priorities are equivalent to integer values ranging from 0 (low) to 255 (high).

When Transfer CFT reaches the maximum number of transfers allowed, it queues transfers. When an incoming transfer is finished and a slot is available for a new transfer, the system selects the one with the highest priority.


LOW, MEDIUM, HIGH

bandwidth

LOW,

MEDIUM,

HIGH

CFTRECV, cosLOW >3 MEDIUM>2 HIGH> 1


Transfer state

Ready, On hold,Kept

transferState

DISP,

HOLD,

KEEP

CFTRECV, state

Ready (D) > DISP On hold (H) >HOLD Kept (K) >KEEP

Indicates the state of the transfer request: Ready, On Hold, Kept.Field is available in UI only if the initiator is the target.

If the initiator is the source, on the target side the transfer state has the value Ready and the field cannot be configured in the Central Governance UI.


userId CFTRECV, userid Identifier of the transfer owner. If this parameter is not defined, its default value is the system userid of the Transfer CFT.

Sender User id


idOfFileSender CFTSEND, suser Identifier of the user sending the file.

Receiver User id


idOfFileReceiver CFTSEND, ruser Identifier of the user receiving the file.




flow




detectDuplicateTransfers CFTRECV, duplicat This field is used in detecting duplicate transfers and may contain a list of symbolic variables separated by a period ".".

On file not found

Abort transfer, Ignore transfer

fileNotFound

ABORT,

IGNORE

CFTSEND, filenotfound

Abort transfer > ABORT

Ignore transfer > IGNORE

Specify whether the flow fails if the file to transfer is not found.

No file exists Create,Cancel

noFileExistsCreationRule

CREATE,

ABORT


Specifies the action taken if the received file does not already exist.Create – The file is created.Cancel – The transfer is refused.

File exists Delete,Cancel,Overwrite, Overwrite only if empty,

Overwrite after receiving temporary file,

Retry renaming after receiving temporary file

fileExistsCreationRule DELETE,

ABORT,

OVERWRITE,

OVERWRITE_IF_EMPTY,

RENAME,

RETRYRENAME


Specifies the action taken if the received file exists.Delete – The existing file is deleted.Cancel – The transfer is refused.Overwrite – The existing file is overwritten.Overwrite only if empty – The existing file is overwritten only if it contains no data.

Overwrite after receiving temporary file - UNIX only: Existing file is overwritten after receiving the temporary file. The user who performs the transfer must have rights to rename the temporary file name into the file to overwrite.

Retry renaming after receiving temporary file - If no file exists, the file is created. If the file exists, after receiving the temporary file, multiple attempts are made to rename the temporary file with the file name.




flow


Aborted transfer

Keep,Delete

abortedTransfer

KEEP,

DELETE

CFTRECV, rkerror Specifies the action taken if a transfer is terminated due to a file creation error on the target.Keep – The transfer remains in the transfer list.Delete – The transfer is removed from the transfer list.



fileDeletionOnPurge

D,

C,

H,

K,

T,

X

CFTRECV, fdelete

Ready (D) >D Transferring (C) > C On Hold (H) > H Kept (K) > K Transferred (T) > T Executed (X) > X

Indicates the transfer states of files that will be deleted when you remove the associated transfers from the transfer list or when you purge the transfer list. You can select any combination of statuses. If you do not select anything, files are not deleted even when the associated transfers are removed from the transfer list.Ready – The transfer is available and can start immediately. Transferring – The transfer is being executed.On hold – The transfer was interrupted due to an error, such as a network failure, or by a user.Kept – The transfer was suspended by Transfer CFT or by a user.Transferred – The transfer was successfully completed.Executed – The transfer was ended by an application or user.


Yes, No purgeCompletedTransfer

YES,

NO

CFTSEND, delete Indicates whether a completed transfer is purged from the transfer list or kept.


[0; 32767] maxDuration CFTRECV, MAXDURATION

Zero (0) indicates a file transfer never times out.




flow


Start date minDate CFTRECV, MINDATE Mapping example: 01 Apr 2014 --> CFT: 20140401 11 Jan 2017 --> CFT: 20170111

If the value is not indicated, Transfer CFT populates it with 10000101.

Start time minTime CFTRECV, MINTIME Mapping example: 3:12:11 --> CFT : 13121100 00:00:01 --> CFT : 00000100

MINTIME default 00:00:00

End date maxDate CFTRECV, MAXDATE If a value is not specified, Transfer CFT uses 99991231.

End time maxTime CFTRECV, MAXTIME MAXTIME default 23:59:59


Default, All, First and last,

None

visibilityMessageLevel

DEFAULT,

ALL,

FIRST_AND_LAST,

NONE

CFTSEND, trk

Default > UNDEFINED

All > ALL

First and last > SUMMARY

None > NO

Specify the level of transfer process step details to send as events to the Visibility service.

File properties > filesIndicates whether you are sending a single file or multiple files.


flow

CFTUTIL-parameter Description

Filename string max 512,Default value: pub\&IDF.&IDTU.&FROOT.RCV

targetFileName CFTRECV, fname Specify the file name or full path name for the received file or files. This field is required if the initiator of the flow is the source. Default value: pub\&IDF.&IDTU.&FROOT.RCV




flow

CFTUTIL-parameter Description

Temporary file

string max 512 temporaryFile CFTRECV, wfname Specify the name of the temporary file used during the transfer. When the transfer is complete, the temporary file is renamed using the name defined in the Filename field. If you do not specify a value, Transfer CFT directly creates the file with the name specified in the Filename field.

If the File exists parameter is set to Overwrite after receiving temporary file, Temporary file becomes required.

Working directory

string max 512 workingDir CFTRECV/WORKINGDIR

Indicates the path to the directory for received files in process and temporary files.

Receiving file size

[0; 2147483647] receivingFileSize

CFTRECV, FSPACE Specify the size allocation in kilobytes of the incoming file. If set to 0, Transfer CFT allocates space according to the file size specified by the sender at the protocol level. The parameter is available only for z/OS computers.

File properties > file typeNote The corresponding flow API parameter for Windows and Linux is fileType.


Binary CFTRECV, ftype=B, fcode=BINARY, fcharset="", ncharset="" Specify whether the file is a binary file.

Text CFTRECV, see Transfer CFT configuration for FTYPE on Windows and Linux on page 585

section 4. Transfer CFT Configuration for FTYPE=TEXT



Stream text

CFTRECV, ftype=J Specify whether the file is a text file sent in Stream CFT mode.

Autodetect CFTRECV ftype= " " (not set), fcode=<empty>, ncode=<empty>



File properties > record format


Record type

CFTRECV, see Transfer CFT configuration for record format on page 588


Processing scripts > post-processing


flow


Script > Filename


For GUI Script=None

postProcessingFileName=””


postProcessingFileContent_button=Browse postScript=none postProcessingFileContent=””

For GUI Script=Custom postProcessingFileName=existing_file_name


postProcessingFileContent_button=Browse

postScript=none postProcessingFileContent=””

For GUI Script=Custom postProcessingFileName=uploaded_file_name postProcessingFileUsage=”upload_file” postProcessingFileContent_button=Browse postScript=custom

postProcessingFileContent=file_b64_encoded

CFTRECV, exec Specify the script to be executed after the file is received.







flow




postProcessingApplyToGroup

LIST,

SUBF,

FILE


This field is displayed if you enabled a broadcast list in source transfer properties.Values – On main request | For each target in the list | BothOn main request – Executes the script only on the main request.For each target in the list – Executes the script only for each target in the list.Both – Executes the script both for the main request and for each target in the list.


On main request,For each source in the list,Both

postProcessingApplyToDistribList

DEST,

CHILDREN,

PART

CFTDEST, exec

On main request > DEST

For each source in the list > CHILDREN

Both > PART

This field is displayed if you enabled a collect list in target transfer properties.On main request – Executes the script only on the main request.For each source in the list – Executes the script only for each source in the list.Both – Executes the script both for the main request and for each source in the list.



Processing scripts > acknowledgment


flow


Script > Filename


For GUI Script=None

acknowledgementFileName=”” acknowledgementFileUsage=existing_file acknowledgementFileContent_button=Browse acknowledgementScript=none acknowledgementFileContent=””

For GUI Script=Custom acknowledgementFileName=existing_file_name acknowledgementFileUsage=existing_file acknowledgementFileContent_button=Browse acknowledgementScript=none acknowledgementFileContent=””

For GUI Script=Custom acknowledgementFileName=uploaded_filename acknowledgementFileUsage=”upload_file” acknowledgementFileContent_button=Browse acknowledgementScript=custom acknowledgementFileContent=file_b64encoded

CFTRECV, ackexec Specify the script to be executed after the file is received and post-processing is complete.







flow



acknowledgementState

REQUIRE,

IGNORE

CFTRECV, ackstateRequire > REQUIRE Ignore > IGNORE

Indicate if the transfer must wait for an acknowledgment.Require – The transfer must wait for an acknowledgment before it can be considered complete.Ignore – The transfer can be considered complete, even if an acknowledgement is not received.


On main request,For each source in the list,Both

acknowledgementApplyToDistribList

DEST,

CHILDREN,

PART

CFTDEST, execa

On main request > DEST

For each source in the list > CHILDRENBoth > PART

This field is displayed if you enabled a collect list in target transfer properties.On main request – Executes the script only on the main request.For each source in the list – Executes the script only for each source in the list.Both – Executes the script both for the main request and for each source in the list.



Processing scripts > error


flow


Script > Filename


For GUI Script=None

errorFileName=””



errorScript=none errorFileContent=””


errorFileName=existing_file_name errorFileUsage=existing_file errorFileContent_button=Browse errorScript=none errorFileContent=””

For GUI Script=Custom errorFileName=uploaded_filename errorFileUsage=”upload_file”

errorFileContent_button=Browse errorScript=custom errorFileContent=file_b64encoded

CFTRECV, exece Specify the script to be executed if an error occurs when a file is received.




Transfer CFT configuration for FTYPE on Windows and LinuxAccording to the following flow settings table, CFTSEND and CFTRECV FTYPE can have different values: O, F, X or T for FTYPE=TEXT.


API

flow

O O F X T

File type fileType Text Text Text Text Text

End of record character endOfRecordChar

CRLF CRLF CRLF LF BOTH

Transfer CFT OS - Linux WINDOWS WINDOWS doesn’t matter

doesn’t matter


API

flow

O O F X T

Ignore end of file character ignoreEOFChar

TRUE,

FALSE

doesn’t matter

NO YES doesn’t matter

doesn’t matter

Transfer CFT configuration for FTYPE on IBM iAccording to the following flow settings table, CFTSEND and CFTRECV FTYPE for IBM i can have the following values: D, E, S, Z. Encoding and transcoding fields are configurable when fcode and ncode support other than BINARY.

The corresponding Transfer CFT flow API parameter is fileTypeOS400.

Central Governance File type value

Transfer CFT ftype value

Central Governance encoding/transcoding and Transfer CFT fcode/ncode value

Binary (default) B fcode=BINARY, ncode=BINARY

Text T See Transfer CFT configuration for encoding/transcoding on page 587

Stream text J See Transfer CFT configuration for encoding/transcoding on page 587

Binary stream <empty> fcode=BINARY, ncode=BINARY

Edit native file E See Transfer CFT configuration for encoding/transcoding on page 587

Non-edit native file N fcode=BINARY, ncode=BINARY

Autodetect (default) <empty> Not defined

Transfer CFT configuration for FTYPE on z/OSAccording to the following flow settings table, CFTSEND and CFTRECV FTYPE for z/OS can have the following values: A, M, S, 1, _, B, T. Or it can be auto-detected. FTYPE=_ only is available for CFTRECV. Encoding and transcoding fields are available for configuration when fcode and ncode support other than BINARY.

The corresponding Central Governance flow API parameter is fileTypeZOS.

Central Governance File type value

Transfer CFT ftype value

Central Governance encoding/transcoding and Transfer CFT fcode/ncode value

Autodetect (default) <empty> Not defined


A See Transfer CFT configuration for encoding/transcoding on page 587


M See Transfer CFT configuration for encoding/transcoding on page 587

Spanned variable format S fcode=BINARY, ncode=BINARY

ARDSSU 1 fcode=BINARY, ncode=BINARY

PDSE (only for receiver) _ fcode=BINARY, ncode=BINARY

Binary B fcode=BINARY, ncode=BINARY

Text T See Transfer CFT configuration for encoding/transcoding on page 587

Stream text J fcode/ncode: See Transfer CFT configuration for encoding/transcoding on page 587.

Transfer CFT configuration for encoding/transcoding According to the following flow settings table, four fields from CFTSEND and CFTRECV are configured for each Transfer CFT selected in flow target: fcode, ncode, fcharset, ncharset.

CG field CG Flow

API

CFTSEND / CFTRECV


Encoding encoding

encodingZOS

encodingOS400

fcode ASCII -> ASCII EBCDIC -> EBCDIC CUSTOM -> <empty>

Encoding charset

encodingCharset

encodingZOSCharset

encodingOS400Charset

fcharset For file type Text:

if Encoding=ASCII/EBCDIC => fcharset is not set else fcode is not set and fcharset= the value set in field and string max 32


fcharset is not set

CG field CG Flow

API

CFTSEND / CFTRECV


Transcoding transcoding

transcodingZOS

transcodingOS400

ncode None -> ‘ ‘

ASCII -> ASCII EBCDIC -> EBCDIC CUSTOM -> <empty> (Windows and Linux only)

Transcoding charset

transcodingCharset

transcodingZOSCharset

transcodingOS400Charset

ncharset For file type Text:

if Transcoding =None/ASCII/EBCDIC => ncharset is not set else ncode is not set and ncharset= the value set in field and string max 32

ncode is not available for Stream Text > Target

Transfer CFT configuration for record format

CG value CFTSEND/CFTRECV

CG Flow

API


CG default value

Comment

Record type

frecfm recordFormat

F,

V

Fixed -> F

Variable -> VAutodetect -> “ " on CFTSEND and null on CFTRECVUndefined -> U (only on z/OS)

Autodetect For multiple types of OS in the source/target, the value Undefined is mapped as follows:

l On CFTSEND: “ “ for Windows/Linux/OS400{IBM i] and U for z/OS.

l On CFTRECV: null for Windows/Linux/OS400 [IBM i] and U for z/OS.

CG value CFTSEND/CFTRECV

CG Flow

API


CG default value

Comment

Padding character/

Trimming character

fpad unpaddingChar 16 characters <empty> If character typed in padding/trimming character is not visible, the character name must be displayed. (If space character is typed as trimming character, label SPACE is displayed.)

To use a special character as a trimming or padding character, set the hexadecimal value as follows:

l x’08FD’ (base UTF-16) up to 8 characters if the charset is 32 bits (like UTF-32LE)

l x’084FD1AE4’ (base UTF-32) up to 16 characters


flrecl maxRecordLength

true,

false defaultMaxRecordLength

TRUE,

FALSE

If the option is checked then the value 0 must be set in Transfer CFT. Otherwise, the next input text is enabled and the user can enter a value between 0...32767

option checked, flrecl=0

If this option is checked, then at deployment the value set in CFTSEND is 0 and Transfer CFT interprets it as:

l Transfer CFT on Windows: 512

l Transfer CFT on Unix:

o 512 for text files (FTYPE=T, O or X)

o 4096 for binary files (FTYPE=B)

Transfer CFT configuration for no file exists, file existsTwo CFTRECV fields correspond to the two CG fields.

The Comments column expresses remarks about file creation rule on the receiver side regarding the existence of the file in the same location with the same name.



CFTRECV, faction

Comments

No file exists=CREATE File exists=DELETE

both delete If no file exists, the file is created. If the file exists it is deleted and recreated (regardless of if it is empty or not).

No file exists=CREATE File exists=OVERWRITE

both erase If no file exists, the file is created. If the file exists it is overwritten (regardless of if it is empty or not).

No file exists=CREATE File exists=OVERWRITE ONLY IF EMPTY

both verify If no file exists, the file is created. If file exists and it is not empty, the transfer is aborted. If the file exists but it is empty, the file is overwritten.

No file exists=CREATE File exists=OVERWRITE AFTER RECEIVING TEMPORARY FILE

both rename If no files exists, the transfer is aborted. If the file exists and is not empty, the transfer is aborted. If the file exists and is empty, the file is overwritten.

No file exists=CREATE

File exists= RETRY RENAMING AFTER RECEIVING TEMPORARY FILE

both retryrename If no file exists, the file is created. If the file exists, after receiving the temporary file, multiple attempts are made to rename the temporary file with the file name. Once the defined number of retries is reached, the transfer is aborted.

No file exists=CREATE File exists=CANCEL

new verify If no file exists, the file is created. If file exists the transfer is aborted (regardless of if it is empty or not).

No file exists=CANCEL File exists=DELETE

old delete If no file exists, the transfer is aborted. If file exists the file is deleted and recreated (no matter if it is empty or not).

No file exists=CANCEL File exists=OVERWRITE

old erase If no file exists, the transfer is aborted. If file exists the file is overwritten (regardless of if it is empty or not).




CFTRECV, faction

Comments

No file exists=CANCEL File exists=OVERWRITE ONLY IF EMPTY

old verify If no file exists, the transfer is aborted. If the file exists and it is not empty, the transfer is aborted. If the file exists but it is empty, the file is overwritten.

No file exists=CANCEL

File exists=OVERWRITE AFTER RECEIVING TEMPORARY FILE

old rename If no file exists, the transfer is aborted. If file exists, the file is overwritten after receiving the temporary file by renaming the temporary file with the file name. This option is available only for Transfer CFT on Unix.

Combination forbidden: No file exists=CANCEL, File exists=CANCEL

Transfer CFT partners in flowsThe following topics define Transfer CFT partners as used in Central Governance flows.

When a flow using Transfer CFTs is deployed, Central Governance deploys on each Transfer CFT the definition of the partners defined in the flow. There are two Transfer CFT partner objects involved: CFTPART and CFTTCP.

l For each CFTPART, Central Governance sets values for the fields ID, NRPART, NRPASSW, NSPART, NSPASSW, PROT, SAP, SSL (if mutual authentication is used). The NSPASSW/NRPASSW is either generated or configured in the Transfer CFT static configuration.

l For each CFTTCP, Central Governance sets values for the fields ID, CLASS, HOST.

All the other fields of CFTTCP and CFTPART have the default values.

You can overwrite the following fields with values from the partner template configuration file.

Transfer CFT field

Partner template parameter

Partner template value Default Central Governance value if property is not set

CFTPART - ID Name of the Transfer CFT partner.

%HOSTNAME% (product host as it appears in the product list)


CFTTCP – CNXIN, CNXOUT, CNXINOUT

cft.partner.cnxin

cft.partner.cnxout

cft.partner.cnxinout

0..1000 CNXIN = '64', CNXOUT = '64', CNXINOUT = '64'

CFTTCP – RETRYW, RETRYM, RETRYN

cft.partner.retryw

cft.partner.retryn

cft.partner.retrym

0..32767 RETRYW = '7', RETRYM = '12', RETRYN = '6',



When a broadcast or collect list is used in flows, Central Governance deploys a new object, CFTDEST. This is in addition to partners definition (CFTPART and CFTTCP objects) for each Transfer CFT partner.

Transfer CFT partner definitionThis topic has tables for defining Transfer CFT partners:

l CFTPART fields and corresponding Central Governance fields

l CFTTCP fields and corresponding Central Governance fields

CFTPARTThe following table lists the CFTPART fields and corresponding Central Governance fields for defining Transfer CFT partners.

l The same protocol must always be used between two Transfer CFTs. Only the security option can change.

l There is a Central Governance limitation. If you change the protocol in a flow, the configuration associated to the previous protocol is not removed on the Transfer CFTs involved in the flow. The new configuration is added in the list of available communications modes with the partner.

CFTPART field

Corresponding field in Central Governance

Type

ID Name of the Transfer CFT partner. STRING max_length=32

NRPART Name of the Transfer CFT partner. STRING max_length=24

NRPASSW PeSIT password of the Transfer CFT. It is the reversed value of the Transfer CFT name.

STRING max_length=8

NSPART Name of the current Transfer CFT. STRING max_length=24

NSPASSW PeSIT password of the Transfer CFT. It is the reversed value of the partner Transfer CFT name.

STRING max_length=8

PROT Protocol name defined on the current Transfer CFT for the flow protocol options: network protocol/security.

STRING LIST max_length=32 max_entries=4

SAP Port defined in the partner Transfer CFT for the flow protocol options: network protocol/security.


If the Transfer CFT partner is only receiving data (is the target, Direction = Sender pushes files and acknowledgments are not enabled), the SAP field is not set.



CFTPART field


Type

SYST Operating system of the unmanaged product.

STRING

CFTTCPThe following table lists the CFTTCP fields and corresponding Central Governance fields for defining Transfer CFT partners.

If the flow has relays defined, additional rules are applied. Flow with relays on page 596.

CFTTCP field


Type

ID Name of the Transfer CFT partner. STRING, max_length=32

HOST Host of the current Transfer CFT. string list max_length=512 max_entries=4

If the Transfer CFT partner is only receiving data (is the target, Direction = Sender pushes files and acknowledgments are not enabled), the HOST is set to INADDR_ANY.

CLASS Class of the network protocol defined on the current Transfer CFT for the flow protocol option: network protocol.

1 - TCP2 - UDT3 - TCP

Number min=0 max=64

Unmanaged product partner definitionThis topic has tables for defining unmanaged product partners:

l CFTPART fields and corresponding Central Governance fields

l CFTTCP fields and corresponding Central Governance fields

CFTPARTThe following table lists the CFTPART fields and corresponding Central Governance fields for defining unmanaged product partners.

If the flow has relays defined, additional rules are applied. See Flow with relays on page 596.


CFTPART field

Corresponding field in Central Governance Type

ID PeSIT login of the unmanaged product. STRING max_length=24

NRPART PeSIT login of the unmanaged product. STRING max_length=24

NRPASSW PeSIT password of the unmanaged product. STRING max_length=8

NSPART Name of the current Transfer CFT. STRING max_length=32

NSPASSW Reversed value of the current Transfer CFT name. STRING max_length=40

PROT Protocols defined on the Transfer CFT for the flow protocol options: network protocol/security.

SAP Ports defined in the unmanaged product for the flow protocol options: network protocol/security.


If mutual authentication is used, the CFTSSL object from the CFT with the ID=SSL_Default is updated. The alias of the new certificate is added to the value of the field ROOTCID.

CFTTCPThe following table lists the CFTTCP fields and corresponding Central Governance fields for defining unmanaged product partners.

CFTTCP field

Corresponding field in Central Governance Type

ID PeSIT login of the unmanaged product. STRING max_length=24

HOST Hosts of the unmanaged product. STRING list max_length=512 max_entries=4

CLASS Class of the network protocol defined on the current Transfer CFT for the flow protocol option: network protocol.

1 - TCP2 - UDT3 - pTCP

Number <1> min=0 max=64

Flow using distribution listWhen a broadcast or collect list is used in flows, Central Governance deploys a new object, CFTDEST. This is in addition to partners definition (CFTPART and CFTTCP objects) for each Transfer CFT partner.


l Broadcast list for each Transfer CFT defined in source

l Collect list for each Transfer CFT defined in target

CFTDEST field


Type

ID Name of the broadcast or collect list defined in flow UI.


FNAME Broadcast list / Collect list -> File

Name of the file containing the names of the Transfer CFTs or the PeSIT logins of the partners.

The file is generated by Central Governance based on the sources or targets selected.

For a broadcast list, the file contains the partners selected in the flow target.

For a collect list, the file contains the partners selected in the flow source.


The number of partners in the file is not limited.

PART Broadcast list / Collect list -> Partner list

The names of the Transfer CFTs or the PeSIT logins of the partners.

For a broadcast list, the field contains the partners selected in the flow target.

For a collect list, the field contains the partners selected in the flow source.

33*200 STRING LISTeach item: max_length=32list: max_entries=200

If more than 200 Transfer CFTs are selected as partners, Central Governance warns that it is recommended to use the File option as Transfer CFT PART supports maximum 200 partners.

NOPART Flow Source, Transfer Properties section -> Unknown targetFlow Target, Transfer Properties section -> Unknown sourcePossible values:

Central Governance:

Cancel

Continue

Ignore

Transfer CFT:

Abort

Continue

Ignore


Flow with relaysA flow in Central Governance with defined relays, as long as store and forward mode is enabled and valid on the flow, is deployed to force routing of the file by the intermediate partner. The IPART parameter defines the immediate partner of the initial sender.

The following are additional rules for defining partners in flows.

On Transfer CFT source l Partner for the Transfer CFT target (normal definition) +

o If relays exist:

o ipart=<first relay>

o OMINTIME=0

o OMAXTIME=0

l + If relays exists, partner for the first Transfer CFT relay (normal definition)

On each relay l Partner for the Transfer CFT before (normal definition)

l Partner with the Transfer CFT target +:

o If next Transfer CFT is not the Transfer CFT target:

o ipart=<next partner>

o OMINTIME=0

o OMAXTIME=0

o Partner for the Transfer CFT defined in the ipart parameter (normal definition) ( if ipart Transfer CFT is different then target )

l Partner with the Transfer CFT source +:

o if Transfer CFT before is not the Transfer CFT source:

o ipart=<Partner before>

o OMINTIME=0

o OMAXTIME=0

On Transfer CFT target l Partner with the Transfer CFT source:

o If Transfer CFT relay exists:

o Ipart=<partner before >

o OMINTIME=0

o OMAXTIME=0

l + If relays exist, CFTPART for the last relay (normal definition)

Operating systems and deployment correspondenceThe following table lists Central Governance values and correspondence with middleware components.

Central Governance value Transfer CFT CFTPART:SYST

aix-power-32 (default value) UNIX

aix-power-64 UNIX

hpux-ia64-64 UNIX

hpux-parisc-32 UNIX

hpux-parisc-64 UNIX

linux-ia64-64 UNIX

linux-s390-32 UNIX

linux-s390-64 UNIX

linux-x86-32 UNIX

linux-x86-64 UNIX

sun-sparc-32 UNIX

sun-sparc-64 UNIX

sun-x86-32 UNIX

sun-x86-64 UNIX

win-ia64-64 WINNT


Central Governance value Transfer CFT CFTPART:SYST

win-x86-32 WINNT

win-x86-64 WINNT

MVS MVS

OS2200 OS2200

os400 OS400

vms-ia64 VMS

vms-alpha VMS

hp_nonstop_oss-ia64-32 GUARD

hp_nonstop_oss-x86-32 GUARD

Any other value that is found on Transfer CFT when importing the Transfer CFT partners or upgrading from Central Governance 1.0.2 to 1.1 is imported or migrated to aix-power-32.


Appendix C: SecureTransport corresponding fields

The following topics have tables that list and describe fields in Central Governance that correspond to fields in SecureTransport.

Protocol fields in Central Governance and SecureTransport

The following tables map protocol fields in Central Governance and SecureTransport.

PeSIT

Central Governance field

SecureTransport field Central Governance values

Comment

Protocol Operations > Server control > PeSIT Server > Enable PeSIT over <TCP/pTCP> <Secure/Plain>

PeSIT PeSIT servers corresponding to the Central Governance server communication profiles are enabled and started on SecureTransport.

Port Operations > Server control > PeSIT Server > Enable PeSIT over <TCP/pTCP> <Secure/Plain> Socket > Port

[1..65535]

Comment

Network protocol

Operations > Server control > PeSIT Server > Enable PeSIT over:CG: TCP + Enable SSL/TLS = No => ST: Enable PeSIT over Plain SocketCG: TCP + Enable SSL/TLS = Yes => ST: Enable PeSIT over Secured SocketCG: pTCP + Enable SSL/TLS = No => ST: Enable PeSIT over pTCP Plain SocketCG: pTCP + Enable SSL/TLS = Yes => ST: Enable PeSIT over pTCP Secured Socket

TCP | pTCP According to whether SSL is activated and according to the network protocol.

PeSIT login N/A in the static configuration Text, maximum 24 characters

Password N/A in the static configuration Text, maximum 8 characters

Represents the PeSIT password corresponding to the PeSIT login used in flows when SecureTransport acts as PeSIT server.

Enable SSL/TLS

Operations > Server control > PeSIT Server > Enable PeSIT over TCP/pTCP over secured socket.

Yes | No


Access > Secure Socket Layer > Client Certificate Authentication > PeSITCG: Yes - ST: MandatoryCG: No - ST: DisabledCG: Optional - ST: Optional

Yes | No | Optional

Private certificate

Operations > Server control > PeSIT Server > Enable PeSIT over <TCP/pTCP> Secure Socket > SSL Key Alias

Use existing private certificate | Upload new private certificate




Comment


Operations > Server control > PeSIT Server > Enable FIPS Transfer Mode

Yes | No If checked, it applies for all PeSIT servers enabled and started.

SFTP



Comment

Protocol Operations > Server control > SSH Server > Enable Secure File Transfer Protocol (SFTP)

SFTP SSH server corresponding to the Central Governance server communication profiles are enabled and started on SecureTransport.

Port Operations > Server control > SSH Server > Enable Secure File Transfer Protocol (SFTP)

[1..65535]


Access > Secure Socket Layer > Client Certificate Authentication > SSHCG: Public key - ST: MandatoryCG: Password - ST: DisabledCG: Password or Public key - ST: Optional

Public key (default) | Password | Password or Public key

Server encryption

Operations > Server control > SSH Server > Enable Secure File Transfer Protocol > SSL Key Alias



Operations > Server control > SSH Server > Enable FIPS Transfer Mode

Yes | No


FTP



Comment

Protocol Operations > Server control > FTP Server > Enable PeSIT over <Secure/Plain>

FTP FTP servers corresponding to the Central Governance server communication profiles are enabled and started on SecureTransport.

Port Operations > Server control > FTP Server > Enable FTP over <Secure/Plain> Socket > Port

[1..65535]

Passive port range

Setup > FTP Settings > FTP Passive ModeCG: From – ST: Base Port CG: To – ST: Port End ST: Number of Ports = (To - From + 1)

From / To: [1024..65535]From must be lower than To

Enable SSL/TLS

Operations > Server control > PeSIT Server > Enable FTP over secured socket

Yes | No


Access > Secure Socket Layer > Client Certificate Authentication > FTPSCG: Yes - ST: MandatoryCG: No - ST: DisabledCG: Optional - ST: Optional

Yes | No | Optional

Private certificate

Operations > Server control > PeSIT Server > Enable PeSIT over <TCP/pTCP> Secure Socket > SSL Key Alias



Operations > Server control > PeSIT Server > Enable FIPS Transfer Mode

Yes | No If checked, it applies for all FTP servers enabled and started.


SecureTransport SFTP, FTP, HTTP flow definitionThe following tables describe the fields and parameters available in flow definition in SecureTransport when it is used as a relay via SFTP, FTP or HTTP in Central Governance.

SecureTransport step definition mappingThe following tables describe fields in Central Governance and SecureTransport for received and send properties.

Receive properties: sender pushes files

Central Governance section


SecureTransport field

Comment

File properties

Directory Subscription > Subscription folder

The directory represents the path where the sender is able to push files on SecureTransport. If in the same account there is another subscription (created outside Central Governance) with the same folder, the flow deployment will fail. You must review the Directory value.

Post-reception actions

On failure Subscription > Post Transmission Settings > On failure

Actions are applied to files that failed to arrive to the directory set before.

Receive properties: SecureTransport pulls files from the sender



SecureTransport field Comment

File properties

Remote directory Transfer Site > Download folder

Represents the folder on the sender from where SecureTransport pulls files.

File properties

File filterOptions: File Globbing/ Regular Expression

Download patternFile Globbing/ Regular Expression

Represents the filter on files SecureTransport pulls from the remote directory.






File properties

Directory Subscription > Subscription folder

The directory represents where SecureTransport saves files pulled from the sender.

File properties

Scheduler Subscription > For Files Received from this Account or its Partners > Schedule

Used to set a schedule for automatic retrieval of files from the sender.If the start date of the scheduler is earlier than the SecureTransport system data at deployment time, the flow deployment on SecureTransport fails.



Actions are applied to files that failed to arrive to the directory set before.

File processing properties




Common fields Description Not deployed on SecureTransport

File filter set to File globbing with no value

Name filter: Process all files

File filter=File globbing/Regular expression with a filter_value

Name filter: Process files based on a file name pattern

Pattern type: File Globbing/Regular expression

File name pattern: filter_value

Compression Algorithm Compression algorithm

Level Compression level Displays when algorithm is a zip, jar, or gzip.

Use archive password Password for protected file Displays when algorithm is a zip file.

Archives: Single/Multiple Compress all files into a single archive

Present when algorithm is zip, jar or tar






Archive name Output file names

Decompression Use archive password Password for protected file

Rename file as Output file names

PGP Encryption

Operations PGP Settings Choose whether to encrypt, sign, or both.

Encryption key with PGP public key

Encryption Settings:

Select an Account= current account name

Encrypt Using PGP Key: public certificate name

Certificate is uploaded in Account > certificates > public certificates

l Select a previously uploaded encryption key (used in another flow) for the same SecureTransport/receiver pair.

l Upload a new encryption key.

Signing key with PGP private key

Signature settings:

Select an Account = current account name

Sign using PGP key: private certificate name

Certificate is uploaded in Account > certificates > private certificates

Compression Compression settings: Type

Compression level Compression settings: Level

Encode using ASCII anchor

Encode Using ASCII Armor


PGP Decryption

Decrypt: Always Require Encryption: Enabled






Decrypt: Only if Encrypted or None

Require Encryption: Disabled

l Use Only if Encrypted to deploy a new decryption key on the SecureTransport.

l Use None if you do not want to deploy a new decryption key on SecureTransport.

Decryption key with PGP private key


l Select a previously uploaded decryption key (used in another flow) for the same sender /SecureTransport pair.

l Upload a new decryption key.

Verify file signature: Always

Require Trusted signature: Enabled

Verify file signature: Only if signed or None


l Use Only if Encrypted to deploy a new verification key on the SecureTransport .

l Use None if you do not want to deploy a new verification key on SecureTransport.

Verification key + PGP public key


l Select a verification key that was previously uploaded in another flow for the same sender /SecureTransport pair.

l Upload a new verification key.


Encoding conversion

Source encoding File encoding: Source file encoding

Target encoding File encoding: Output file encoding


Line ending Source: End of Record Character

Source file settings: Line Ending format

Source: Encoding Source file settings: File Encoding

Target: End of Record Character

Target file settings: Line Ending format






Target: Encoding Target file settings: File Encoding


Line folding Fold width Line folding: Line fold width




Line truncating Truncate length Line truncating: Truncate length




Line padding Line length Line padding: Predefined line length

Padding character Line padding: Line padding character

Padding character is a valid Unicode escape sequence.




Character replacement

Find lines with Find/Replace: Find






Delete found lines Strip lines starting with start string

Replace with Find/Replace: Replace




External script Filename Script settings: External Script Path

Absolute path to an external script.

Redirect output to Server log

Log script’s standard output to Server log

Send properties: SecureTransport pushes files to receiver




File properties

Remote directory Route Package > Route for receiver > Transfer settings > Step: Send to partner > Overwrite upload folder

Represents the folder on the receiver where SecureTransport pushes files.

File properties

File name sent Route Package > Route for receiver > Step: Send to partner > Transfer settings > Route file as

Rename files to be routed to the receiver.

File properties

File filter:Options: File Globbing/Regular Expression

Route Package > Route for receiver > Step: Send to partner > File filter

If set, represents the filter on files SecureTransport pushes to the remote directory.






Archive files On failure: Default/Enabled/Disabled

Route Package > Route for receiver > Step: Send to partner > Post routing actions >Archive files on failure

The Central Governance setting is deployed on SecureTransport even if archiving is not enabled globally. It has an effect when the global archiving policy is enabled on SecureTransport.

Archive files On success: Default/Enabled/Disabled

Route Package > Route for receiver > Step: Send to partner > Post routing actions >Archive files on success

The Central Governance setting is deployed on SecureTransport even if archiving is not enabled globally. It has an effect when global archiving policy is enabled on SecureTransport.

Post-sending actions

On failure Subscription > Post Processing Settings > On failure

Actions are applied to files that failed to be sent to the receiver.


On success Subscription > Post Processing Settings > On success

Actions are applied to files that were sent successfully to the receiver.

Send properties: receiver pulls files




Transfer properties

File exists Route Package > Route for receiver > Transfer settings > Step: Publish to account > Target settings: Collision settingsCancel(Default) > Fail operationOverwrite > Replace existing fileRename existing file > Rename existing fileRename transferred file > Use a different file name to publish the fileAppend > Append to existing file

This field is used in detecting duplicate transfers on the remote directory.






File properties

Remote directory Route Package > Route for receiver > Transfer settings > Step: Publish to account > Target settings > Folder

The directory represents the path where SecureTransport publishes files to the receiver.

File properties

Publish file as Route Package > Route for receiver > Transfer settings > Step: Publish to account > Target settings > Publish file as

Represents the name of the published file.

File properties

File filter: Options: File Globbing/Regular Expression

Route Package > Route for receiver > Step: Publish to partner > File filter

If set, represents the filter on files SecureTransport publishes to partner.



Actions are applied to files that failed to be pulled by the receiver.



Actions are applied to files that were pulled successfully by the receiver.

Post-download actions

On success Subscription > Post Client Download Actions > On success

Actions are applied to each file downloaded from the directory where SecureTransport received files from the sender.

Central Governance updates to SecureTransport objectsThe following tables describe whether objects deployed on SecureTransport have updates available from Central Governance for transfers.

Account definitionThe account represents a part of the flow that communicates directly with the SecureTransport relay: the sender that sends files to SecureTransport or the receiver that pulls files from SecureTransport.

The account is created on SecureTransport when:

l The sender pushes files to SecureTransport over SFTP, FTP or HTTP or SecureTransport pulls files from sender.

l The receiver pulls files from SecureTransport.



Field Central Governance deployed value Update from Central Governance

Name If the account represents a part of the flow that acts as a client (push files to SecureTransport or pulls files from SecureTransport): client login. The value is taken from the protocol definition between SecureTransport and client. When SecureTransport pulls files from the sender, the account name is the name of the sender.

Yes

Email contact Taken from the contact information of the part of the flow. Yes

Phone contact Taken from the contact information of the part of the flow. Yes

Account Type: Unspecified. No

Business unit: CentralGovernanceBusinessUnit. Yes

Routing Mode Ignore. Yes

Encrypt Mode Unspecified. No

UID Taken from SecureTransport settings: Setup > Central Governance > UID. No

GID Taken from SecureTransport settings: Setup > Central Governance > GID. No

Home Folder Taken from SecureTransport settings: Setup > Central Governance > Account Home Folder Prefix.

No

Home Folder Access Level

Business Unit. No

Notes N/A No

Adhoc Settings: Delivery Method

Disabled. No

Allow this account to login to SecureTransport Server

Is enabled only if the sender or receiver is an SFTP client for SecureTransport. Yes

Login Name The name of the account.




Allow this account to login by email

No. No

Allow this account to submit transfers using the Transfers RESTful API

No. No

Password is stored locally (not in external directory)

Yes. No

Password If SecureTransport acts as server and the client authenticates via login and password: taken from the client communication profile from the protocol definition.

No*

Require user to change password on next login

Taken from SecureTransport settings: Setup > Central Governance > Expire password on account creation.

No

Require user to change password every X days

No. No

Lock account after y failed login attempts

Taken from SecureTransport settings: Setup > Central Governance > Failed login attempts before account is locked.

No

* The certificate is updated if needed.

Transfer site definitionsSee:

l SFTP transfer site definition on page 617

l FTP transfer site definition on page 620

l HTTP transfer site definition on page 623


SubscriptionThe subscription is always created in the sender account. It is created starting from the CentralGovernanceApplication.


Subscription folder SecureTransport Step, Receive properties, Directory. Yes

Automatically Retrieve Files From

Yes when SecureTransport pulls files from the sender. Otherwise No.

Yes

Automatically Retrieve Files From Transfer Site

The transfer site created for the sender only when SecureTransport pulls files from the sender.

Yes

Schedule SecureTransport Step, Receive properties, Scheduler. Yes

Transfer profile <empty> Yes

Post Transmission Settings

On Temporary Failure Delete. No

On Failure SecureTransport Step, Receive properties, Post-reception actions, On failure.

Yes

Routing Options Trigger Settings

Trigger processing of files based on condition

No. No

Submit for processing All files in the subscription folder. No

Post Processing Settings

On Failure SecureTransport Step, Send properties, Post-sending actions, On failure.

Yes

On Success SecureTransport Step, Send properties, Post-sending actions, On failure.

Yes

Post Client Download Actions SecureTransport Step, Send properties, Post-download actions, On failure.

Yes

Route packageThe route package is always created in the sender account. It is created starting from the CentralGovernanceRouteTemplate. It contains information about how SecureTransport routes files received from senders to receivers.


Name <flow name> Yes

Description Managed by Central Governance. Changing it can corrupt already deployed Central Governance flows.

Yes

Subscriptions Link the subscriptions generated for each receiver. Yes

Inherited Settings Not set. No

Specific Settings

Execution Rule All Matching Routes. No

Routes See Route on page 614. Yes

Notifications

Notify following e-mails on route failure

Disabled. Yes

Notify following e-mails on route success

Disabled. Yes

RouteA route in the route package corresponding to the flow is managed for each receiver.


Name <sender name>-<receiver name> Yes


Yes

Condition SecureTransport Step, File processing, Condition. If the user does not set a value in Central Governance, the value deployed on SecureTransport is Always.

No

Notifications


Disabled. Yes


Disabled. Yes

Step: Send to Partner

Managed only when the direction between SecureTransport and the receiver is sender pushes files.

Yes

File filter SecureTransport Step, Send properties, File filter. Yes

Proceed with route execution on step failure

N/A ( SecureTransport default value: Yes) No

Transfer Settings

Select an account If SecureTransport pushes files to the receiver over SFTP, FTP or HTTP, option is Use current account.Else (SecureTransport pushes files over PeSIT), option is Specify an account name; Account is <Receiver account>.

Yes

Account Transfer Site The transfer site generated for the receiver. Yes

Transfer Profile Available only if the protocol between SecureTransport and receiver is PeSIT. The value is the transfer profile generated for the receiver

Yes

Configure advanced PeSIT settings

Enabled only if the protocol between SecureTransport and receiver is PeSIT. Yes

Overwrite upload folder

SecureTransport Step, Send properties, File properties, Remote folder. Yes

Route file as SecureTransport Step, Send properties, File properties, Sent file as. Yes

Send trigger file N/A (SecureTransport default value: No). No



Max number of parrallel transfers:

N/A (SecureTransport default value: 4). No

Retry Settings N/A (SecureTransport default value: 5). No

Max number of retries:


Sleep between retries(in ms):


Sleep increment between retries(in ms)

N/A No

Post Routing Action N/A (SecureTransport default value: No) No

Step: Publish to partner

Managed only when the direction between SecureTransport and the receiver is receiver pulls files.

Yes

File filter SecureTransport Step, Send properties, File filter. Yes


N/A (SecureTransport default value: Yes). No

Target Settings

Account Receiver account. generated

Folder SecureTransport Step, Send properties, File properties, Remote folder. Yes

Publish File as SecureTransport Step, Send properties, File properties, Publish File as. Yes

Collision settings SecureTransport Step, Send properties, Transfer properties, File exists. Yes

SSH keysWhen SecureTransport relay acts as a client, pushing files to the receiver or pulling files from the sender, and it must authenticate via login and SSH key , you define in the flow definition the SSH key SecureTransport uses for authentication.


l When SecureTransport pushes files to a receiver, the SSH key is imported in the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and the receiver. Transfer site with name is <flowname><receiver name>.

l When SecureTransport pulls files from a sender, the SSH key is imported in the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and the sender. Transfer site with name is <flowname><sender name>.

When SecureTransport relay acts as a server — sender pushes files to SecureTransport or receiver pulls files from SecureTransport — Central Governance does not deploy the SSH key. It is defined in the server communication profile, and SecureTransport already manages it. SecureTransport must have the client public key, which is imported in the in Login Certificates on the account created for the client:

l When sender pushes files to SecureTransport, the public key of the sender is imported in the sender account.

l When receiver pulls files from SecureTransport, the public key of the receiver is imported in the receiver account.

SFTP transfer site definitionThe SFTP transfer site is created in SecureTransport when it acts as an SFTP client in the flow. When SecureTransport pulls files from the sender or pushes files to the receiver, the transfer site is created in the sender account.


Name When SecureTransport pulls files from sender: <flow name><sender name>.When SecureTransport pushes files to receiver: <flow name><receiver name>.

Yes

Site type Not set (default value : Unspecified). No

Access Level:

Business Unit. No

Transfer Protocol

SFTP. No

Site settings

Server When SecureTransport pulls files from the sender, the server host is taken from the protocol definition between the sender and SecureTransport. When SecureTransport pushes files to the receiver, the server host is taken from the protocol definition between SecureTransport and the receiver.

Yes



Port When SecureTransport pulls files from sender, the server port is taken from the protocol definition between the sender and SecureTransport.When SecureTransport pushes files to receiver, the server port is taken from the protocol definition between SecureTransport and the receiver.

Yes

Network Zone

Taken from the protocol definition in the communication profile of SecureTransport.

Yes

Download folder

When SecureTransport pushes files to receiver, taken from SecureTransport step, Send properties: Remote folder. Otherwise not set.

No

Download Pattern Type

When SecureTransport pulls files from sender, taken from SecureTransport step, Send properties: File filter. Otherwise not set.

Yes

Download pattern


Yes

Upload folder

When SecureTransport pushes files to receiver, taken from SecureTransport step, Receive properties: Remote folder. Otherwise not set.

Yes

Allow overwrite

Yes. Yes

Transfer Settings

Transfer Mode

When SecureTransport pulls files from sender, transfer mode taken from the protocol definition between the sender and SecureTransport.When ST pushes files to receiver, transfer mode taken from the protocol definition between SecureTransport and the receiver.

Yes

Verify Fingerprint for this Site

Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server.

Yes

Fingerprint Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server.

Yes




Enable FIPS Transfer Mode


Yes

Site Login Credentials

User Name Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server.

Yes

Password Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server.

Yes

Use Password

Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: Yes if SecureTransport must use a password as SFTP client, otherwise No.

Yes

SSH Keys Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: If SecureTransport must use an SSH key to connect to the SFTP server, the keys is imported in private certificates in the account and is selected in this field. Otherwise the field is empty.

Yes

Network Settings

Connection Read/Write timeout:*

N/A No

Connection Read/Write Buffer Size:*

N/A No

Post Transmission Settings Send Options

Send file as N/A No

On Temporary Failure

N/A No


On Failure N/A No

On success N/A No

Post Transmission Settings Receive Options

Receive file as

N/A No

On Failure N/A No

On success SecureTransport Step, Receive properties, Post-reception actions, On success Yes

FTP transfer site definitionThe FTP transfer site is created in SecureTransport when it acts as an FTP client in the flow. When SecureTransport pulls files from the sender or pushes files to the receiver, the transfer site is created in the sender account


Name When SecureTransport pulls files from sender: <flow name><sender name>.

When SecureTransport pushes files to receiver: <flow name><receiver name>.

Yes


Access Level

Business Unit. No

Transfer Protocol

FTP(S) No

Site settings

Server When SecureTransport pulls files from the sender, the server host is taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to the receiver, the server host is taken from the protocol definition between SecureTransport and the receiver.

Yes



Port When SecureTransport pulls files from sender, the server port is taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to receiver, the server port is taken from the protocol definition between SecureTransport and the receiver.

Yes

Enable Active connection mode

Taken from sender’s server communication profile, connection mode. Yes

Network Zone


Yes

Download folder


No



Yes

Download pattern


Yes

Upload folder


Yes

Allow overwrite

Yes. Yes

Transfer settings

Transfer Mode

When SecureTransport pulls files from sender, transfer mode taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to receiver, transfer mode taken from the protocol definition between SecureTransport and the receiver.

Yes

Transcode any line terminators in ASCII mode

Not set from Central Governance. No




Use FTPS Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server. If between SecureTransport and sender: SSL=None => disabled, otherwise=Yes.

Yes

Verify certificate for this Site

Taken from protocol definition between SecureTransport and partner: is SSL is required: enabled, else disabled. If in protocol between SecureTransport and sender: SSL = Mutual Authentication => enabled else , taken from SecureTransport client communication profile with the sender.

Yes

Clear Command Channel

Not set. No



Yes

Site command

Not set. No

Site login credentials


Yes


Yes

Use Password

Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: Yes if SecureTransport must use a password as client, otherwise No.

Yes

Certificate Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: If SecureTransport must use a certificate to connect to the server, the certificate is imported in private certificates in the account and is selected in this field. It is also added in the Trusted certificates of SecureTransport. Otherwise the field is empty.

Yes

Send options


Send file as N/A No


N/A No

On Failure N/A No

On success N/A No

Receive options

Receive file as

N/A No

On Failure N/A No


HTTP transfer site definitionThe HTTP transfer site is created in SecureTransport when it acts as an HTTP client in the flow. When SecureTransport pulls files from the sender or pushes files to the receiver, the transfer site is created in the sender account


Name When SecureTransport pulls files from sender: <flow name><sender name>.

When SecureTransport pushes files to receiver: <flow name><receiver name>.

Yes


Access Level:

Business Unit. No

Transfer Protocol

HTTP(S) No



Site settings

Specify partner using host name (IP address) and port number

Taken from the sender’s server communication profile: If in the sender's server communication profile: host, port => Enabled, else Disabled.

Server When SecureTransport pulls files from the sender, the server host is taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to the receiver, the server host is taken from the protocol definition between SecureTransport and the receiver.

Yes

Port When SecureTransport pulls files from sender, the server port is taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to receiver, the server port is taken from the protocol definition between SecureTransport and the receiver.

Yes

Specify partner using URL

Taken from the sender’s server communication profile: If in the sender's server communication profile: URL => Enabled, else Disabled.

URL When SecureTransport pulls files from the sender, the server URL is taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to the receiver, the server URL is taken from the protocol definition between SecureTransport and the receiver.

Network Zone


Yes

Download folder


No



Yes

Download pattern


Yes




Upload folder


Yes

Allow overwrite

Yes. Yes

Transfer settings

Transfer Mode

When SecureTransport pulls files from sender, transfer mode taken from the protocol definition between the sender and SecureTransport.

When SecureTransport pushes files to receiver, transfer mode taken from the protocol definition between SecureTransport and the receiver.

Yes

Use HTTPS Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server. If between SecureTransport and sender: SSL=None => disabled, otherwise=Yes.

Yes

Verify certificate for this Site

Taken from protocol definition between SecureTransport and partner: is SSL is required: enabled, else disabled. If in protocol between SecureTransport and sender SSL = Mutual Authentication => enabled else , taken from SecureTransport client communication profile with the sender.

Yes



Yes

Site command

Not set. No

Site login credentials


Yes


Yes

Use Password

Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: Yes if SecureTransport must use a password as a client, otherwise No.

Yes




Certificate Taken from the SecureTransport client communication profile protocol definition between SecureTransport and the server: If SecureTransport must use a certificate to connect to the server, the certificate is imported in private certificates in the account and is selected in this field. It is also added in the Trusted certificates of SecureTransport. Otherwise the field is empty.

Yes

Send options

Send file as N/A No


N/A No

On Failure N/A No

Receive options

Receive file as

N/A No

On failure N/A No




SecureTransport PeSIT flow definitionThe following tables describe the fields and parameters available in flow definition in SecureTransport when it is used as relay via PeSIT in Central Governance.

SecureTransport step definition mappingThe following tables describe fields in Central Governance and SecureTransport for receive and send properties.

Receive properties: PESIT, sender pushes files




File properties Receive file as Transfer profile > Receive File As

The field must be used to name the files received when files are transferred to SecureTransport.

File properties File type Transfer profile > Transfer Mode

Specifies the file type.

File properties Record type Transfer profile > Record Format


File properties Max record length

Transfer profile > Record Length

Specify the maximum length of the records in bytes.



Actions are applied to files that failed to arrive to the directory set previously.

Receive properties: PESIT, SecureTransport pulls files from the sender




File properties

Receive file as

Transfer profile > Receive File As

The field must be used to name the files received when files are transferred to SecureTransport.






File properties

Files to receive

Transfer profile > All files Specify if SecureTransport must pull all files available or only the first one.

File properties

File type Transfer profile > Transfer Mode


File properties

Record type Transfer profile > Record Format

Indicates whether the records in the file are fixed or variable in length.

File properties

Max record length

Transfer profile > Record Length


File properties

Scheduler Subscription > For Files Received from this Account or its Partners > Schedule

Used to set a schedule for automatic retrieval of files from the sender. If the scheduled start date is later than the Secure Transport system date, the flow fails to deploy on SecureTransport.



Actions are applied to files that failed to arrive to the directory set previously.

Send properties: PESIT, sender pushes files




File properties

File name sent Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Transfer profile > File label

The File label field is used to override the file label (PI37) predefined in the transfer profile.

File properties

Condition Route Package > Route for receiver > Condition

Specify a condition to route files to receiver.

File properties

File type Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Transfer profile > Transfer mode







File properties

Record type Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Transfer profile > Record format


File properties

Max record length Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Transfer profile > Record length


Default value = 2048

Archive files On failure: Default/Enabled/Disabled

Route Package > Route for receiver > Step: Send to partner > Post routing actions >Archive files on failure


On success: Default/Enabled/Disabled

Route Package > Route for receiver > Step: Send to partner > Post routing actions >Archive files on success




Actions are applied to files that failed to arrive to the directory where SecureTransport received the files from the sender after they were routed to a receiver.



Actions are applied to files that properly arrived to the directory where SecureTransport received the files from the sender after they were routed to a receiver.



Send properties: PESIT, receiver pulls files




Transfer properties

File exists Route Package > Route for receiver > Transfer settings > Step: Publish to account > Target settings : Collision settings

Cancel(Default) => Fail operation

Overwrite => Replace existing file

Rename existing file => Rename existing file

Rename transferred file => Use a different file name to publish the file

Append => Append to existing file

This field is used in detecting duplicate transfers on the remote directory.

Transfer properties

User message Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: User message

The User message field is used to override the predefined user message (PI99) in the PeSIT transfer site.

File properties

File name sent

Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: File label

The File label field is used to override the file label (PI37) predefined in the transfer profile.

File properties

Condition Route Package > Route for receiver > Condition

Specify a condition to route files to receiver.

File properties

File type Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Transfer mode


File properties

Record type Route Package > Route for receiver > Step: Send to partner > Configure advanced PeSIT settings: Record format


File properties

Max record length

Route Package > Route for receiver > Step: Send to partner-> Configure advanced PeSIT settings: Record length


Defualt value = 2048








Actions are applied to files that failed to arrive to the directory where SecureTransport received the files from the sender after they were routed to a receiver.



Actions are applied to files that properly arrived to the directory where SecureTransport received the files from the sender after they were routed to a receiver.

Post-download actions

On success Subscription > Post Client Download Actions > On success

Actions are applied to each file downloaded from the directory where SecureTransport received files from sender.

File processing properties




Common fields File filter set to File globbing with no value

Name filter: Process all files

File filter=File globbing/Regular expression with a filter_value

Name filter: Process files based on a file name pattern

Pattern type: File Globbing/Regular expression

File name pattern: filter_value

Compression Algorithm Compression algorithm

Level Compression level Displays when algorithm is a zip, jar, or gzip.

Use archive password Password for protected file Displays when algorithm is a zip file.

Archives: Single/Multiple Compress all files into a single archive

Present when algorithm is zip, jar or tar

Archive name Output file names






Decompression Use archive password Password for protected file


PGP Encryption

Operations PGP Settings Choose whether to encrypt, sign, or both.

Encryption key with PGP public key

Encryption Settings:

Select an Account= current account name

Encrypt Using PGP Key: public certificate name


l Select a previously uploaded encryption key (used in another flow) for the same SecureTransport/receiver pair.

l Upload a new encryption key.

Signing key with PGP private key

Signature settings:

Select an Account = current account name

Sign using PGP key: private certificate name


Compression Compression settings: Type

Compression level Compression settings: Level

Encode using ASCII anchor

Encode Using ASCII Armor


PGP Decryption

Decrypt: Always Require Encryption: Enabled

Decrypt: Only if Encrypted or None


l Use Only if Encrypted to deploy a new decryption key on the SecureTransport.

l Use None if you do not want to deploy a new decryption key on SecureTransport.






Decryption key with PGP private key


l Select a previously uploaded decryption key (used in another flow) for the same sender /SecureTransport pair.

l Upload a new decryption key.

Verify file signature: Always

Require Trusted signature: Enabled

Verify file signature: Only if signed or None


l Use Only if Encrypted to deploy a new verification key on the SecureTransport .

l Use None if you do not want to deploy a new verification key on SecureTransport.

Verification key + PGP public key


l Select a verification key that was previously uploaded in another flow for the same sender /SecureTransport pair.

l Upload a new verification key.


Encoding conversion




Line ending Source: End of Record Character

Source file settings: Line Ending format

Source: Encoding Source file settings: File Encoding

Target: End of Record Character

Target file settings: Line Ending format

Target: Encoding Target file settings: File Encoding







Line folding Fold width Line folding: Line fold width




Line truncating Truncate length Line truncating: Truncate length




Line padding Line length Line padding: Predefined line length

Padding character Line padding: Line padding character

Padding character is a valid Unicode escape sequence.




Character replacement

Find lines with Find/Replace: Find

Delete found lines Strip lines starting with start string

Replace with Find/Replace: Replace









External script Filename Script settings: External Script Path

Absolute path to an external script.

Redirect output to Server log

Log script’s standard output to Server log

Central Governance updates to SecureTransport objectsThe following tables describe whether objects deployed on SecureTransport have updates available from Central Governance for PeSIT transfers.

Account definition The account represents a part of the flow that communicates directly with the SecureTransport relay from:

l The sender that sends files to SecureTransport.

l The receiver that pulls files from SecureTransport.

Generally , the account is managed on SecureTransport when:

l The sender pushes files to SecureTransport or SecureTransport pulls files from sender.

l The receiver pulls files from SecureTransport.

In addition, for PeSIT the account is also managed when SecureTransport pushes files to receiver over PeSIT, or the sender pushes files to SecureTransport over PeSIT.

Field Deployed value from Central Governance Update from Central Governance

Name The SecureTransport identifier (PeSIT login). Yes

Email contact Taken from the contact information in the flow. Yes




Phone contact Taken from the contact information in the flow. Yes

Account type: Unspecified No

Business unit: CentralGovernanceBusinessUnit Yes

Routing Mode Ignore Yes

Encrypt Mode Unspecified No

UID Taken from SecureTransport settings: Setup > Central governance > UID No

GID Taken from SecureTransport settings: Setup > Central governance > GID No

Home Folder Taken from SecureTransport settings: Setup > Central governance > Account Home Folder Prefix

No

Home Folder Access Level

Business Unit No

Notes N/A No

Adhoc Settings: Delivery Method

Disabled No

Allow this account to log in to SecureTransport Server

Is enabled only if the sender or receiver is a client for SecureTransport. Yes

Login Name The name of the account

Allow this account to login by email

No No

Allow this account to submit transfers using the Transfers RESTful API

No No

Password is stored locally (not in external directory)

Yes No




Password If SecureTransport acts as a server and the client authenticates via the login and password, the value is taken from the client communication profile from the protocol definition.

If SecureTransport acts as a server and the client authenticates via the login and public key, the password is randomly generated strong enough. In this case the client key is imported in the account login certificates.

No. The certificate is updated if needed.

Require user to change password on next login

Taken from SecureTransport settings: Setup > Central governance > Expire password on account creation

No

Require user to change password every X days

No No

Lock account after Y failed login attempts

Taken from SecureTransport settings: Setup > Central governance > Failed login attempts before account is locked.

No

PESIT transfer site definition The PESIT transfer site is created on SecureTransport for all senders and receivers that send or receive data to or from SecureTransport via PeSIT.


Name The sender or receiver PeSIT identifier ( login) Yes

Site type Not set (default value : Unspecified) No

Access Level: Business Unit No

Transfer Protocol PeSIT No

Remote Partner Settings

Server Set only when SecureTransport partner acts as a client: Server port .

Taken from the communication profile of a partner (sender or receiver), from the protocol definition.

Yes




Port Set only when SecureTransport partner acts as a client: Server port

Taken from the communication profile of a partner (sender or receiver), from the protocol definition.

Yes

Network Zone Taken from the communication profile of SecureTransport from the protocol definition.

Yes

Transfer Settings

Compression Taken from the communication profile of a partner (sender or receiver), from the protocol definition.

Yes

Network Settings

Parallel TCP connections: If in Central Governance PeSIT protocol definition, the network protocol is pTCP, 10

Otherwise it is 10

Yes

USE TLS Taken from the communication profile of partner (sender or receiver), from the protocol definition.

Yes

Verify certificate for this Site If Mutual Authentication is Yes,

Otherwise it is taken from the communication profile of a partner (sender or receiver), from the protocol definition.

Enable FIPS Transfer Mode Taken from the communication profile of partner (sender or receiver) from the protocol definition

Enable Legacy Transfer CFT compatible SSL Mode

No No

PESIT transfer profile definitionThe PESIT transfer profile is created on SecureTransport for each PeSIT identifier configured between SecureTransport and partners over PeSIT (sender or receiver).


Sender pushes files to SecureTransport over PeSIT


Name The PeSIT identifier configured between the sender and SecureTransport

Yes

Files To Send N/A No

Receive File As

/<PeSIT identifier between sender and SecureTransport>/<the value from SecureTransport step, Receive properties, Receive file as>

Yes

Acknowledge transfer

Taken from the protocol definition between sender and SecureTransport Yes

File Label N/A No

All files SecureTransport step, Receive properties > Files to receive Yes

Transfer Mode

SecureTransport step, Receive properties > File type Yes

Record Format

SecureTransport step, Receive properties > Record type Yes

Record Length

SecureTransport step, Receive properties > Maximum record length Yes

SecureTransport pulls files from sender


Name The PeSIT identifier configured between the sender and SecureTransport Yes

Files To Send N/A No

Receive File As

/<PeSIT identifier between sender and SecureTransport>/{pesit.senderID}/<the value from SecureTransport step, Receive properties, Receive file as>

Yes


N/A Yes

File Label N/A No

All files SecureTransport step, Receive properties > Files to receive Yes

Transfer Mode

SecureTransport step, Receive properties > File type Yes

Record Format

SecureTransport step, Receive properties > Record type Yes

Record Length

SecureTransport step, Receive properties > Maximum record length Yes

SecureTransport pushes files to receiver


Name The PeSIT identifier configured between SecureTransport and receiver

Yes

Files To Send /<PeSIT identifier between sender and SecureTransport>/ * No

Receive File As N/A Yes


N/A Yes

File Label N/A * No

All files N/A Yes

Transfer Mode N/A * Yes

Record Format N/A * Yes

Record Length N/A * Yes

The PeSIT properties values are set in the Send to partner step that is defined in the route between original sender and receiver.

Receiver pulls from SecureTransport


Name The PeSIT identifier configured between SecureTransport and receiver Yes

Files To Send /<PeSIT identifier configured between SecureTransport>/ and receiver>/${pesit.receiverID}/*

No

Receive File As N/A Yes


N/A Yes

File Label SecureTransport step, Send properties > Files name sent No

All files SecureTransport step, Send properties > Files to send Yes

Transfer Mode SecureTransport step, Send properties > File type Yes

Record Format SecureTransport step, Send properties > Record type Yes

Record Length SecureTransport step, Send properties > Maximum record length Yes

SecureTransport general definitions in flows The following definitions apply in SecureTransport for all protocols.

SubscriptionThe subscription is always created in the sender account. It is created from the CentralGovernanceApplication.

Subscription folder If the protocol is PeSIT:

l If sender pushes files to SecureTransport: /<the PeSIT identifier between SecureTransport and sender>.

l If SecureTransport pulls files from sender: /<the PeSIT identifier between SecureTransport and sender>/<the sender PeSIT login>.

Otherwise, the value is from SecureTransport step, receive properties, directory.

Yes

Automatically Retrieve Files From

Yes when SecureTransport pulls files from sender, otherwise No Yes

Automatically Retrieve Files From Transfer Site

Only when SecureTransport pulls files from sender: The transfer site created for the sender.

Yes

Schedule SecureTransport Step, Receive properties, Scheduler Yes

Transfer profile If the protocol is PeSIT, the value is the transfer profile created for the files received from the sender.

Otherwise the value is <empty>

Yes

Post Transmission Settings

On Temporary Failure Delete No

On Failure SecureTransport Step, Receive properties, Post-reception actions, On failure

Yes

Routing options trigger settings

Trigger processing of files based on condition

No No

Submit for processing All files in the subscription folder No

Post-processing settings

On Failure SecureTransport Step, Send properties, Post-sending actions, On failure

Yes

On Success SecureTransport Step, Send properties, Post-sending actions, On failure

Yes

Route packageThe route package is always created in the sender account. It is created from the CentralGovernanceRouteTemplate. It contains information about how SecureTransport routes files received from senders to receivers. You create a route package for each receiver.


Name SFTP, FTP,HTTP: <flow name>

PeSIT: <PeSIT identifier set between sender and SecureTransport>

Yes


Yes

Subscriptions Link the subscriptions generated for each receiver Yes

Inherited Settings Not set No

Specific settings

Execution Rule All matching routes No

Routes See Route on page 643 table Yes

Notifications


Disabled Yes


Disabled Yes

RouteA route in the route package corresponding to the flow is managed for each receiver.

Name <sender name>-<receiver name>

When SecureTransport is the destination of a store-and-forward path, the sender name is original sender name, the initiator of the path. When SecureTransport is the initiator of a store-and-forward path, the receiver name is the final destination name.

Yes


Yes

Condition SecureTransport step, File properties, Condition. If PeSIT, the following is automatically added to the value set in flow definition:

When SecureTransport is the target of a store-and-forward path: ${(pesit.pi.originalsenderID.toUpperCase() eq '<original sender PeSIT login>')}

Else: ${(pesit.pi.senderID.toUpperCase() eq '<sender PeSIT login>')}

Yes

Notifications


Disabled Yes


Disabled Yes

Step: send to partner

Managed only when the direction between SecureTransport and the receiver is sender pushes files.

Yes

File filter SecureTransport Step, Send properties, File filter Yes


N/A ( SecureTransport default value: Yes) No

Transfer settings

Select an account

If SecureTransport pushes files to the existing receiver over SFTP, FTP or HTTP, the option is Use current account

Otherwise, (SecureTransport pushes files over PeSIT and the receiver account is different to the sender account), the option is Specify an account name where Account is the <Receiver account>.

Yes

Account Transfer Site

The transfer site generated for the receiver. Yes

Transfer Profile

Available only if the protocol between SecureTransport and receiver is PeSIT. The value is the transfer profile generated for the receiver.

Yes

Configure advanced PeSIT settings

Enabled only if the protocol between SecureTransport and receiver is PeSIT. Yes

Store and Forward mode

Start New Yes

Virtual File Name

N/A No

Data Encoding

SecureTransport Step, SEND Properties, File type Yes

Record Format

SecureTransport Step, SEND Properties, Record type Yes

Record Length

SecureTransport Step, SEND Properties, Max record length Yes

File Label SecureTransport Step, SEND Properties, File name sent Yes

Final Destination

When SecureTransport is the initiator of the store-and-forward path, the value is equal to the PeSIT login of the store-and-forward destination.

Yes

User Message

SecureTransport Step, SEND Properties, User message Yes

Overwrite upload folder

If the protocol is PeSIT between SecureTransport and the receiver, then the value is: /<flow id>/<receiver name>/*. Otherwise, the value is: SecureTransport Step, Send properties, File properties, Remote folder.

Yes

Route file as SecureTransport Step, Send properties, File properties, Sent file as Yes

Send trigger file

N/A (SecureTransport default value: No) No

Max number of parallel transfers:

N/A (SecureTransport default value: 4) No

Retry Settings


Max number of retries:


Sleep between retries(in ms):


Sleep increment between retries(in ms)

N/A No

Post Routing Action

N/A (SecureTransport default value: No) No

Step: Publish to partner

Managed only when the direction between SecureTransport and receiver is receiver pulls files.

Yes

File filter SecureTransport Step, Send properties, File filter Yes


N/A (SecureTransport default value: Yes) No

Target settings

Account Receiver account generated

Folder If PeSIT: /<The PeSIT identifier configured between the ST and receiver>/<receiver PeSIT login>/*

Otherwise: SecureTransport Step, Send properties, File properties, Remote folder

Yes

Publish File as

SecureTransport Step, Send properties, File properties, Publish File as Yes

Collision settings

SecureTransport Step, Send properties, Transfer properties, File exists Yes

Certificates used for authenticationWhen SecureTransport relay acts as a client, pushing files to a receiver or pulling files from the sender, and when it requires authentication via a certificate, you must define in the flow definition the certificate SecureTransport uses for authentication as the client.

When SecureTransport pushes files to a receiver, the certificate is imported in the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and the receiver (transfer site with name is <flow name><receiver name>).When SecureTransport pulls files from sender, the certificate is also imported in the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and sender (transfer site with name is <flow name><sender name>).

The root certificate is imported in the SecureTransport trusted certificates.

When SecureTransport relay acts as a server (sender pushes files to SecureTransport or receiver pulls files from SecureTransport), Central Governance does not deploy the certificate. It is defined in the server communication profile, and SecureTransport already manages it. SecureTransport must have the client certificate of the client and it is imported in Login Certificates on the account created for the client:

l When sender pushes files to SecureTransport, the certificate of the sender is imported in the sender account.

l When receiver pulls files from SecureTransport, the certificate of the receiver is imported in the receiver account.

Certificates used with FTP, HTTP, PeSITWhen SecureTransport relay acts as a FTP, HTTP or PeSIT client, pushing files to the receiver or pulling files from the sender, and it must authenticate via a certificate, you define in the flow definition the certificate SecureTransport uses for authentication.


When SecureTransport pushes files to a receiver, the certificate is imported to the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and the receiver.

When SecureTransport pulls files from a sender, the certificate is imported to the private certificates list of the sender account and selected in the transfer site managed for defining the connection between SecureTransport and the sender.

The SecureTransport certificate and the partner’s certificate are added to the list in SecureTransport of trusted certificates, if they are new certificates.

When SecureTransport relay acts as a server — sender pushes files to SecureTransport or receiver pulls files from SecureTransport — Central Governance does not deploy the certificate. The certificate is defined in the server communication profile, and SecureTransport already manages it. SecureTransport must have the client public certificate, which is imported to the Login Certificates on the account created for the client:

l When the sender pushes files to SecureTransport, the public certificate of the sender is imported to the sender account.

l When the receiver pulls files from SecureTransport, the public certificate of the receiver is imported to the receiver account.

l The certificate, from the partner’s client communication profiles, is added to the list in SecureTransport of trusted certificates, if new certificates.

l If the incoming flow is over edges, the certificate also is imported to the list in the edge of trusted certificates.

Folder monitoring when SecureTransport is source in flow

SecureTransport can be the source of the flow when it is linked with an application that is selected as source of the flow.

In this case, an account is managed on SecureTransport that has the name of the application used in the flow and it does not have permissions to log in to SecureTransport server (Allow this account to login to SecureTransport Server property is not enabled). A transfer site of type Folder Monitor is managed in this account with the definition of the download settings. A subscription on this account will automatically retrieves files from the directories configured in the Transfer Site of Folder Monitor type.

The Folder Monitor transfer site is created in SecureTransport when it acts as source in the flow. It is created in the account that represents the source application.







Access Level Business Unit. No

Transfer Protocol Folder Monitor. No

Download settings

Download Folder Taken from SecureTransport step, Receive properties, Folder Monitoring: Directory to scan

Yes

Download File Filter Taken from SecureTransport step, Receive properties, Folder Monitoring: File Filter

Yes

Download pattern Taken from SecureTransport step, Receive properties, Folder Monitoring: File Filter

Yes

Subfolder Monitoring, Do Not Monitor Subfolders

Taken from SecureTransport step, Receive properties, Folder Monitoring: Scan sub-directories = No

Yes

Subfolder Monitoring, Monitor All Subfolders

Taken from SecureTransport step, Receive properties, Folder Monitoring: Scan sub-directories = Yes, Directory depth=Unlimited

Yes

Subfolder Monitoring, Subfolder Monitoring, Monitor All Subfolders

Taken from SecureTransport step, Receive properties, Folder Monitoring: Scan sub-directories = Yes, Directory depth=Limited, Directories

Yes

Subfolder Monitoring, Download Subfolder Pattern Type

Taken from SecureTransport step, Receive properties, Folder Monitoring, Scan sub-directories = Yes, Sub-directory filter

Yes

Subfolder Monitoring, Download Subfolder Pattern

Taken from SecureTransport step, Receive properties, Folder Monitoring, Scan sub-directories = Yes, Sub-directory filter

Yes

Post Transmission Settings, Receive file as

Taken from SecureTransport step, Receive properties, File properties, Receive file as

Yes

Upload settings Not set when ST is source



Folder monitoring when SecureTransport is target in flow

SecureTransport can be the target of the flow when it is associated with an application selected as the target in the flow. The transfer site of type Folder Monitor is managed in the account for the sender of the file. A route between the sender and the application target configures the processing of the files and the routing to the destination directory.

The folder monitor transfer site is created in SecureTransport when it acts as target in the flow. It is created in the sender account.




Access Level Business Unit. No

Transfer Protocol Folder Monitor. No

Download settings Set when SecureTransport is target

Upload settings upload folder

Folder Taken from SecureTransport step, Send properties, Upload directory

Yes

Expression Language support for upload folder

Taken from SecureTransport step, Send properties, Use expression lamguage

Yes

Automatically create upload folder if it doesn't exist

Taken from SecureTransport step, Receive properties, Create directory if not existent

Yes

Allow overwrite Yes No

Post-transmission settings

Send file as Taken from SecureTransport step, Send properties, Upload file as

Yes

On Failure Taken from SecureTransport step, Send properties, On failure

Yes

On Success Taken from SecureTransport step, Send properties, On success

Yes


Appendix D: Flows deployed on SecureTransport

When SecureTransport is used as a relay in flows, the deployment of the flows on SecureTransport depends on:

l The protocol definition between SecureTransport and the sender or receiver.

l The flow properties defined on the SecureTransport relay step.

Objects created in SecureTransportThe following are the objects created in SecureTransport for sender and receiver when Central Governance deploys flows to it.

Account for the senderIf the sender must connect to SecureTransport, acting as a client pushing files to SecureTransport, the option Allow this account to login to SecureTransport Server is enabled.

The name of the sender account is generated according to the protocol definition between the sender and SecureTransport:

l If the protocol between source and SecureTransport is PeSIT, the name of the account is the PeSIT identifier that SecureTransport uses for the sender.

l If the protocol between source and SecureTransport is SFTP or FTP and the sender presents a login to authenticate, the name of the account is the login. Otherwise, it is the name of the sender.

Account for the receiverFor protocols SFTP, FTP and HTTP protocols, the account is created only if the receiver acts as a client and must connect to SecureTransport.

For the PeSIT protocol, the account always is created.

The name of the receiver account follows the same rules as for the sender account name. It is generated according to the protocol definition between SecureTransport and the receiver:

l If the protocol between source and SecureTransport is PeSIT, the name of the account is the PeSIT identifier that SecureTransport uses for the receiver.

l If the protocol between source and SecureTransport is SFTP or FTP and the receiver presents a login to authenticate, the name of the account is the login. Otherwise, it is the name of the receiver.


AppendixD: Flows deployed on SecureTransport

Objects deployed in sender accountThe following objects are deployed in the sender account.

Transfer sites l For all cases when SecureTransport must connect to the sender and pull files from the sender over SFTP, FTP and HTTP.

l For all the cases when SecureTransport must connect to the receiver and push files to the receiver over SFTP, FTP and HTTP.

l Always when PeSIT is the protocol between the sender and SecureTransport.

The name of the transfer site depends on the protocol definition between SecureTransport and the part of the flow for which the transfer site is created:

l For PeSIT, it represents the PeSIT identifier that the partner presents to SecureTransport.

l For SFTP, FTP and HTTP, it represents the <flow name value><partner name>.

For one flow there can be multiple transfer sites generated to the sender account. For example, sender pushes to SecureTransport via PeSIT and SecureTransport pushes to receiver via SFTP. In this case the sender account has one transfer site for the sender and one for the receiver.

Transfer profile l Only when PeSIT is the protocol between sender and SecureTransport.

l The name of the transfer profile is the PeSIT identifier configured in the protocol between sender and SecureTransport.

Subscription l Always created in the sender account. It allows the trigger of the transfers routing from sender to receiver.

l For SFTP, FTP and HTTP, the subscription folder is taken from the SecureTransport step flow definition between each sender and SecureTransport send properties.

l For PeSIT, the subscription folder is generated: /<PeSIT identifier of the flow>.

Route package l Always created in the sender account. It allows routing files received in the subscription folder from sender to receiver. A route package is created for each receiver defined in the flow.

l The name of the route package. For SFTP, FTP, HTTP: <flow name>. For PeSIT: <PeSIT identifier between sender and SecureTransport>.

l The subscription is linked to the route package.

l A route is created for the receiver for each route package created:

o The name of the route is <sender name><receiver name>.

o It contains steps according to the file processing defined in the SecureTransport step flow definition between SecureTransport and the receiver. The last step is Send to Partner, if SecureTransport pushes files to the receiver, or Publish to Account, if the receiver pulls files from SecureTransport. (Send to Partner and Publish to Account are types of steps defined in SecureTransport.)

Objects deployed in receiver account: Subscription l Central Governance creates a subscription in the receiver account when the receiver pulls files from SecureTransport.

l The subscription allows for triggering the post-download action on files successfully pulled by the receiver.

l For SFTP, FTP and HTTP, the subscription folder is taken from the SecureTransport step flow definition between each SecureTransport and receiver, send properties.

l For PeSIT, this subscription folder is generated: /<PeSIT identifier of the flow between ST

and receiver>/<the receiver PeSIT login>.

Deployed flow examples

Appendix E: Gateway corresponding fields

The following topics have tables that list and describe fields in Central Governance that correspond to fields in Gateway.


Server communication profilesThe following tables list and describe by protocol the fields in Central Governance for server communication profiles that correspond to fields in Gateway.

CG Gateway

CG field (Server communication profile)

Value Object type Attribute (UI/CMD)

Value Comment

PeSIT protocolName <Name> Network

ProfileNetwork profile name / sn_nprof_name

CG_<Name>_# where # is a sequence number starting with 1

TLS Security Profile (SERVER)

TLS Security Profile (SERVER) name / spn_sprof_name

CG_<Name>

Network zones Yes, No n/a n/a n/a

CG Gateway



Value Comment

Host ALL INTERFACES

PeSIT configuration entry

Gateway Interface empty

any other value in the list


Gateway Interface selected value

Port <port_value>


Gateway Port (if Network zones = No)

<port_value>


SecureRelay port (if Network zones = Yes)

<port_value>


Yes, No (default)

n/a n/a n/a

Public host <host_value>

n/a n/a n/a

Public port <port_value>

n/a n/a n/a

PeSIT login <login_value>

Local Site alias <login_value>

The Local Site is created only when deploying the flow that references this Server Communication Profile

Local Site proto_ident <login_value>

Password <pwd_value>

Remote Site login_password <pwd_value>

login_password is set in the Remote Site when deploying the flow that references this Server Communication Profile

Enable SSL/TLS Yes, No (default)

n/a n/a n/a


Yes (default), No, Optional



selected value

CG Gateway



Value Comment

Server encryption

Use existing private certificate

n/a n/a n/a

Upload existing private certificate

n/a n/a n/a

Private certificate <private certificate>


Select single certificate

<private certificate>

Certificate Name of certificate


All certificate are stored into a local database file

SFTP protocolName <Name> Network



SSH Profile SSH Security Profile (SERVER) / shp_name



Host ALL INTERFACES

SFTP configuration entry

CG Gateway



Value Comment




Port <port_value>



<port_value>



<port_value>


Yes, No (default)

n/a n/a n/a


n/a n/a n/a


n/a n/a n/a


Public key SSH Profile Client authentication methods / shp_client_auth_methods

'PUBLIC_KEY'

Password SSH Profile Client authentication methods / shp_client_auth_methods

'PASSWORD'


SSH Profile Client authentication methods / shp_client_auth_methods

'PASSWORD' 'PUBLIC_KEY'

Private key <file> Key n/a n/a All keys are stored into a local database file

CG Gateway



Value Comment

File password <password> Key n/a n/a

Private key alias <alias> Key Private key alias <alias>

SSH Security Profile

Private key alias / shp_private_key_alias

<alias>

FTP protocolName <Name> Network




TLS Security Profiles (SERVER)

TLS Security Profiles (SERVER) name / spn_sprof_name

CG_<Name>

Host ALL INTERFACES

FTP configuration entry





Port <port_value>



<port_value>



<port_value>

CG Gateway



Value Comment


Yes, No (default)

n/a n/a n/a


n/a n/a n/a


n/a n/a n/a

Limit passive port range

Yes, No (default)

n/a n/a n/a

From <port_value>


Listen port range in server passive mode: min

<port_value>

To <port_value>


Listen port range in server passive mode: max

<port_value>


n/a n/a n/a





selected value

Security mode Explict (default), Implicit


Connection security mode

selected value

Server encryption


n/a n/a n/a


n/a n/a n/a



Select single certificate /

CG Gateway



Value Comment




HTTP protocolName <Name> Network




TLS Security Profiles (SERVER)

TLS Security Profiles (SERVER) name / spn_sprof_name

CG_<Name>

Host ALL INTERFACES

HTTP configuration entry





Port <port_value>



<port_value>



<port_value>


Yes, No (default)

n/a n/a n/a


n/a n/a n/a

CG Gateway



Value Comment


n/a n/a n/a


n/a n/a n/a





selected value

Server encryption


n/a n/a n/a


n/a n/a n/a



Select single certificate / sp_certificate_name





Global parameter used for Cluster active/passive governed by Central Governance

Cluster virtual host

<virtual_host>

n/a n/a n/a Cluster virtual host is set at installation of a cluster.

PeSIT flow configurationThe following tables describe the fields in Central Governance for flows using PeSIT and the corresponding objects and attributes in Gateway.

CG Gateway

Section Field Value Object Object name

Attribute Value Comment

Incoming exchange between the Sender and the Relay

Protocol Exchange protocol

PeSIT Remote Site for the Sender

<sender_pesit_login>

Protocol PeSIT E A Remote site object is created for each sender

Protocol Direction Sender pushes file

Remote Site for the Sender


Role Initiator/Sender



Initialization mode

Initiating site

Receiver pulls file

n/a n/a n/a n/a Direction "Receiver pulls file" on the incoming exchange is not supported when Gateway is relay.

PeSIT details Flow identifier

<input_flow_id>

Application for the incoming exchange

<input_flow_id>

Name <input_flow_id>

An application object is created per each incoming flow id

Network protocol

any n/a n/a n/a n/a

SSL/TLS any n/a n/a n/a n/a

CG Gateway



<Sender_name>

Name (of the Client comm profile)

any n/a n/a n/a n/a Available only when have Partner as Source/Sender. For CFT a default client communication profile is being used.

PeSIT login <sender_pesit_login>



Alias <sender_pesit_login>



Protocol identifier


Password <sender_password>



(Connection) Password to receive from partner

<sender_password>

When the sender is a CFT / Application, check_password2? is set to the reversed name of the application


<any> n/a n/a n/a n/a

CG Gateway



Select public certificate

<public_certificate_alias>

Certificate

Name of the certificate



An object of type Certificate is created for the Partner. If the source/sender is CFT, then certificate is taken from the default client comm profile.

<Relay_name> / Server communication profile

Network zone

any n/a n/a n/a n/a This information is deployed on the sender, to set the physical location of the target

Host any n/a n/a n/a n/a

Port any n/a n/a n/a n/a

PeSIT login <relay_PeSIT_login>



Partner local alias

<relay_PeSIT_login>

Local Site

<relay_PeSIT_login>

Alias <relay_PeSIT_login>

Local Site

<relay_PeSIT_login>

Protocol identifier

<relay_PeSIT_login>

CG Gateway



Acknowledgement

Enable any n/a n/a n/a n/a Gateway will automatically route back to the sender the acknowledgement received from the receiver, regardless of this setting.

PeSIT properties

Compression

yes Application for the incoming exchange

<input_flow_id>

Compression

Both

no Application for the incoming exchange

<input_flow_id>

Compression

None

Gateway relay propertiesReceive properties / File properties

Organization

<selected_value>


<input_flow_id>

Transfer attributes/ Organization

<selected_value>

CG Gateway



Record format

<selected_value>


<input_flow_id>

Transfer attributes/ Record format

<selected_value>


<selected_value>


<input_flow_id>

Transfer attributes/ Record length

<selected_value>

Encoding <selected_value>


<input_flow_id>

Transfer attributes/ Data code

<selected_value>

Enable truncating

<selected_value>


<input_flow_id>

Transfer attributes/ Truncating allowed

<selected_value>

Receive properties / Post-reception actions

File availability

<selected_value>


<input_flow_id>

PeSIT E / Receiving a pre-existing file / File disponibility

<selected_value>

CG Gateway



File action <selected_value>


<input_flow_id>

PeSIT E / Receiving a pre-existing file / File action

<selected_value>

Local properties/ File properties

Directory <selected_value>


<input_flow_id>

Physical file attributes/ Reception/ Directory for received files

<selected_value>

Receive file as

<selected_value>


<input_flow_id>

Physical file attributes/ Reception/ Received file name

<selected_value>

Organization

<selected_value>

Application for the incoming and outgoing exchange

<input_flow_id> and <output_flow_id>

Physical file attributes/ Local file attributes/ Organization

<selected_value>

Record format

<selected_value>



Physical file attributes/ Local file attributes/ Record format

<selected_value>

CG Gateway




<selected_value>



Physical file attributes/ Local file attributes/ Record length

<selected_value>




Physical file attributes/ Local file attributes/ Data code

<selected_value>

Padding character

<selected_value>



Physical file attributes/ Local file attributes/ Padding character

<selected_value>

CG Gateway



Routing criteria originator alias, destination alias, remote agent, local agent, param1, param2, application, dir path, file component, file label, file name, originator, destination, file type, xfer ident, directory name, called address, called SAP, group, rcv user, rcv appli, rcv text, rcv msg

<string_value>

Exchmd (new object type)

<random_key>

md_exch_rule_N

<string_value>

New object data can be accessed in Gateway using the commands: select_exchmd display_exchmd

rec length, padding, block size, xfer rec length, yday

<numeric_value>


<random_key>

md_exch_rule_N

<string_value>

CG Gateway



protocol, type, direction, mode, file organization, rec format, data code, xfer rec format, xfer data code, newline convention, text file

<predefined_value>


<random_key>

md_exch_rule_N

<string_value>


The list of available options for these routing critera properties can be found on 'Routing criteria properties' files.

Send properties

Organization

<selected_value>

Application for the outgoing exchange

<output_flow_id>


<selected_value>

Record format

<selected_value>


<output_flow_id>


<selected_value>


<selected_value>


<output_flow_id>


<selected_value>

CG Gateway





<output_flow_id>


<selected_value>

Enable truncating

<selected_value>


<output_flow_id>


<selected_value>

Outgoing exchange (between the Relay and the Receiver)

Protocol = PeSIT, Direction = Sender pushes fileProtocol Exchange

protocolPeSIT Remote

Site for the Receiver

<receiver_pesit_login>

Protocol PeSIT E A Remote site object is created for the receiver

Direction Sender pushes file

Remote Site for the Receiver





Initialization mode

Initiating site

Receiver pulls file



Role Initiator/Receiver

CG Gateway





Initialization mode

Initiating site

PeSIt details Flow identifier

<output_flow_id>


<output_flow_id>

Name <output_flow_id>

An application object is created for the outgoing flow id

Network protocol

any n/a n/a n/a n/a


<Relay_name> / Client communication profile

Network zone

<selected_value>

n/a n/a n/a n/a Selecting the network zone that Gateway uses to access the receiver is not supported




Remote Site name

<relay_PeSIT_login>

Password <password>



(Connection phase) Password to send to partner

<password>



Select private certificate

<private_certificate_alias>

TLS Security Profile - CLIENT

Name of the Client Communication Profile

CG Gateway



Certificate




Uploaded or existing certificate. Certificate in imported in Gateway, if not already present

<Receiver_name>/ Server communication profile

Host <host_value>



Network address/ IP address or machine name

<host_value>

Port <port_value>



Network address/ Port number

<port_value>

PeSIT login <receiver_pesit_login>



Name <receiver_pesit_login>



(Pre-Connection) ID to receive from partner


Password <receiver_password>



(Pre-Connection) Password to receive from partner

<receiver_password>

Public certificate


Certificate



<public _certificate_alias>

CG Gateway



Acknowledgement


PeSIT properties

Compression


<input_flow_id>

Compression

Both


<input_flow_id>

Compression

None

Protocol = PeSIT, Direction = Receiver pulls fileProtocol Exchange

protocolPeSIT Remote



Protocol PeSIT E A Remote site object is created for the receiver

Direction Receiver pulls file

CG Gateway





Initialization mode

Initiating site

PeSIT details Flow identifier

<output_flow_id>


<output_flow_id>

Name <output_flow_id>

An application object is created for the outgoing flow id

Network protocol

any n/a n/a n/a n/a

SSL/TLS any n/a n/a n/a n/a CFT supports only mutual authentication


Network zone

<selected_value>

n/a n/a n/a n/a This information is deployed on the sender, to set the physical location of the target

Host <host_value>

n/a n/a n/a n/a

Port <port_value>

n/a n/a n/a n/a




Partner local alias

<PeSIT_login>

Local Site

<relay_PeSIT_login>

Alias <relay_PeSIT_login>

CG Gateway



Local Site

<relay_PeSIT_login>

Protocol identifier

<relay_PeSIT_login>

Password <password>



(Connection phase) Password to send to partner

<password>

Private certificate

<private_certificate>

n/a n/a n/a n/a

<Receiver_name>


any Applies only for Partner as Targer/Receiver. For CFT a default client comm profile is used.

PeSIT login <receiver_pesit_login>



Alias <receiver_pesit_login>

For CFT, the login is equal with the name of the CFT.

Protocol identifier





(Connection) Password to receive from partner

<receiver_password>

For CFT, the password is equal with the reversed CFT name.


<selected option>

n/a n/a n/a n/a Upload a new certificate or select an existing one

CG Gateway



Public certificate


Certificate


Certificate <public_certificate_alias>

Partner certificate. For CFT the default SSL certificate is being imported.

Acknowledgement


PeSIT properties

Compression


<input_flow_id>

Compression

Both


<input_flow_id>

Compression

None

SFTP flow configurationThe following tables describe the fields in Central Governance for flows using SFTP and the corresponding objects and attributes in Gateway.

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Incoming exchange between the Sender and the Relay


SFTP Remote Site for the Sender

<sender_sftp_login>

Protocol SFTP A Remote site object is created for each sender. At the end of the name have appended the protocol name: '_SFTP'



<sender_sftp_login>



<sender_sftp_login>

Initialization mode

Initiating site

Receiver pulls file

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

SFTP details Client authentication

any n/a n/a n/a n/a The Client authentication value is used to filter the communication profiles


any n/a n/a n/a n/a Gateway with FIPS mode is not supported.

<Sender_name>


any n/a n/a n/a n/a

Login <sender_sftp_login>


<sender_sftp_login>

Alias <sender_sftp_login>


<sender_sftp_login>

Remote site parameters to check / Username

<sender_sftp_login>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Public key <sender_pk_alias>

Key <sender_pk_alias>

Alias <sender_pk_alias>

The selected file is imported in Gateway as Key object, with the Alias indicated in CG, if not already exists. In Gateway, the imported file is stored into an internal format, specific to Gateway.



<sender_password>

Remote site parameters to check / Password

<sender_password>


Network zone

any n/a n/a n/a This information is deployed on the sender, to set the physical location and the authentication information of the relay

Host any n/a n/a n/a

Port any n/a n/a n/a

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

SFTP properties

Transfer mode n/a n/a n/a

Gateway relay propertiesReceive properties

Reception folder

any valid folder name

VFD for de Sender

\sftp\<sender_login>\

VFD for de Sender

\sftp\<sender_login>\<reception_folder>


Organization

<selected_value>


<generated sequence>


<selected_value>

Record format

<selected_value>




<selected_value>


<selected_value>




<selected_value>





<selected_value>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Padding character

<selected_value>




<selected_value>

Routing criteria

The same as for the Routing criteria in PeSIT flow configuration on page 664

Send properties

Remote Directory

<selected_value>




<selected_value>

Field applies if the Direction between the Relay and the Receiver is Sender pushes file

File name sent

<selected_value>




<selected_value>

Field applies if the Direction between the Relay and the Receiver is Sender pushes file

Directory <selected_value>




<selected_value>

Field applies if the Direction between the Relay and the Receiver is Receiver pulls file

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Publish file as

<selected_value>




<selected_value>

Field applies if the Direction between the Relay and the Receiver is Receiver pulls file

Organization

<selected_value>




<selected_value>

Record format

<selected_value>




<selected_value>


<selected_value>




<selected_value>





<selected_value>

Enable truncating

<selected_value>




<selected_value>

Line ending

<selected_value>


Newline convention

<selected_value>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Outgoing exchange between the Relay and the Receiver

Protocol = SFTP, Direction = Sender pushes fileProtocol Exchange

protocolSFTP Remote


<receiver_sftp_login>

Protocol SFTP A Remote site object is created for the receiver







Initialization mode

Initiating site


<client_auth_method>

Client SSH profile

<ccp_name> prefixed with CG_

Client authentication methods


The Client authentication value is also used to filter the communication profiles

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment


Name <ccp_name>

SSH Security Profile - CLIENT

<ccp_name> prefixed with CG_

Name <ccp_name>

Network zone

<selected_value>


Login <relay_SFTP_login>



Parameters to connect to Remote Site / User name

<relay_SFTP_login>

Local Site <receiver_sftp_login>

Alias <relay_SFTP_login>

Key pair <relay_pk_alias>

SSH Security Profile - CLIENT

<ccp_name>

Local authentication / Private key alias

<relay_pk_alias>

Field applies if the selected Client aunthenticatiopn method is Public key

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Key <relay_pk_alias>

Alias <relay_pk_alias>

The selected file is imported in Gateway as Key object, with the Alias indicated in CG, if not already exists. In Gateway, the imported file is stored into an internal format, specific to Gateway.

Password <relay_password>



Parameters to connect to Remote Site / Password

<relay_password>

Field applies if the selected Client aunthenticatiopn method is Password


Host <host_value>




<host_value>

Port <port_value>




<port_value>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Public key <receiver_pk_alias>

Key <receiver_pk_alias>

Alias <receiver_pk_alias>

The selected file is imported in Gateway as Key object, with the Alias indicated in CG. In Gateway, the imported file is no longer kepot. The key is transformed in an internal format specific to Gateway.

Protocol = SFTP, Direction = Receiver pulls fileProtocol Exchange

protocolSFTP Remote



Protocol SFTP A Remote site object is created for the receiver







Initialization mode

Initiating site

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment



n/a n/a n n/a The Client authentication value is used to filter the communication profiles




Name <ccp_name>

n/a n/a n n/a

Network zone

<selected_value>


Host <host_value>

n/a n/a n/a n/a

Port <port_value>

n/a n/a n/a n/a

<Receiver_name>/ Client communication profile

Name <ccp_name>

n/a n/a n/a n/a

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Login <receiver_SFTP_login>



Remote site parameters to check / User name

<relay_SFTP_login>

Key pair <receiver_pk_alias>

Key <receiver_pk_alias>

Alias <receiver_pk_alias>

The selected file is imported in Gateway as Key object, with the Alias indicated in CG, if not already present. In Gateway, the imported file is no longer kepot. The key is transformed in an internal format specific to Gateway.




Remote site parameters to check / Password

<receiver_password>

Field applies if the selected Client authentication method is Password

FTP flow configurationThe following tables describe the fields in Central Governance for flows using the FTP protocol and the corresponding objects and attributes in Gateway


Central Governance Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Incoming exchange between the Sender and the RelayProtocol Exchange

protocolFTP Remote Site

for the Sender

<sender_login>

Protocol FTP A Remote site object is created for each sender. At the end of the name have appended the protocol name: '_FTP' for non secured connections, '_FTPS' for secured connections.



<sender_login>



<sender_login>

Initialization mode

Initiating site

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Receiver pulls file


FTP details Connection mode

Active, Passive (default)


<sender_login>

Passive mode Active -> None Passive -> Initiator



Yes, No (default)

n/a n/a n/a n/a Gateway with FIPS mode is not supported.

Security mode

Explicit (default), Implicit

n/a n/a n/a n/a

<Sender_name>


any n/a n/a n/a n/a

Login <sender_login>


<sender_login>

Alias <sender_login>


<sender_login>

Id to check <sender_login>



<sender_login>

Password to check

<sender_password>

Section

Field

Value

Object

Object name

Attribute

Value

Comment




<public_certificate>

Certificate Name of the certificate

Certificate <public_certificate>

An object of type Certificate is imported/created for the Partner, if it does not already exists.


Yes (default), No

n/a n/a n/a n/a Option not used by Gateway


Network zone

any n/a n/a n/a n/a This information is deployed on the sender, to set the physical location of the target



Port range <port_value> - <port_value>

n/a n/a n/a n/a

Server encryption


n/a n/a n/a n/a

FTP properties

Transfer mode

any n/a n/a n/a n/a Not used by Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Gateway Relay propertiesReceive properties

Reception folder


VFD for de Sender

\ftp\<sender_login>\

VFD for de Sender

\ftp\<sender_login>\<reception_folder>


Organization

<selected_value>




<selected_value>





<selected_value>

Record format

<selected_value>




<selected_value>

Padding character

<selected_value>




<selected_value>


<selected_value>




<selected_value>

Routing criteria

The same Routing criteria as for PeSIT flow configuration on page 664

HTTP flow configurationThe following tables describe the fields in Central Governance for flows using HTTP and the corresponding objects and attributes in Gateway.


CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Incoming exchange between the Sender and the RelayProtocol Exchange

protocolHTTP Remote Site

for the Sender

<sender_login>

Protocol HTTP A Remote site object is created for each sender. At the end of the name have appended the protocol name: '_HTTP' for non secured connections, '_HTTPS' for secured connections.



<sender_login>



<sender_login>

Initialization mode

Initiating site

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Receiver pulls file


HTTP details Enable HTTP methods check

Yes, No n/a n/a n/a n/a

HTTP methods

PUT, GET, POST

n/a n/a n/a n/a With Gateway can not force to receive a specific HTTP method.



Yes, No (default)


<Sender_name>


any n/a n/a n/a n/a

Login <sender_login>


<sender_login>

Alias <sender_login>


<sender_login>

Id to check <sender_login>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment



<sender_login>

Password to check

<sender_password>






Certificate <public_certificate>

An object of type Certificate is imported/created for the Partner, if not already present.


Yes (default), No

n/a n/a n/a n/a Option not used by Gateway


Network zone

any n/a n/a n/a This information is deployed on the sender, to set the physical location of the target



HTTP properties

Transfer mode

any n/a n/a n/a n/a Not used by Gateway

Gateway Relay properties

Receive properties

Reception folder


VFD for de Sender

\http\<sender_login>\

VFD for de Sender

\http\<sender_login>\<reception_folder>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment


Organization

<selected_value>




<selected_value>





<selected_value>

Record format

<selected_value>




<selected_value>

Padding character

<selected_value>




<selected_value>


<selected_value>




<selected_value>

Routing criteria

Same as the Routing criteria for PeSIT flow configuration on page 664

Send properties / File properties

Remote directory

<selected_value>

Model CG_# where # is s a sequence number starting with 1

Directory name <selected_value>

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

File name sent

<selected_value>

Model CG_# where # is s a sequence number starting with 1

File name <selected_value>

Organization

<selected_value>


<input_flow_id>


<selected_value>

Record format

<selected_value>


<input_flow_id>


<selected_value>


<selected_value>


<input_flow_id>


<selected_value>



<input_flow_id>


<selected_value>

Enable truncating

<selected_value>


<input_flow_id>


<selected_value>

Identification method

Web (default), CGI, Cookies


<receiver_partner_name>

Identification method

<selected value>

Anonymous mode is not supported in CG.

Login path <string> Remote Site for the Sender


Login path <string> Available only if identification method is 'Cookies'

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

HTTP method

POST (default), GET



HTTP method <selected_value>

Available only if identification method is 'Cookies'

Login CGI parameters

<string> Remote Site for the Sender


Login CGI parameters

<string> Available only if identification method is 'Cookies'

Outgoing exchange between the Relay and the Receiver

Protocol = HTTP, Direction = Sender pushes fileProtocol Exchange

protocolFTP Remote Site

for the Receiver


Protocol FTP A Remote site object is created for the receiver







Initialization mode

Initiating site



HTTP methods

PUT, GET, POST

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment



Yes, No (default)



Network zone

<selected_value>


Login <relay_login>


<receiver_login>

Alias <relay_login>


<receiver_login>

Id to send <relay_login>

Password <password>


<receiver_password>

Password to send to partner

<password>



Select private certificate

Any TLS Security Profile - CLIENT

Name of the Client Communication Profile




Name of certificate


Certificate is imported in Gateway, if not already present.

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment


Yes, No n/a n/a n/a n/a Not supported by Gateway.


Host <host_value>


<receiver_login>


<host_value>

Port <port_value>


<receiver_login>


<port_value>

HTTP properties

Transfer mode

Any n/a n/a n/a n/a Not used by Gateway. In step properties have a similar field called 'Encoding'.

Protocol = HTTP, Direction = Receiver pulls fileProtocol Exchange

protocolHTTP Remote Site

for the Receiver

<receiver_login>

Protocol HTTP A Remote site object is created for the receiver



<receiver_login>



<receiver_login>

Initialization mode

Initiating site

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

HTTP methods

PUT, GET, POST




Yes, No (default)



Network zone

<selected_value>

n/a n/a n/a n/a Network zone is used to access Gateway.

Host <host_value>

n/a n/a n/a n/a

Port <port_value>

n/a n/a n/a n/a

<Receiver_name>


any n/a n/a n/a n/a

Login <receiver_login>


<receiver_login>

Alias <receiver_login>



<receiver_login>

Password to receive from partner

<receiver_password>


<selected option>

n/a n/a n/a n/a Upload a new certificate or select an existing one

CG Gateway

Section

Field

Value

Object

Object name

Attribute

Value

Comment

Public certificate



Certificate <selected_certificate>

Partner certificate

HTTP properties

Transfer mode

Any n/a n/a n/a n/a Not used by Gateway. In step properties there is a similar field called 'Encoding'.

Gateway exchmd and sgatemd objectsThe following tables describe the fields in Central Governance for flows using the Gateway exchmd and sgatemd objects for Central Governance, and the corresponding objects and attributes in Gateway.



Section

Field

Value

Object

Object name

Attribute

Value

Comment

exchmd (Gateway object for governance by Central Governance)

Section

Field

Value

Object

Object name

Attribute

Value

Comment

n/a n/a n/a Exchmd md_exch_key

Exchmd object key

<uniqueue_generated_value>

Exchmd objects are used to store data used for CG flows identification and to differentiate between CG and non-CG flows.


PeSIT, FTP, SFTP, HTTP

Exchmd md_exch_protocol

Protocol PHSE, FTP, HTTP or SFTP

Sender / Client Communication Profile

Login <login> Exchmd md_exch_login

Login <login>

n/a n/a n/a Exchmd md_exch_identity

Local identity <local site name>

Step configuration

Receive properties

Reception folder

Exchmd md_exch_location

Path for uploading files

<location> Only for FTP, HTTP and SFTP

n/a n/a n/a Exchmd md_exch_pattern

Not used n/a

n/a n/a n/a Exchmd md_exch_model

Model name (generated)

Model user to route the incoming payload

Flow details Flow name <flow name>

Exchmd md_exch_flowname

Flow name <flow name>

Protocol details (Source, Relay)

SSL/TLS any option Exchmd md_exch_secured

Security option Multual authentication, Client optional, None

n/a n/a n/a Exchmd md_exch_subjectdn

Not used n/a

Section

Field

Value

Object

Object name

Attribute

Value

Comment

n/a n/a n/a Exchmd md_exch_issuerdn

Not used n/a

n/a n/a n/a Exchmd md_exch_address

Not used n/a

Server Communication Profile

Port <port> Exchmd md_exch_service

Port <port>

Routing properties

Routing criteria parameter Exchmd md_exch_rule_#

Routing criteria #

<routing_rule_#>

# takes values starting with 1

sgatemd (object for governance by Central Governance)

n/a n/a n/a Sgatemd md_sgate_key

Sgatemd object key

<uniqueue_generated_value>

Sgatemd objects are used to store data used on SGate selection (for CG user authentication).


PeSIT, FTP, SFTP, HTTP

Sgatemd md_sgate_protocol

Protocol PHSE, FTP, HTTP or SFTP


Login <login> Sgatemd md_sgate_login

Login <login>

Server Communication Profile

Port <port> Sgatemd md_sgate_port

Port <port>

n/a n/a n/a Sgatemd md_sgate_service

Not used n/a

Section

Field

Value

Object

Object name

Attribute

Value

Comment


Password <password>

Sgatemd md_sgate_password

Partner password

<password>

n/a n/a n/a Sgatemd md_sgate_salt

Not used n/a

n/a n/a n/a Sgatemd md_sgate_sgate

Sgate object <sgate_name>

Appendix F: Objects created on Gateway

This topic describes the objects created on Gateway when Central Governance deploys configurations or flows to Gateway.

Some objects are created or modified on Gateway when Central Governance deploys configurations to a registered Gateway. All objects deployed on Gateway are prefixed with CG_.


Product registrationWhen Gateway is registered in Central Governance and PeSIT is active on it, a network profile object is created in Gateway for each PeSIT port defined in its static configuration. The network profile is named in the format:

CG_PeSIT_#

Where # is a sequence number.

Configuration updatesWhen Central Governance deploys a new configuration to Gateway, the objects created on Gateway depend on the protocol in the server communication profile.

Static configuration entryA configuration entry is created in Gateway when a server communication profile is created. This applies to PeSIT and SFTP.

KeyIf an SFTP server communication profile is created in Central Governance with a new key, on deployment the new key is imported in Gateway with the alias specified in the server communication profile. This applies only to SFTP.



SSH profileIf an SFTP server communication profile is created in Central Governance, an SSH profile object of type SERVER is created in Gateway. The name of the SSH profile object is the name of the server communication profile in Central Governance prefixed with CG_.

This SSH profile object refers the new key imported in Gateway. This applies only for SFTP.

Network profileWhen any new server communication profile is deployed from Central Governance to Gateway, a network profile object is created in Gateway. The name of the network profile object is the name of the server communication profile in Central Governance prefixed with CG_.

This network profile object refers the SSH profile object. This applies for PeSIT and SFTP.

Flows deployed on GatewayWhen Gateway is used as a relay in flows, the deployment of the flows on Gateway depends on:

l The protocol definition between Gateway and the sender or receiver.

l The direction of the exchange between Gateway and the receiver.

l The flow properties defined on the Gateway relay step.

The following objects are typically created when deploying a flow on Gateway.

Remote site for the senderThe sender always pushes files to Gateway, so a remote site of type Initiator/Sender is created for the sender on flow deployment.

The name of the remote site is given by the login declared in the sender’s client communication profile.

l If a remote site with the same name already exists in Gateway and if the various settings match, then that remote site is reused.

l If a remote site with the same name already exists in Gateway but the settings in the current flow do not match the settings of the remote site, then the deployment fails in error. For example, if the current deployment attempts to override the partner local alias of an existing PeSIT remote site, potentially involved in other flows, the deployment fails.



Remote site for the receiver l If the flow direction is Sender pushes file between Gateway (relay) and the receiver, then a remote site of type Responder/Receiver is created on flow deployment.

l If the flow direction is Receiver pulls file between Gateway (relay) and the receiver, then a remote site of type Initiator/Receiver is created on flow Gateway.

l If the protocol between Gateway and the receiver is PeSIT, then the name of the remote site is given by the PeSIT login field in the server communication selected for the receiver in the flow definition.

l If the protocol between Gateway and the receiver is SFTP and the receiver is a partner, then the name of the remote site is given by the name of the receiving partner.

l If a remote site with the same name already exists in Gateway but the settings in the current flow do not match with the settings of the remote site, then the deployment fails in error. For example, if the current deployment attempts to override the non-empty Host and Port settings of an existing remote site, potentially involved in other flows, the deployment fails.

Local site l A local site is created on Gateway upon flow deployment for every login it is supposed to present either as server or as client. For example, when Gateway acts as client in an exchange and the client communication profile selected in flow has the login MyLogin, a local site object is created on Gateway upon flow deployment, with the name MyLogin.

l When Gateway acts as server in an exchange and the server communication profile selected in flow has the login MyLogin, a local site object is created on Gateway upon flow deployment, with the name MyLogin.

Key l If Gateway acts as a client in an SFTP flow and a new key is uploaded with Gateway’s client communication profile, when the configuration is deployed, the new key is imported in Gateway with the alias specified in the client communication profile.

l This applies only for SFTP protocol.

SSH profile l If Gateway acts as a client in an SFTP flow, a SSH profile object of type CLIENT is created in Gateway. The name of the SSH profile object is the name of the client communication profile in Central Governance prefixed with CG_.

l This SSH profile object refers the new key imported in Gateway.




VFD l If Gateway acts as a server in an SFTP flow, typically you have to define either a reception folder or a folder for published files. When the flow is deployed, a corresponding VFD object (Virtual File Directory) is created on Gateway, with read/write/delete rights.


Application l For any flow deployed from CG, typically an application object is created on Gateway for any exchange in that flow, to specify the properties of the transferred file (either incoming or outgoing) and the local file’s properties.

l An application object contains both the properties of the transferred file and the information about how to store it locally on Gateway machine.

Depending on protocol, there are some slight differences in the way these objects are created:

For PeSIT flowsThe name of the application object is the flow ID of the corresponding flow exchange. For example, if PeSIT protocol is selected between the sender and the relay and the flow id on this exchange is MyFlowID, the application object created on Gateway is named MyFlowID.

For SFTP flows l The name of the application object is an automatically generated sequence of 10 digits prefixed with CG_. For example, the name of such application object could be: CG_0000000005.

l Application objects are not created in Gateway for the incoming SFTP exchange (when SFTP protocol is selected between the sender and relay).

Transfer model l For any flow deployed from Central Governance, one transfer model object is created in Gateway for each outgoing exchange. For example, when deploying a flow with one sender and three receivers, three transfer model objects will be created in Gateway.

l A transfer model object instructs Gateway what to do with the incoming file. At runtime, a decision mechanism within Gateway selects the transfer model object to apply for each incoming file.

l The name of each transfer model object is an automatically generated sequence of 10 digits prefixed with CG_.

l The parameters of the transfer model object depend on the protocol and the direction of the exchange.


Glossary

active-passiveIn an active-passive cluster failover configuration, one or more passive or standby nodes can take over for failed nodes. Normally, only the primary node is used for processing. When it fails, the standby node takes over the resources and the identity of the failed node. The services provided by the failed node are started on the standby node. After the switch, clients can access the services unaware that the services are being provided by a different node.

active modeIn FTP active mode, the client establishes the command channel, from client port X to server port 21, but the server establishes the data channel, from server port 20 to client port Y, where the client supplies Y. Also see passive mode.

advanced routingIn SecureTransport, advanced routing is an intelligent routing engine enabling flexible provisioning of new data flows, creating diverse patterns for moving data among parties.

AESThe Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.

alertAn event that occurs in the system, such as a product registration failure. An alert may require user intervention.

alert notificationMessage sent to recipients defined in an alert rule.

alert ruleA definition containing parameters and notification information. An alert rule is triggered when an alert occurs in the system.

APIAn application programming interface (API) is a protocol intended for use as an interface by software components to communicate with each other.

applicationThe logical definition of a business application that is the real endpoint of a file exchange.


Glossary

asynchronousAsynchronous communication is when data are sent intermittently rather than in a steady stream.

base DNThe top level of the LDAP directory tree is the base DN. DN stands for distinguished name.

BSONBSON, short for Bin-ary JSON, is a bin-ary-en-coded seri-al-iz-a-tion of JSON-like doc-u-ments. Like JSON, BSON sup-ports the em-bed-ding of doc-u-ments and ar-rays with-in oth-er doc-u-ments and ar-rays.

CAA certificate authority (CA) is a trusted third party that issues digital certificates for use by other parties.

certificateA digital certificate contains keys used for encrypting and signing messages, and also for decrypting and verifying signatures. A certificate can contain a public-private key pair or a public key only. See key.

CFTPARMAn object or command for general Transfer CFT environment parameters.

CFTPARTIn Transfer CFT, the CFTPART command describes each partner relative to the network/protocol environment by defining the Transfer CFT protocols, network identification, and intermediate partner identification.

CLICommand line interface (CLI) is a tool for performing actions on products and services.

client communication profilesClient communication profiles contain details for the sender or receiver to connect via a protocol to the server. The sender acts as client when it pushes files to the receiver. The receiver acts as a client when it pulls files from the sender.

cnxinMaximum number of sessions for incoming connections in Transfer CFT.

cnxinoutMaximum number of communication sessions in Transfer CFT.


Glossary

cnxoutMaximum number of sessions for outgoing connections in Transfer CFT.

command line interfaceCommand line interface (CLI) is a tool for performing actions on products and services.

communication profileA communication profile contains the technical details for making connections between clients and servers to transfer data. There are two types of communication profiles: client and server. The two types of profiles are based on the roles of senders and receivers in file transfers.

component security descriptor fileComponent security descriptor (CSD) files are XML files that define product resources, user privileges and user roles for each product that integrates with Central Governance for identity and access management.

core servicesCore services support the Central Governance graphical user interface, identity management and management of all functions related to product configuration and flow definition.

credentialInformation to verify a user's identity. For example: passwords, X.509 certificates.

CRLA certificate revocation list (CRL) is a list of X.509 certificates that have been revoked or are no longer valid and should not be relied upon.

CRONJOBIn Transfer CFT, a scheduled job defined within a script that executes a specified task at set dates and times.

CronjobsSee CRONJOB

CRONTABsIn Transfer CFT, a CRONTAB is a parameter that represents a file or list of files containing the scheduled jobs.

CSDComponent security descriptor (CSD) files are XML files that define product resources, user privileges and user roles for each product that integrates with Central Governance for identity and access management.


Glossary

CSRIn public key infrastructure, a certificate signing request (CSR) is a message sent from an applicant to a certificate authority to apply for a digital identity certificate.

DBAdatabase administrator

Dependency-CheckDependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Dependency-check can currently be used to scan Java applications and their dependent libraries to identify any known vulnerable components.

distribution listIn Transfer CFT, a distribution list manages the list of partners for distribution and collection operations. Use of a distribution list enables, with a single command, sending or receiving a file to all targets or sources in the list.

DMZA demilitarized zone (DMZ) or perimeter network is a physical or logical subnetwork that contains and exposes an organization's external-facing services to a larger and untrusted network, usually the Internet. A DMZ adds an additional layer of security to an organization's local area network (LAN). An external network node only has direct access to equipment in the DMZ, rather than any other part of the network.

DNSDomain Name System (DNS) is an Internet service that translates domain names into IP addresses. As the Internet is based on IP addresses, a DNS service must translate the name into the corresponding IP address.

DTDA document type definition (DTD) is a set of markup declarations that define a document type for an SGML-family markup language (SGML, XML, HTML).

EBCDICExtended Binary Coded Decimal Interchange Code (EBCDIC) is an 8-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems.

entityA password-protected repository of certificates and keys.


Glossary

expression languageSecureTransport uses an expression language (EL) based on the Sun JSP Expression Language. See the SecureTransport documentation for details. The following SecureTransport features can use EL: transfer site post-transmission actions, subscription post-transmission actions, PGP, account templates.

FGACFine-grained access control (FGAC) is a way to manage users' access to objects or capacity to perform actions. For example, you could enable some users to view specific objects in the user interface, but prohibit other users from viewing the same objects.

file-by-file modeWhen a group of files are transferred, the files are transmitted individually

FIPSFederal Information Processing Standards (FIPS) have been developed by the U.S. government. FIPS describes document processing, cryptographic algorithms and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with the agencies. Your user license for this software supports FIPS-compliant implementations of certain cryptographic algorithms or IAIK implementations of those algorithms. Also see IAIK in the glossary. For more information about FIPS, see http://www.itl.nist.gov/fipspubs/.

flowA flow specifies the technical details and communications protocols for exchanging business data between business applications or partners.

flowsA flow specifies the technical details and communications protocols for exchanging business data between business applications or partners.

FortifyFortify is Hewlett-Packard software for users to assess, assure and protect enterprise software and applications from security vulnerabilities.

FQDNfully qualified domain name

FTPFile Transfer Protocol (FTP) is a standard network protocol for transfering files from one host to another host over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and uses separate control and data connections between the client and the server.


Glossary

GFSGlobal File System (GFS) is a cluster file system that enables a cluster of computers to simultaneously use a block device that is shared between them. GFS reads and writes to the block device like a local file system, but also allows the computers to coordinate their I/O to maintain file system consistency. With GFS any changes that are made to the file system on one computer will immediately be seen on all other computers in that cluster.

GIDgroup ID

grouped transfer modeWhen a group of files is transferred, the files are transmitted as a group when possible.

groupsGroups enable you to organize and manage related products.

GUIgraphical user interface

HazelcastHazelcast is an in-memory open-source software data grid based on Java. By having multiple nodes form a cluster, data are distributed evenly among the nodes. This enables horizontal scaling for storage space and processing power. Backups are distributed similarly to other nodes, protecting against single-node failure.

HSMHardware security module

HSTSHTTP Strict Transport Security (HSTS) ensures browsers connect securely to the user interface. If a user includes http:// in the URL to connect, HSTS converts it to https://.

HTTPHypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to commands.

HTTPSHTTPS is a protocol for secure communication over a computer network widely used on the Internet. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a


Glossary

connection encrypted by Transport Layer Security or its predecessor, Secure Sockets Layer. HTTPS is also called HTTP over TLS, HTTP over and HTTP Secure.

IAIKThe Institute for Applied Information Processing and Communications (IAIK) researches information and computer security. This includes design and implementation of cryptographic algorithms and protocols in hardware and software, network security and trusted computing. Your user license for this software supports FIPS-compliant implementations of certain cryptographic algorithms or IAIK implementations of those algorithms. Also see FIPS in the glossary. For more information about IAIK see http://www.iaik.tugraz.at/.

IAMIdentity and access management (IAM) is a role-based solution for securing enterprise resources and managing user access to protected network components through a continuous and interactive authorization process.

IBM iIBM i is an EBCDIC-based operating system that runs on IBM Power Systems and on IBM PureSystems. The name, introduced in 2008, is the current evolution of the operating system. IBM i, formerly named i5/OS, originally was named OS/400 when introduced with the AS/400 computer system in 1988.

identity and access managementIdentity and access management (IAM) is a role-based solution for securing enterprise resources and managing user access to protected network components through a continuous and interactive authorization process.

identity storeA central repository for managing user identity information, such as roles, privileges and groups. There are two types: internal and external.

IDFAn IDF is a model file identifier, or file identifier, in Transfer CFT.

IPARTIn Transfer CFT, the IPART is the local identifier of an intermediate partner. The identifier must correspond to the ID parameter of a CFTPART object. This parameter is involved in the file store and forward or backup mechanism.

IPv4Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet, and was the


Glossary

first version deployed for production in the ARPANET in 1983. It still routes most Internet traffic today, despite the ongoing deployment of a successor protocol, IPv6.

IPv6Internet Protocol version 6 (IPv6) is a set of specifications from the Internet Engineering Task Force (IETF) that's essentially an upgrade of IP version 4 (IPv4).

ISOThe International Organization for Standardization sets standards in many businesses and technologies, including computing and communications.

JDBCJava database connectivity (JDBC) is an API for the Java programming language that defines how a client can access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.

JSONJavaScript Object Notation (JSON) is a text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for many languages.

keyKeys are contained in digital certificates. There are two kinds of keys: Private and public. A private key is your secret key for decrypting messages or signing messages. A public key is also your key, but it can be used by a partner to encrypt messages that only you can decipher with your private key.

LDAPLightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.

log4jLog4j, an open source project, allows the developer to control which log statements are output with arbitrary granularity. It is fully configurable at runtime using external configuration files.

MFTManaged file transfer (MFT) refers to software or a service that manages the secure transfer of data from one computer to another through a network or over the Internet.


Glossary

NessusNessus is an open-source network vulnerability scanner that uses the Common Vulnerabilities and Exposures architecture for easy cross-linking between compliant security tools. Nessus employs the Nessus Attack Scripting Language (NASL), a simple language that describes individual threats and potential attacks.

NFNAMEIn Transfer CFT, the name of the physical file at the receiver partner site.

NFSNetwork File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984. It allows a user on a client computer to access files over a network in a manner similar to how local storage is accessed.

notificationSee alert notification.

NTOSpiderNTOSpider, a dynamic application security scanner for testing web and mobile applications, identifies application vulnerabilities and site exposure risk.

OMAXTIMEIn Transfer CFT, the IMINTIME, IMAXTIME, OMINTIME and OMAXTIME parameters of the CFTPART command define the time slot for communicating with a partner for incoming and outgoing calls.

OMINTIMEIn Transfer CFT, the IMINTIME, IMAXTIME, OMINTIME and OMAXTIME parameters of the CFTPART command define the time slot for communicating with a partner for incoming and outgoing calls.

OS/400See IBM i

PARMA user parameter or parameter file in Transfer CFT.

partnerIn Transfer CFT a partner is a logical entity such as a bank, a government agency or trading partner, that can be the sender or receiver of data. A partner corresponds to a remote file-transfer controller.


Glossary

partnersPartners represent entities such as companies that send or receive business data in file transfers governed by Central Governance flows.

passive modeIn FTP passive mode, the client establishes the command channel and the data channel. The server tells the client which port to use for the data channel. Also see active mode.

password policyRules and conditions for valid passwords, such as character length, case requirements and validity periods.

pentestA penetration test, or pentest, is an attack on a computer system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data.

PeSITPeSIT is an open file transfer protocol often associated with Axway. PeSIT stands for Protocol d’Echanges pour un Systeme Interbancaire de Telecompensation. It was designed as a specialized replacement for FTP to support European interbank transactions in the mid-1980s.

PGPPretty Good Privacy (PGP) is a data encryption and decryption program for cryptographic privacy and authentication in data communication. PGP often is used for signing, encrypting, and decrypting texts, emails, files, directories and whole disk partitions, and to increase the security of email communications.

PI37The file label predefined in the transfer profile in SecureTransport.

PI99The predefined user message in the PeSIT transfer site in SecureTransport.

PKIPublic key infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.

privilegeA user right to perform an action on a resource.


Glossary

processing scriptIn Transfer CFT, a set of rules in a file for actions to execute on files transferred between Transfer CFTs. A processing script can be executed before a transfer (pre-processing script) or after a transfer (post-processing script).

productAxway business application software. For example, Transfer CFT.

productsAxway business application software. For example, Transfer CFT.

pTCPThe parallel Transmission Control Protocol (pTCP) is an end-to-end transport layer protocol that supports striped connections.

RACOracle Real Application Clusters (RAC) provides software for clustering and high availability in Oracle database environments.

RAIDRedundant array of independent disks (RAID) is a storage technology that combines multiple disk drive components into a logical unit for the purposes of data redundancy and performance improvement. Data are distributed across the drives in one of several ways, referred to as RAID levels, depending on the specific level of redundancy and performance required.

RBACIn computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. RBAC is sometimes referred to as role-based security.

relayA relay is an intermediate product between the source and target, or true sender and true receiver, in a flow. A relay can be an Axway product or an unmanaged product.

resourceA class of object in a product whose use can be authorized only through privileges associated with user roles.

RESTRepresentational State Transfer (REST) is a software architecture style for building scalable web services. REST consists of a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.


Glossary

restart Transfer CFTsWhen Central Governance restarts Transfer CFTs to update their configurations, only the Transfer CFT servers are restarted. Central Governance does not start or stop Transfer CFT Copilots. Central Governance communicates with Transfer CFT servers via their Copilots. Central Governance can perform actions on Transfer CFT servers only when their Copilots are running.

RESTfulRESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE) web browsers use to retrieve web pages and to send data to remote servers. Representational State Transfer (REST) interfaces usually involve collections of resources with identifiers. For example, /people/paul, which can be operated upon using standard verbs, such as DELETE /people/paul.

RMIRemote method invocation (RMI) is a distributed object technology for the Java programming language. It is available as part of the core Java application programming interface (API) where the object interfaces are defined as Java interfaces and use object serialization.

roleA collection of privileges. Roles are assigned to users and govern the products they can access and the actions they can perform.

saltIn cryptography, a salt is random data that are used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary attacks and pre-computed rainbow table attacks. A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication while defending against compromise of the plaintext password in the event that the database is somehow compromised.

SDLThe secure development lifecycle (SDL) is process for enhancing product security during development of the product.

self-signed certificatesIn cryptography and computer security, a self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies. This term has nothing to do with the identity of the person or organization that actually performed the signing procedure. In technical terms a self-signed certificate is one signed with its own private key.


Glossary

server communication profilesServer communication profiles contain details for a client to transfer data via a protocol to the sender or receiver that acts as a server. The sender acts as a server when it publishes files for the receiver. The receiver acts as a server when it receives files pushed by the sender.

service classA service class groups product services that facilitate data flows.

SFTPSSH File Transfer Protocol (SFTP) is a network protocol for file transfer and manipulation functionality over any reliable data stream.

SHAThe Secure Hash Algorithm (SHA) is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS).

SIDIn Oracle, a SID dentifies the database instance (database name + instance number). For example, if the database name is somedb and the instance number is 3, the SID is somedb3.

single sign-onSingle sign-on (SSO) enables a user to log on once and gain access to all components managed by the SSO system without being prompted to log on again for each component.

SMTPSimple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail (email) transmission.

SOAPSimple Object Access Protocol (SOAP) is a protocol specification for exchanging structured information in the implementation of Web services in computer networks. It relies on Extensible Markup Language (XML) for its message format. SOAP usually relies on other application layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

sourceThe source is the owner of the data being transferred.

source initiator modeTransfer mode in which the Transfer CFT where the files are located initiates the transfer


Glossary

SSHSecure Shell (SSH), sometimes known as Secure Socket Shell, is a UNIX-based command interface and protocol for securely getting access to a remote computer.

SSLSecure Sockets Layer (SSL), which is the predecessor of Transport Layer Security (TLS), is an encryption protocol that ensures communication security over the Internet. See TLS for more information.

SSOSingle sign-on (SSO) enables a user to log on once and gain access to all products managed by the SSO system without being prompted to log on again for each product.

STARTTLSSTARTTLS is an extension to plain text communication protocols, which offers a way to upgrade a plain text connection to an encrypted TLS or SSL connection instead of using a separate port for encrypted communication.

store-and-forwardStore-and-forward occurs when files are routed through one or more intermediary sites called store-and-forward sites. The feature only is available from a requester/sender (write-mode transfer).

synchronousSynchronous communication is when data are sent in a continuous stream at a constant rate.

tagsKeywords for classifying objects like applications, products, flows, partners.

targetThe target is the receiver of the data exchange.

target initiator modeTransfer mode in which the Transfer CFT that will receive the files sends a request to another Transfer CFT to send the files

TCPThe Transmission Control Protocol (TCP), one of the core protocols of the Internet protocol suite (IP), is often called TCP/IP. TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer.


Glossary

TLSTransport Layer Security (TLS) is an encryption protocol that ensures communication security over the Internet. TLS encrypts the network connection above the transport layer. TLS uses asymmetric cryptography for key exchange, symmetric encryption for privacy and message authentication codes for message integrity. Secure Sockets Layer (SSL) is the predecessor of TLS.

transferin Transfer CFT, the data transport and exchange of the actions to be taken on the data (read, write, create, delete) from one computer (partner) to another via a network. One of the partners is the sender and the other the receiver.

UCONFStands for unified configuration in Transfer CFT.

UDTThe UDP-based Data Transfer Protocol (UDT) is a high performance data transfer protocol designed for transferring large volumetric data sets over high-speed wide-area networks.

UFMsee Unified Flow Management

UIuser interface (same as graphical user interface or GUI)

UIDA user ID (UID) is a unique positive integer assigned by a Unix-like operating system to each user. Each user is identified to the system by its UID, and user names are generally used only as an interface for humans.

Unified Flow ManagementUnified Flow Management (UFM) is a set of Axway products that enable you to manage the flow of data within and outside your enterprise.

unmanaged productUnmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that cannot register in Central Governance or third-party products.

unmanaged productsUnmanaged products are systems that are not registered in Central Governance, but that are integrated in flows for transferring files. Unmanaged products can be Axway products that


Glossary

cannot register in Central Governance or third-party products.

URIA uniform resource identifier (URI) is a string of characters for identifying the name of a resource. This enables interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols.

user exitA subroutine invoked by a software package for a predefined event in the execution of the package. Clients of the package can substitute their own subroutines in place of the default ones provided by the package vendor to provide customized functionality. A typical use is replacing the user exits provided by a sort-merge package, where the user program provides its own subroutines for comparing records. The procedures provided by the user take the place of the default routines provided by the package vendor. Procedures provided as user exits are typically compiled into a static library and linked directly with the package to produce an executable program. Another approach employs dynamic libraries to accomplish the same thing.

UUIDA universally unique identifier (UUID) is an identifier standard used in software construction. A UUID is simply a 128-bit value. The meaning of each bit is defined by any of several variants.

VPNA virtual private network (VPN) is constructed by using public wires — usually the Internet — to connect to a private network, such as a company's internal network.

Web serviceA software system designed to support interoperable machine-to-machine interaction over a network.

workflowThe sequence of tasks through which a process advances from initiation to completion.

write-mode transferIn the PeSIT protocol, a write-mode transfer occurs when a file is sent from the requester to the server.

z/OSz/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390.


Glossary

zip bombA zip bomb, also known as a zip of death or decompression bomb, is a malicious archive file designed to crash or render useless the program or system reading it. It is often employed to disable antivirus software and create an opening for more traditional viruses.


Central Governance User's Guide - Axway Documentation Portal

Documents

Transcript of Central Governance User's Guide - Axway Documentation Portal