FTP Adapter: Version: v6.3.4 Q2

FTP Adapter
Version: v6.3.4 Q2
November 10, 2010

Table of Contents
1 Terms and Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Features and Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
4.2 Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
4.3 Certificate Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
4.4 Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
4.5 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
5 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Adapter Control over the Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
6.2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
6.3 Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
7 Master Data Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7.1 Configuring FTP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Configuring FTP Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8 Process Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 DtFtpRequestType Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 sendFile (Sending Messages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.3 polling (Polling Messages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.4 processFtp (FTP Processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.5 listBox (List) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.6 getFile (Get). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7 Receiving Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7.1 initiateMessage (Initiate to the System). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7.2 Return into Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.8 initiateDuplicateMessage (Receiving Duplicate Messages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.9 Receiving Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.10 Report Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.10.1 Correlation Outside of the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.10.2 Correlation Within the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.10.3 Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.11 Adapter Invocation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.12 Direct Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.13 Synchronous Adapter Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.14 Worklist Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9 Extended Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1 HostDir Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.1 SEND Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.2 POLL Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2 Lock File Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3 Keep-Alive Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.4 Connection Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.4.1 ACTIVE Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4.2 PASSIVE Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.5 Security Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6 TLS Client Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.6.1 Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.7 Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.8 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.8.1 Script Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.8.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.8.3 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.8.4 Client-Side Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.8.5 Script Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.8.6 Transaction Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.9 Temp File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.10 List Settings (Charset, Locale, NLST and Custom Pattern) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.10.1 Simplified Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.10.2 Custom Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.11 IP Address Caching/Dynamic IP Address Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10 Adapter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1 Timeout Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.2 Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
11 Adapter Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
12 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
13 Server Type Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

13.1 Standard FTP (UNIX, DOS, OS/400) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.2 HPUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.3 Amazon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.3.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.3.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.4 MVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.5 Novell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.6 BAAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.7 EBMX_ANX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.7.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.7.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.8 EDISwitch (Ford Solmis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.8.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.8.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.8.3 Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.9 Sterling Commerce. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.9.1 General Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.9.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.9.3 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.9.4 Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.10 Sterling IIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.10.1 General Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.10.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.10.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.11 IBM IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
13.11.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.11.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

13.11.4 Common. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.11.5 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.11.6 Custom Script File Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.12 EDI*Express (GE MARK III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.12.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.12.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.13 EDI*Express (GE MARK 3000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.14 EXITE (ECODEX). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.14.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.14.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14 Known Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1 Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.2 Receiving Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

C Secured FTP (FTP Over SSH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.2 Establishing the SSH Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.3 Configuring FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C.3.1 Configure a Local SOCKS Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C.3.2 Configure an FTP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C.3.3 Configure an FTP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
C.4 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4 Sample Scenario for cheap polling of GE MARK III reports . . . . . . . . . . . . . . 81
5 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1 IBM IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Copyright (c) 2010 SEEBURGER AG (http://www.seeburger.de). All rights reserved.
If (registered or pending) trademarks are named in this document, the rights of the respective proprietors
apply.
Note: False configuration and/or improper use of communication components may result in significant
charges from your telecommunication provider. Also consider configuration changes initiated by your
telecommunication provider. SEEBURGER is not liable for related additional costs.
Note: We expressly declare that the document "SEEBURGER Legal Information" (delivered also with
your BIS installation media) is part of this documentation.
Figures
3-1 FTP Model 3

4-1 BIS Architecture 6
B-1 Add an FTP node 76
B-2 Create a process 76
B-3 Create a process 77
FTP Adapter
1 Terms and Definitions
Term / Abbreviation Meaning

FTP (File Transfer Protocol): TCP-based protocol for file exchange. Based on
RFC959.
TCP (Transmission Control Protocol): communications standard used in TCP/IP
networks (e.g. internet) which allows two computers to establish a
connection and exchange data.
VAN (Value Added Network): proprietary communication network providing
some added services to the end user – security, traceability, replies, etc.
FTP VAN VAN network using FTP protocol as a gateway for the users.
IBMIE (IBM Information Exchange): Popular VAN protocol from IBM corp.
GE_MARK_III and Popular VAN protocols from GE Information Services.
GE_MARK_3000
GEIS The marketing name of GE_MARK_III protocol.
EXITE/ECODEX Popular VAN protocol from IBM.
Converter See BIC.
EDI Electronic Data Interchange.
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport. (
http://www.unece.org/trade/untdid/welcome.htm)
FTP Adapter - v6.3.4 Q2 1

FTP Adapter
2 Introduction
The SEEBURGER FTP Adapter extends the SEEBURGER Business Integration Server (BIS) with the
capability to transfer files according to the FTP protocol specification with the particular support of several
VANs. It is tightly integrated with the BIS 6 system, so that the exchanged files can be composed,
decomposed, and otherwise processed under the control of a user-defined process, which can be adapted to
the user’s specific requirements and environment.

FTP Adapter
3 Basics
The FTP (File Transfer Protocol) is a protocol for reliable and efficient file transfers. It is TCP-based and it
uses the client-server model. The File Transfer Protocol is officially specified in RFC 959. The following
simple diagram represents the FTP model:
Figure 3-1: FTP Model
The SEEBURGER FTP Adapter is a FTP client (based on RFC 959) with the additional support of some
VANs that have FTP access points. It allows secure transfer based on:
• RFC 2246 (The TLS Protocol Version 1.0),

• RFC 2228 (FTP Security Extensions), and
• RFC 4217 (Securing FTP with TLS).

FTP Adapter
4 Overview
This topic gives an overview of the features, the restrictions, and the integration of the adapter to the BIS
system, plus the system requirements.
4.1 Features and Restrictions

The FTP Adapter supports the following protocols:
• Plain FTP as of RFC959;

• IBMIE VAN (gateways are not supported);
• GEIS (GeMarkIII) and GeMark3000, report file is only extracted, if needed;
• EXITE(ECODEX), EDIFACT file processing, DISPATCHED reports;
• EBMX/ANX VAN;
• EDISwitch, FordSolmis VAN;
• Amazon, HPUX, MVS server types;
• Sterling Commerce and Sterling IIB;
• MCI EDI*Net;
• BAAN server type.
• AS400 file members (*MEM) and stream files (*STMF).
The FTP Adapter supports the following options:
• SSL, both IMPLICIT and AUTH_TLS support, server authentication

• All popular FTP proxy types like: USER with login, USER without login, SITE with login and OPEN
without login
• Active and Passive connection modes
• KeepAlive feature
• Using temp file for upload
• Using Lock file
• Using custom charset (encoding) for communication with the FTP server
• Using custom list pattern for parsing the List result
• Binary and ASCII transfer types
• Using custom port range for active connection
4.2 Logical Systems

The FTP Client supports Logical Systems as described in the manual Master Adapter Configuration Guide.

FTP Adapter
In particular, master data and runtime data exclusively belong to one Logical System. The adapter is able to
process data and processes according to their Logical System, and therefore one instance of the adapter
may be shared across all Logical Systems.
Parallel Polling Actions

The different logical systems may poll a server as equals partners. This can lead to conflicts when it is not
desired that messages are polled from different logical systems. Nevertheless, this is a configuration issue
and can also be the desired behavior. E.g., one logical system is polling, another logical system is polling,
and deleting messages.
Because of this special case, no master data restrictions are added. It is the administrator’s responsibility to
avoid parallel pollings, i.e. to prevent the creation of duplicate accounts used for polling.
4.3 Certificate Rollover

This communication adapter provides a Certificate Rollover mechanism to ensures a seamless transition of
certificates or keys in communication scenarios.
It may be used for example to rollover smoothly from an old, expiring certificate to a newly issued one.
There are two different list controls for managing the rollover lists. Their type depends on the usage of the
certificate.
There are two usage scenarios. Usages like signature validation or decryption for inbound messages, where
several certificates may be in charge in parallel, and usages like signing and encrypting outbound messages,
where a dedicated certificate is used at a certain point of time.
Refer to the topic Configuration in the Certificate Rollover manual for further details.
4.4 Integration
The figure below illustrates the BIS 6 architecture.

FTP Adapter
Figure 4-1: BIS Architecture
Each communications adapter runs inside the Adapter Engine. Send requests are passed from the Process
Engine via the Queuing System Worklist, the Direct Mode or the sync connector to the appropriate
communications adapter in the Adapter Engine.
Incoming messages received from a listener for example, are forwarded to the Process Engine using the
Initiator.
4.5 System Requirements

The system requirements are described in the topic Installation and Configuration of the BIS Installation
Guide, and in the Release Notes for your software version.
There are no adapter-specific requirements.

FTP Adapter
5 Installation
Please refer to the BIS Installation Guide for the detailed installation steps. There are no adapter-specific
requirements.

FTP Adapter
6 Usage
6.1 Adapter Control over the Control Center

To start and stop the adapter, use the adapter-related Control Center. There, also the adapter's user
configuration can be displayed and edited.
For more information, refer to the topic Control Center in the Master Adapter Configuration Guide.
6.2 Operations
The SEEBURGER FTP Adapter basically supports two types of operations:
• System-to-Module, like sendFile, polling, processFtp, listBox, and getFile, and

• Module-to-System, like initiateMessage and the general operation for all communication adapters -
initiateReport.
The first type represents operations initiated by the system, while the second group represents operations
started by the FTP adapter.

FTP Adapter
Parameter Definition
sendFile This operation uploads one or more files to a specified FTP server.
polling This operation checks and downloads explicit files from a specified FTP
server.
processFtp
Attention: This operation is only applicable for standard FTP servers
and BAAN.
This operation allows both uploading and downloading in one execution.

listBox This operation lists all the files on a specified FTP server.
getFile This operation gets one specified file from a given FTP server.
initiateMessage This operation returns information to the system about a downloaded FTP
file.
initiateDuplicateMessage
Attention: This operation is only applicable for the following VANs:
IBM IE, GE MARK III, GE MARK 3000 and ECODEX.
This operation returns information to the system about a downloaded

duplicate message.
initiateReport This operation returns information about a downloaded FTP report to the
system.
The FTP Adapter operation process could be summarized as follows:
1. Receive a message from Work List Handler.

2. Prepare an internal task based on the requested operation type.
3. Create a new session, if another task is still in process.
4. Extract the partner-related data from the master data and include it in the task object.
5. Overwrite it with the partner-related data from the task request XML file.
6. Extract the script for this task (default if not overwritten).
7. Execute the script, e.g. for data transfer.
8. If the script is finished, check whether another task is waiting in the Work List Handler for this session,
and close the session if not.
9. Prepare the response XML file (depending on the task type).
10. Return the task with the corresponding status to the Work List Handler.
6.3 Monitoring
The Adapter is connected to different monitors. The specific function of each monitoring tool is described in
the Master Adapter Configuration Guide.
Monitor Description
Adapter Monitor Provides runtime information.
Queue Monitor Gives an overview of orders waiting for the Adapter.
Recovery Monitor If individual orders require recovery, they are listed in the Recovery
Monitor.
Transaction Monitor The SEEBURGER Transaction Monitor is a monitor for showing the
Message ID Store entries used by the Adapter to correlate messages and
related reports.
Resource Monitoring Provides information about the resource reservations.

FTP Adapter
7 Master Data Configuration
The partner settings can be saved in the BIS master data and can be edited with the BIS Front-end
application. In the master data, partner settings are separated in two objects:
• The address object represents an individual FTP user.

• The connection object represents a FTP server and its communication settings.
7.1 Configuring FTP Addresses

Parameter Meaning
Name (Mandatory) Descriptive and an unique name for the configuration
parameter set.
User (Mandatory) User name for establishing a connection.
Password Password for establishing a connection.
Account Account name (if required by the server). Leave it empty if it is not
required.
Relative path Relative path for this user. Please use the FTP server's operating system's
path conventions. Please refer to the topic HostDir Syntax (page 25) .
Mask Upload or the download mask. Please refer to the topic HostDir Syntax
(page 25) .
Default encoding Default character set of the downloaded attachment.
For ASCII and BINARY transfer types, this encoding will be used.
Note: False encoding settings may corrupt the files.
7.2 Configuring FTP Connections

Connection Settings
Parameter/Option Description
Name (Mandatory) Descriptive and unique name which describes the record.
Server type Please select the adequate server type for the applied FTP server, or
leave the default Standard FTP if you are not sure which to select.

FTP Adapter
Host (Mandatory) Host name of the FTP server. Both DNS host name and IP
address are accepted.
Port (Mandatory) Port of the FTP server. The default value is 21. 990 is default
value if Implicit SSL/TLS is selected.
Use TLS Please check the Security Mode (page 28) topic for details.
Connection mode For the connection mode, both Active and Passive mode is supported.
Please refer to the Connection mode (page 27) topic for details.
Port range This field is visible if the value Active is set for the Connection mode. It
adds options for specifying ports that are used to establish a data
connection with the FTP server. Please refer to the Port Range (page 28)
topic for details.
Keep alive Activates the Keep-alive mechanism. Please refer to the Keep Alive (page
27) topic for details.
Proxy mode Please check the Proxy Support (page 30) topic for details.
File Handling
Base directory Base directory on the FTP server, which resolves the relative path in the
address. Please use the FTP server's OS path conventions. For further
details, refer to the HostDir Syntax (page 25) topic.
Transfer type For transfer type, Binary (TYPE I) and ASCII (TYPE A) are supported.
Lock file The lock file name can include the complete path. It enables the Lock File
feature. See the Lock File (page 27) topic for details. Leave empty to
disable the lock file feature.
Filename spelling Controls the (upper/lower) case of the file name on upload.
If Original , no modification is applied.
The To upper and To lower options will change the case accordingly. Useful
on cross-platform upload (Windows-to-Unix).
Append mode Controls the upload behavior if the file name is already present in the
upload directory.
• Append
The file will be appended.
• Overwrite
The file will be overwritten.
• Unique
The adapter executes a list command before uploading. If a file with
this name already exists in the list, an error will be returned; otherwise
it will be uploaded.
Use Temp file This field is visible if Overwrite or Unique is selected for Append Mode. If it
is set when uploading, a temporary file will be used. Check the Temp File
(page 40) topic for details.
Delete file If selected, the downloaded files will be deleted from the server. This
setting is only valid for standard FTP servers.

FTP Adapter
List Command
Custom charset This field provides an option to specify a character set (encoding) different
from the default one (ISO-8859-1). It is used in FTP connections to the
server. Please check the List Settings (page 40) topic for details.
Use NLST command If selected, the FTP Adapter uses simple listing. Please check the List
Settings (page 40) topic for details.
When this field is selected the field Language is hidden and it is not used.
Language This field provides specification of a Locale setting that differs from the
default value (US locale). Please check the List Settings (page 40) topic
for details.
Custom list pattern This field provides specification of a pattern that differs from the default
one. This pattern will be used for parsing the result of the list command.
Please check the List Settings (page 40)topic for details.
Custom date pattern This field specifies the pattern for parsing the date in the FTP server
listing. Please check the List Settings (page 40) topic for details.

FTP Adapter
8 Process Configuration
All operations supported by the FTP Adapter are realized over processes. You can find request samples in
the topic Appendix B: Sample Scenario (page 74) of this documentation.
Besides the master data configuration, the Partner Settings can be specified directly in the request. This
gives more flexibility as simpler and/or more flexible scenarios can be defined. Each parameter setting in the
request overwrites the corresponding parameter that may come from the master data. I.e. if both master data
and the request partner settings are used, the ones in the request will have priority.
Note: Even if the Partner Settings reside in the master data, the originAddressId and connectionId
elements should be used to specify the applied address and connection objects.
Note: Many of the described elements use default values. You can select them by clicking the right
mouse key and selecting Constants | Select from the context menu. If you enter a wrong constant
name, the process will be activated successfully, because the resulting request XML file is not validated
against the schema. It is only validated, when it is received by the FTP Adapter at runtime, but the error
message in the JAXB exception is sufficient for a profound error analysis.
If a field is left empty, it will have the value null and the default value will be used. In this case it will not
overwrite the respective values from the master data's Partner Settings.
8.1 DtFtpRequestType Element

DtFtpRequestType element is a base element for the request on operations: sendFile, polling, processFtp,
listBox, and getFile. All its members are included in these operations. The tables below contain the
description of the members of the DtFtpRequestType and their meaning.
Note: It is possible to omit the destinationAddressId and connectionId. In this case, at least the
serverName and userName must be specified (in partnerSettings).

FTP Adapter
Parameter Description
clientId Client ID, must correspond to the logical system in which the process is
running.
originAddressId (Not relevant)
originAddressName (Not relevant)
destinationAddressId ID of the address object which is used.
destinationAddressName Use the name of the address object in order to show it in the Message
Monitor.
connectionId Connection ID.
connectionName Use the name of the connection object in order to show it in the Message
Monitor.
correlationId In requests, this field holds the business process Message ID. It is used as
primary ID in the MessageIdStore, and it is visible in the Message Monitor.
If not specified, an UUID is generated and set in the request. Please refer
to the Master Adapter Configuration Guide for more details.
subject Not used in the FTP context, but useful for information purposes.
dialInCommand (Obsolete) RAS dial-in command.
dialOutCommand (Obsolete) RAS dial-out command.
queue Please refer to the topic Adapter Invocation Mode. (page 22)
Partner Settings
serverType According to the applied server type, the following values apply :
• STANDARD
• IBM_IE
• GE_MARK_III
• GE_MARK_3000
• MVS
• ECODEX
• STERLING_COMMERCE
• STERLING_IIB, VMs
• AMAZON, HP_UX
• NOVELL
• EBM_ANX
• EDI_SWITCH
• FORD_SOLMIS
• BAAN
• MCI
Refer to the individual server type topics for details.
serverName Server's DNS name or IP address.
serverPort Server's port number, the default is 21.
userName User name
userPass User password
account Account name. Leave empty if not used!

FTP Adapter
baseDir Base directory on the FTP server for resolution of the relativePath.
Please use the FTP server's operating system's path conventions. Please
refer to the topic HostDir Syntax. (page 25)
relativePath This is the relative path for the user.
Please use the FTP server's operating system's path conventions. Please
refer to the topic HostDir Syntax (page 25).
mask Applied upload or download mask. Please refer to the topic HostDir Syntax
(page 25) .
transferType Transfer type. Applicable values are:
• I for BINARY
• A for ASCII.
Further values can be specified if the server recognizes them.
lockFileName Lock file name. Leave it empty to disable the lock file feature. Also refer to
the Lock File (page 27) topic.
uploadCase Upload case settings. Applicable values are:
• ORIGINAL
• TO_LOWER
• TO_UPPER.
appendMode Append mode. Applicable values are:
• APPEND
• OVERWRITE
• UNIQUE.
useTempFile Use temp file flag. Applicable values areYES or NO. Also refer to the Temp
File (page 40)topic.
delOnDownload Delete file on download:
Applicable values are: YES or NO.

connectMode Connection mode. Applicable values are:
• ACTIVE
• PASSIVE
Also refer to the Connection Mode (page 27) topic.
keepAlive Keep Alive flag. Applicable values are: YES or NO.
Also refer to the Keep Alive (page 27) topic.

proxyMode Proxy mode. Applicable values are:
• NONE
• DEFAULT
• SPECIFIC
Also refer to the Proxy Server topic.
proxyAlias This is the Proxy alias. Please refer to the Proxy Mode (page 30) topic for
details.

FTP Adapter
securityMode Security mode. Applicable values are:
• CLEAR
• AUTH_TLS
• IMPLICIT.
Also refer to the Security Mode (page 28) topic.
clientAlias Certificate and private key alias.

trustStoreAlias Server certificate alias.
Leave it empty to disable server authentication. Also refer to the Security

Mode (page 28)topic.
sslServerHostnameVerification SSL server host name verification flag. Applicable values are: YES or NO.
Partner VAN Settings
EBMX
senderID Please refer to the EBMX ANX Server topic for details
senderPass
receiverID
fileType
Baan
controlFileID Please refer to the BAAN Server topic for details.
deleteControlFile
from
to
GE Mark3000
messageClass Please refer to the GE Mark 3000 Server topic for details.
ECODEX
messageClass Please refer to the ECODEX Server topic for details.

FTP Adapter
MVS
LRECL Please refer to the MVS Server topic for details.
BLKSIZE
RECFM
AMAZON
fileExtension Please refer to the AMAZON Server topic for details.
8.2 sendFile (Sending Messages)

The sendFile operation basically represents a file upload to the specified FTP server. The sendFile operation
is requested by a message that contains DtFtpSendFileRequest request part contained in the message
body. One attachment contains the file to be uploaded. It is uploaded with the name prepared as described in
the HostDir Syntax (page 25) topic in the adapter's manual.
The send request contains the elements, described in the common process definitions, and the several
additional elements, described below. In the table below the additional members of the request and their
meaning are described.
scriptFile This is the script file URI, refer to the Scripting (page 30) topic in the
adapter's manual for further details.
script This is the script content. This script will be used if no scriptFile URI is
present.
needDispatchedReport Here you can select the option Need dispatched report: YES or NO.
needDisplayedReport Here you can select the option Need displayed report: YES or NO.
reportTimeout This is the Report timeout in hours, 0 means infinite, the default is 72
hours.
reportAction Here you can select the option Report action: REFER or DISCARD.
A report could be requested while uploading the file, if reports are supported by the specified FTP server
type. Reports are special messages that are generated as a result of the receiver interaction with the
uploaded file. Reports could signal either some positive action like the message being received successfully,
or a negative status like the message has failed. The following report types are supported:
• FAILED report: The message was not delivered to the user's mailbox.
• DISPATCHED report: The message was delivered to the receiver's mailbox.
• DISPLAYED report: The message was downloaded from the mailbox by the receiver.
• PURGED report: The message was deleted without being received by the user.
• TIMEOUT report: The message has timed out, without being received.
Note: Not all reports are supported by all server types. Generally reports are supported only by VANs
and FTP server types used as VAN gateway. Please refer to each individual VAN topic which reports are
supported.

FTP Adapter
The report can have a timeout period. When this period expires, the message mapping is finished, and
possible a TIMEOUT report is generated. A TIMEOUT report will only be generated, if the reportAction
element has the value REFER e.g. send the report to the system. If the reportAction element has the value
DISCARD, the TIMEOUT report will be discarded, and only a log message will be traced.
After a successful upload, a DtFtpSendFileResponse response part is created and attached to the task.
Then the task is returned to the Work List Handler. The response part contains one <DtFtpSentFileDetails>
element for every uploaded file. These elements contain some basic details about the uploaded file, like the
file name after processing and can contain some server-specific detailed elements.
8.3 polling (Polling Messages)

The polling operation basically represents a file download from a specified FTP server. The polling operation
is requested by a message that contains the DtFtpPollingRequest request part contained in the message
body. Then the adapter lists the specified location at the FTP server, and downloads all available files that
match the download criteria. If reports are requested and supported by this server type, all new reports are
also listed and downloaded. Listing and downloading reports is very specific procedure for every VAN that
supports them, but is fully implemented in the FTP Adapter.
The polling request contains the elements, described in the common process definitions and the several
additional elements, described below. In the table below are described the additional members of the request
and their meaning.
scriptFile Script file URI: Please refer to the Scripting (page 30) topic in the
adapter's manual for further details.
script Script content which will be used if no scriptFile URI is present.
After each download, the item is classified as new file, or new report and processed respectively. If a new file
is received, a new message is created, containing the DtFtpReceivedFile request part. The downloaded file
content is placed as a message attachment, and the new message is forwarded to the system. All available
information for the downloaded file is available in the DtFtpRequestFile element. Please refer to the topic
Receiving Messages (page 20) in the adapter's manual for details.
It is possible for the new downloaded file to be placed as a message attachment to the
DtFtpPollingResponse, without the creation of a new message. In this case, the response is added also to
the file details . To do this use a custom script with the appropriate argument for the get command. Please
refer to the topics Scripting (page 30) and Receiving Messages (page 20) in the adapter's manual for
details.
If a new report is received, it is parsed, and a new message is created containing the DtReport request part.
The new message is forwarded to the system. Please refer to the topic Receiving Reports (page 22) in the
adapter's manual for details.
Note: Reports are a VAN-specific feature and are supported on a very limited number of server types.
Besides, report requesting and receiving is very different from VAN to VAN. Those differences are
hidden behind a common interface that the FTP Adapter provides, but if the report usage is required,
you are strongly advised to get familiar with the reporting capabilities, and limitations of the respective
VAN.

FTP Adapter
8.4 processFtp (FTP Processing)

The processFtp operation basically represents the FTP interaction with the server. It can be upload,
download, or both in a single operation. The processFtp operation is requested by a message that contains
the DtFtpProcessRequest request part contained in the message body.
Note: The processFtp operation has a default script only for a BAAN server type. For the standard FTP
server type, the script must be explicitly specified in the scriptFile, or script field on the request. Refer to
the topic Scripting (page 30) in the adapter's manual for more information about the scripting.
Note: The processFtp operation must be used only with standard, and the BAAN server types. The
processFtp request contains the elements, described in the common process definitions, and the
several additional elements.
In the table below are described the additional members of the request, and their meaning.
scriptFile This is the script file URI, please refer to the topic Scripting (page 30) in
the adapter's manual for further details.
script This is the script content. This script will be used, if no scriptFile URI is
present.
needDispatchedReport This field is not used with this adapter.
needDisplayedReport This field is not used with this adapter.
reportTimeout This field is not used with this adapter.
reportAction This field is not used with this adapter.
After a successful upload, the DtFtpProcessReponse attached to the task contains one DtFtpSentFileDetails
element for every uploaded file. These elements contain some basic details about the uploaded file, like the
file name after processing, and can contain some server-specific details elements.
After each download, the item is classified as a new file, or a new report and processed respectively. If a new
file is received, a new message is created containing the DtFtpReceivedFile request part. The downloaded
file content is placed as a message attachment, and the new message is forwarded to the system. All
available information for the downloaded file is available in the DtFtpRequestFile element. Please refer to the
topic Receiving Messages (page 20) in the adapter's manual for details.
It is possible for the new downloaded file to be placed as a message attachment to the
DtFtpProcessReponse, without creating a new message. In this case, the response is also added to the file
details. To do this use a custom script with the appropriate argument for the get command. Please refer to
the topics Scripting (page 30) and Receiving Messages (page 20) in the adapter's manual for details.
8.5 listBox (List)

The listBox operation basically represents a list of the available files at a specified FTP server. The listBox
operation is requested by a message that contains the DtFtpListBoxRequest request part contained in the
message body. Then the adapter lists the specified location on the FTP server, parses the list result, and
returns it in the DtFtpListBoxResponse response part. All of the applicable options specified in the Partner
Setting are in effect with this operation.
Note: With individual VANs, listing is either very limited, or not available at all. This is due to the
transaction concept used by every VAN.

FTP Adapter
The list request contains the elements, described in the common process definitions. No additional members
of the request are needed.
Each file in the list is shown as a separate <receivedFileDetails> element in the list response.
Note: The LIST command does not download the file, and so the only information that is contained in
the response is the one received with the list command result. This means that some of the information
that is available in the same element in NewFile request part, will not be available here. With some
VANs, reports are also listed and presented in the LIST result. Please refer to each individual VAN topic
for details.
8.6 getFile (Get)

The getFile operation basically represents a download of single file from a specified FTP server. The getFile
operation is requested by a message that contains the DtFtpGetFileRequest request part contained in the
message body. All of the applicable options specified in the Partner Setting are in effect with this operation,
with exception of the HostDir, which is ignored when the field remoteFileName is specified.
Note: The get File operation is not applicable, or very limited for the VANs. This is due to the transaction
concept used by every VAN.
The get request contains the elements, described in the common process definitions and the several
additional elements. In the table below the additional members of the request and their meaning are
described.
remoteFileName The name of the file, which will be downloaded. If this field is specified, the
HostDir (base dir, relative path and mask) is ignored for the processing.
Note: The getFile operation does not support wildcards. The file must be exactly specified.
If the file is downloaded successfully, it is attached to the response together with the file details.
8.7 Receiving Messages

There are two ways to receive messages: Initiate them to the system, or directly return to the response of the
operation, which downloaded the file.
8.7.1 initiateMessage (Initiate to the System)

The initiateMessage operation passes to BIS 6 a payload received by the adapter. In a business process,
this is the point of entrance, to handle received FTP messages. The new message contains the following
data:

FTP Adapter
Subject The FTP Adapter sets the file name as a subject.
correlationId Generated UUID.
Attachments Received payloads (files) from FTP Adapter.
startTime Start time of the downloaded file.
stopTime Stop time of the downloaded file.
remoteFileName File name on the remote server's side.
fileSize Size of the file (maybe not present).
creationTime Creation time of the file (maybe not present).
attachmentId ID of the attachment which is stored with this file.
gemarkFileDetails This are the specific fields for the GeMark-type files. Please refer to the
GeMark III Server and GeMark 3000 Server topics in the adapter's manual
for details.
ecodexFileDetails Specific fields for the ECODEX-type files. Please refer to the ECODEX
Server topic in the adapter's manual for details.
ediswitchFileDetails This are the specific fields for the EDISwitch-type files. Please refer to the
EDISwitch Server topic in the adapter's manual for details.
sterlingcommerceFileDetails This are the specific fields for the Sterling Commerce type files. Please
refer to the Sterling Commerce topic for details.
ibmieFileDetails This are the specific fields for the IBMIE-type files. Please refer to the IBM
IE Server topic in the adapter's manual for details.
unixFileDetails This are the fields for the UNIX-type file permissions.
8.7.2 Return into Response

The file will be returned into the response as an attachment. The file details are added also to the response.
The response will contain the following additional data:
Attachments This is the received payload (file) from the FTP Adapter.
receivedFileDetails\remoteFile This is the file name on the server side.
Name
receivedFileDetails\fileSize This is the size of the file (maybe not present).
receivedFileDetails\creationTi This is the creation time of the file (maybe not present).
me
receivedFileDetails\attachment This is the ID of the attachment, which is stored with this file.
Id
8.8 initiateDuplicateMessage (Receiving Duplicate Messages)

The initiateDuplicateMessage operation is the same as the initiateMessage. It is only used to show that a
supposedly deleted message is polled for a second time.
Attention: This operation is only available for the following VANs:

- IBM IE,

FTP Adapter
- GE MARK III,
- GE MARK 3000,
- ECODEX.
The IBM IE, GE MARK III, GE MARK 3000 and ECODEX include a transaction confirmation mechanism.
There are rare cases of connection break-down during this confirmation. In these cases, the transaction is
not confirmed, e.g. the message is not deleted from the VAN box, and it can be polled again. The internal
message IDs of these VANs can help to identify such messages. Thus, the recognized messages are
initiated to BIS with initiateDuplicateMessage operation.
Note: Duplicate messages can also be viewed in the MessageIdStore monitor. Their secondary ID is a
vanMessageID_duplicate_no. of duplicate.
8.9 Receiving Reports

This operation is documented in the topic Business Process Configuration in the Master Adapter
Configurstion Guide.
8.10 Report Handling

There are two possibilities to correlate FTP messages and reports.
8.10.1 Correlation Outside of the Business Process

The correlation between messages and reports is done by the SEEBURGER MessageIDStore. The
correlation can be viewed with the MessageIDMonitor. Please refer to the topic Monitoring for details.
8.10.2 Correlation Within the Business Process

Additional it is possible to correlate via business processes. For further information, please refer to the topic
Correlation in the Master Adapter Configuration Guide.
8.10.3 Timeout
When a requested report is not received in the given period, the TIMEOUT_REACHED event will be
released. This event initiates the sending report operation to BIS 6. The status of the DtReports is set
thereby on failures.
8.11 Adapter Invocation Mode

There are different invocation modes in which the orders can be forwarded to the adapter. The mode is
configured using the destination or queue part within the outbound operations.
For details about the differences of the invocation modes please refer to the topic 'Adapter Invocation' in the
manual 'Master Adapter Configuration Guide'.
Note: If the destination/queue part is empty, the order is executed in WLH mode.
Following three invocation modes are supported by this adapter:

FTP Adapter
8.12 Direct Invocation

The direct adapter invocation (direct mode) is used to forward orders from the process engine to the adapter.
A JMS queue is used to queue the orders until the adapter is ready to handle them.
• The direct mode supports order retry handling in case of an adapter error. Independent from the error
type the order is retried based on the queue configuration.
• It is possible to connect more than one adapter to one single queue.
The direct mode can be configured over the Worklist Handler GUI. There you can directly create queues and
assign nodes. See the topic Direct Mode GUI for details.
When defining a process, you have to specify a specific queue/destination name to be used. Use async: for
the queue/destination part in the request (note the colon). After the colon, enter the corresponding JMS
queue's JNDI name (e.g. async:queue/ftpTestQueue).
If only async: is entered, the default queue to<PortType> is used (e.g. toDtFTPComponent). This is the
recommended usage for simple architectures, since this method does not require adapter configuration and
queue definition.
Limitation: Orders relying on hardware resources like ISDN, X.31, or X.25 cannot be used with the
direct invocation since no resource management is available. Use the WorklistHandler (page 24
)integration instead.
Note: Up to version 6.3.3 direct: was used instead of async: to specify the queue/destination. You can
still use the direct: parameter.
Note: An error of the type Line-Busy does not increase the retry count of the order.
8.13 Synchronous Adapter Invocation

Beside the Direct Adapter Invocation there is the Synchronous Adapter Invocation.
This invocation method is the fastest. But it is not recommended for each use case. There is no queue
between the process and the adapter. Instead the adapter is executed synchronously from within the
business process. The process itself is not passivated. The process will be blocked until the adapter/module
has finished its work.
This invocation mode is only recommended for short running operations which will not block one of the
process threads for a long time, because there is a limit for maximum parallel executed processes. Also there
is no retry handling for such processes. If there is an error the adapter returns to the process immediately.
The synchronous invocation can be configured using the queue/destination part.
Syntax Description
sync: The operation is executed synchronous on any running instance.
sync:instanceid=MY_INSTANC The operation is executed synchronous on the node with instanceID
E "MY_INSTANCE".
sync:nodegroup=MY_GROUP The operation is executed synchronous on any running node of the node
group "MY_GROUP".

FTP Adapter
Limitation: Orders relying on hardware resources like ISDN, X.31, or X.25 cannot be used with the
direct invocation since no resource management is available. Use the WorklistHandler (page 24
)integration instead.
8.14 Worklist Handler

The SEEBURGER Worklist Handler provides an additional queuing functionality for the system (see the topic
Adapter Invocation for another strategy).
The Worklist Handler accepts orders and can place them in different queues. Each queue can be assigned to
one, or more adapters to which the orders can be sent. The queue in which the order is placed thus
determines to which adapter it can be sent.
In contrast to the Direct Adapter Invocation the queue configuration and the order dispatching can be
configured to a more complex scenario. It supports for example polling of orders, dynamic retry handling, and
resource handling.
To configure the process to use a WLH queue, just enter the name of the queue in the queue part of the
outbound operation.
For details about this invocation mode please refer to the topic 'Adapter Invocation' in the 'Master Adapter
Configuration Guide'.

FTP Adapter
9 Extended Functionalities
9.1 HostDir Syntax

The SEEBURGER FTP Adapter interprets HostDir as the concatenation of baseDir, relativePath, and mask,
which are contained in both the FTP Connection Settings and DtFtpRequestType.
Note: Since the HostDir is used as a FTP command argument, it is strongly recommended that HostDir
is a string formed by any of the 128 ASCII characters except <CR> and <LF> as stated in RFC959.
However, there are FTP servers, which implement the internationalization draft (RFC2640). Such
servers support HostDir with the UTF-8 characters. Generally, the FTP Adapter works with these
servers, but a successfull operation cannot be warranted.
Attention: The HostDir command must correspond to the FTP server OS path conventions. The FTP
client will not take care of correcting the HostDir command, e.g. inserting a "/" or a "\", because not all
the existing possibilities can be considered.
The HostDir must correspond to the FTP server's OS path conventions. The FTP adapter cannot consider
any possibility for the HostDir to be formed by the combination of the server type and the FTP server OS.
Thus, the FTP client will not adjust the HostDir settings, e.g. by inserting a "/" or a "\".
If the relativePath is send and the mask is invoice, the file will be sent as a sendinvoice instead of a
send/invoice. It is the user's responsibility to correct the HostDir settings.
The HostDir specifies the type and the location of uploaded or downloaded files. The behavior described
here is only applicable to the standard FTP server type, and to all other server types unless explicitly stated
otherwise. This syntax definitely does not apply for VANs.
The syntax of the HostDir must confirm to the server site conventions. A plain directory is assumed, if no file
name (mask) is given. E.g. the HostDir ends with a path separator character. Wildcards are also supported
in the file name path (mask) of the HostDir. Wildcards are resolved on the client side (e.g. the FTP server is
never questioned to resolve the wildcard, since no common syntax is defined in the FTP specification).
Supported symbols are "?" that denotes a single arbitrary character and "*" that denotes multiple arbitrary
characters.
Note: Most FTP servers do not allow the host path to start with a slash that denotes the root dir,
because the path resolution is assumed to be relative to the user's home folder.

FTP Adapter
9.1.1 SEND Operation

On Send operation, the path from the path name in the HostDir parameter specifies where the message
payload will be uploaded. By default (if no mask, or mask “*.*” is applied), an unique file name is generated
for the uploaded file in the form of a jSI4WYRP58.see.
If the file name is contained in the path name, it is used as a mask to modify the unique file name. In this
case, wildcards are very useful to apply specific requirements over the file name.
For example:
• The string *.MY will change the file extension to MY.

• The expression ??????_invoice.send will add the _invoice string to the first 6 generated symbols from the
file name, and will change the extension to .send.
• The expression *_invoice.send” will add the “_invoice string to the file name, and will change extension to
.send.
• The mask invoice_*.send will generate the invoice_BZBT8RJ7KD.send file name.
• The mask invoice_*_edi_*.send will generate the invoice_P8JLDOS3Y6_edi_D3SV677XFX.send file
name.
• The mask abc*_123_??_invoice_*.ext generates the
abcD3SV677XFX_123_JD_invoice_WBOG9W2NPS.ext.
Note: Every wildcard ‘?’ means one unique char and every ‘*’ means a unique string that has max. ten
characters.
Note: The bracket symbols ‘(‘ and ‘)’ are not allowed in the file name, and will be removed if they are
specified in the mask.
Please note that the Upload Case parameter will also influence the file name used in upload operation. If
TO_LOWER or TO_UPPER is selected, the file name, generated as described so far will be changed to
lower case, or to upper case.
In all cases, the actual path and file name that are used for uploading will be presented in the <
remoteFileName> element in the SendFileResponse response part as described in the File handling on
SEND (page 17) topic.
Please note that some FTP servers, particularly older Windows and/or MSDOS-based ones, do not allow an
upload operation without a specified path in the upload command. This is the case the HostDir is left empty.
To overcome this problem, please specify at least the current dir shortcut (“.” on most OS’s including Unix
and Windows).
Note: Some FTP Servers require that the path in the upload command must exist on the file structure
on the FTP Server. Otherwise it is possible that the server will reject the upload operation.
9.1.2 POLL Operation

On Poll operation, the path from the path name contained in the HostDir is listed for new files that are to be
downloaded. If file name is contained in the path name, it is used as file mask to select only a subset of files
to download. For example *.new will select all files with the new”extension. new_*.??? will select all files
starting with the new_ that have three char extension and so on.
Note: The wildcard ‘?’ stands for exactly one unspecified symbol, and the wildcard ‘*’ stands for zero, or
unlimited unspecified symbols.

FTP Adapter
Examples:
• With the mask invoice*.*, the FTP will download the files: invoice.edi, invoice_123.att, invoiceA.important,
etc.
• With the mask *abc*.invoice? the FTP will download the files: abc.invoiceA, abc_12.invoice1,
edi_abcany_length01.invoiceB, but will not download the files: abc.invoice, edi_abc.invoice01, etc.
9.2 Lock File Feature

The Lock file mechanism gives a provision to synchronize possible simultaneous Upload and Download
sessions. Such parallel sessions can occur when a single account and/or host path is used by more than one
user/business process. If then two parallel sessions are started, and the FTP server allows simultaneous
sessions, especially if both are Poll or Send with the Unique mode, a file corruption, or an erroneous file
delete can occur.
Attention: The Lock file mechanism can be used to synchronize one Upload and one Download
session, but it must not be used when there are more than one session.
Note: The lock file mechanism is applicable only to ordinary FTP servers, but not VANS.
The Lock file mechanism as specified in the GUI is created in the default scripts and deleted in the process
execution. If an error occurs during execution, the FTP is responsible to remove the created lock file, so a
future communication (especially polling) will not fail because of it. If, for some reason, the FTP cannot delete
the lock file, this would be shown in the Adapter Error Monitor and the adapter log.The default VAN scripts
are missing the commands that implemented the lock file.
9.3 Keep-Alive Feature

The Keep alive is a mechanism used to keep on-demand connections open (e.g. VPN, ISDN bridge, or
firewall) that are configured with an inactivity timeout.
If such connections are used and a large file is transferred, there may be long periods of inactivity on the
control connection. The control connection may be closed and this will terminate the entire transfer of data.
If the connection is open, but there was no activity for 10 sec, and the Keep alive option is activated, the
adapter will send a NOOP command over the control connection. Neither the Keep-alive command, nor the
timeout period can be changed in the current version.
Note: If the FTP client is used with the SEEBURGER FTP Server, make sure that the keep-alive feature
is disabled. The FTP server does not support this mechanism and this will lead to read timeouts.
Please be especially careful when enabling the Keep-alive feature in VANs. The Keep-alive feature sends
NOOP commands that (according to RFC950) should not have any consequences in ordinary FTP servers.
With VANs that have transaction concepts (e. g. IBMIE, GEIS, EXITE), this unexpected NOOP could be
wrongly interpreted as operation conformation and could completely disturb the adapter operation. Please
use the Keep-alive feature only if you are aware of the server's reaction to the excessive NOOP commands.
9.4 Connection Mode

Seeburger FTP Adapter can operate in one of two connection modes: Active or Passive. The mode uses
changes the direction of communications established between the client and server, and thus the operation
of the firewall at each end.

FTP Adapter
9.4.1 ACTIVE Mode

The Active Mode is the traditional communication method between a FTP client and a server. In this mode
the client establishes a connection from a random, unprivileged (>1024), port (X) to the server's FTP control
port (default 21). The client then notifies the server which unprivileged port (X+1) it should connect back to.
The server then initiates a connection from its data port (default 20) to the specified client port (X+1). The
issue here is that the connection between the server and client on port X+1 is initiated by the server, and so
the security devices in front of the client ( NAT, firewalls, bridges ) must be configured so that the remote
hosts can establish connections to their clients on any port over 1024. This is a security leak as this
configuration is prone for abuse, and/or is complicated to configure the network devices.
9.4.1.1 Port Range

The SEEBURGER’s FTP Adapter provides the option to specify a limited selection of ports that will be used
to establish the FTP server’s data connection. This allows to more precisely and protectively configuring the
security devices in front of the FTP client. Several port ranges separated by a comma (‘,’) can be specified.
Each port range contains begin port (inclusive), and end port (exclusive), connected with a dash (‘-’). The
port ranges must be not overlapping. The port range can also be specified with a single port. The FTP
Adapter tries to use consecutive ports across all the specified ranges. Examples for valid port ranges are:
• 10450-10700, 22000-22100;
• 36030-36300, 44123, 52000-52050.
Note: Because the operating systems have a specific timeout before allowing to reuse the sockets, it is
required to specify an adequate number of ports by the port range value. This either means that the
number of the effective ports must be greater than the number of the files, which are
uploaded/downloaded within one session, or that the effective ports are so many that the system
timeout expires before the FTP Adapter covers all of them and starts over.
9.4.2 PASSIVE Mode

In the Passive mode, also known as Client Managed FTP, a client opens two unprivileged ports (X and X+1).
A connection is made from X to the servers control port (21). The server then opens an unprivileged port (Y),
and notifies the client of this port. The client then initiates a connection from X+1 to port Y on the server. In
this way, the client drives the connections and so the firewalls in front of the client can continue to block
inbound connection requests to ports greater than 1024 for increased security on the client network. The
downside is that the firewall in front of the server must allow connections from any port >1024 to any port >
1024 from the client IP address.
9.5 Security Mode

The FTP Adapter can operate in three security modes regarding data transfer: Clear, Implicit and AUTH_TLS.
CLEAR Mode
In this mode there is no security applied for the data or control connection. This presents a security break as
the user password is exchanged in clear-text and could be sniffed by an unauthorized party with the classical
man-in-the-middle attack.
AUTH_TLS Mode
In this mode both the control and the data connections are encrypted using the TLS protocol. The control
connection is opened in clear-text, but the first command that the client issues is AUTH TLS, e.g. a request to
start a TLS handshake. If successful, all other communication over the controlled connection is encrypted.

FTP Adapter
The data connection always starts with a security handshake, and continues only if the connection is fully
encrypted. This is the classical security, expected by the most FTP servers that support security.
IMPLICIT Mode
In this mode, both the control and the data connections start with a TLS handshake, and continue only if it is
successful. This security mode is more modern e.g. complies better with the TLS security architecture, but
does not present any security benefit compared with AUTH_TLS. The major advantage is that the TLS/SSL
handshake can be separated from the FTP server and be established via a central security gateway. This is
sometimes used in corporate networks, where a single security gateway establishes a SSL tunnel for every
connection coming from the outside, and the FTP server does not need to handle it.
The security mode is configured in the respective field in the Settings configuration. If Implicit, or AUTH_TLS
is selected, a new tab TLS Settings is displayed.
9.6 TLS Client Settings

In order to use TLS, the flag Use TLS has to be set. A new tab TLS is then shown where the TLS settings
can be made.
9.6.1 Server Authentication
9.6.1.1 CA-based Trust Model

The default setting is the CA-based trust model. If the server uses a valid certificate of a well-known CA (i.e.
a CA contained in the system default list of trusted CAs) and the certificate contains the correct server name,
no further settings are necessary. In particular, the server certificate has not to be imported into the BIS
Keystore Manager.
If the certificate is issued by a CA which is not contained in the system default list, the CA certificate must be
imported into a keystore (within the CA section of the BIS Keystore Manager) which is then selected as
custom list of trusted CAs.
Attention: The host name check should never be deactivated, as this effectively switches off server
authentication. The direct trust model should be used instead.
9.6.1.2 Direct Trust Model

The direct trust model should only be used, in one of the following cases:
• The server uses a self-signed certificate.

• The server name in the certificate does not match the actual server name.
• The CA which issued the server certificate is not regarded as trustworthy.
In these cases the server certificate has to be imported into the BIS Keystore Manager. The certificate has to
be validated by comparing the certificate’s hash value with the value obtained from the partner. Several
certificates can be added in order to accommodate a planned switch of the server certificate. They become
effective one after another according to their “Effective From Date & Time”. At each point in time at most one
server certificate is in use (see the book Certificate Rollover for more information on configuration details).

FTP Adapter
9.6.1.3 Client Authentication

In order to configure client certificates, the flag Use client authentication has to be set. One or more client
certificates may then be selected from the BIS Keystore Manager. If several client certificates are configured,
they become effective one after another according to their “Effective From Date & Time”. At each point in time
at most one client certificate is in use. Refer to the topic Configuration in the Certificate Rollover manual for
further details.
9.7 Proxy Mode

The SEEBURGER FTP Adapter supports three kinds of proxy servers: SOCKS, HTTP, and FTP proxies.
Please refer to the topic Proxy Management in the Master Adapter Configuration Guide for more information
about the support and configuration of the SOCKS and the HTTP proxy protocols. All popular FTP proxy
servers types are supported: FTP with login, FTP without login, SITE with login, and OPEN without login.
Note: A Implicit SSL secure connection cannot be used with the FTP proxy servers.
9.8 Scripting
The SEEBURGER FTP Adapter supports the script file execution for the automation of common
communication sequences, or the advanced customization of transfer processes. There are a number of
default scripts that are executed internally, if no script file is specified. A custom script file can be specified in
the sendFile, polling, and processFtp operation details.
There are two ways to specify custom script:
scriptFile field
The scriptfile field is specified with an URI pointing to it. All JVM-handled schemes, like ftp:, http: and
file:, are supported.
Please note that ftp: and http: schemes will use the JVM build-in HTTP, and FTP protocol handlers,
and so their usage is limited to the simplest access scenarios.
Example: The script file on the local file system is specified like: file:c:\del.scp.
script field
If this field is used, the whole script must be specified inside it. The scriptFile field has a higher priority
than the script field. This means, if the scriptFile field is filled, the adapter ignores the field script and
its content. Please note that overwriting the default scripts by specifying custom script could
completely change the behavior of the FTP Adapter.
Attention: The usage of the custom scripts by VAN is strongly discouraged. The reason is that only a
limited number of functions are generally supported on the VAN host systems, and their behavior varies
among the different VAN providers.
In a cluster environment, the script file should be accessible to all the cluster nodes. This can be achieved by
either copying the script file to all cluster nodes, or by storing it in a common location that is accessible by all
cluster nodes.
9.8.1 Script Format

The FTP script contains mainly three parts:

FTP Adapter
• Script begin: This describes the part from the start of the script to the [LOOPSTART] expession. Usually
this part contains the commands needed to establish a FTP connection, e.g. the open command. This
section may not be executed with every task execution. When the FTP connection is established, and the
compatible FTP session exists, the FTP Adapter will not execute the begin section, but only the loop
section for every task.
Note: When the [LOOPSTART] and [LOOPEND] are missing in the script, the script begin section does
not exists, and the FTP will not use the script begin behavior. The whole script is assumed, and is
executed as a loop section!
• Script loop: The script’s part included between [LOOPSTART] and [LOOPEND]. Usually this section
contains the commands defining the FTP processing, exluding commands for connection establishing,
and for disconnecting. This section is executed only once for every task.
Note: If the [LOOPSTART] and [LOOPEND] expressions are missing, the complete script is applied to
the loop!
• Script end: Comprises the lines betwen [LOOPEND] and the last line of the script. Usually this part
contains the commands required for terminating the FTP connection, e.g. the close command. This
section may not be executed with every task execution. When the FTP is instructed by BIS to keep the
connection, this section is not executed!
Note: If the [LOOPSTART] and [LOOPEND] are missing, the script end section does not exists, and
FTP will not apply the script end behavior. The complete script is assumed, and executed as a loop
section!
Below is a list of all the supported commands with their format and possible limitations. Every empty line and
line starting with a ‘!’ character is accepted as comment, and is skipped when executing the script. The
commands are not case sensitive. In this manual we use lowercase, but scripts using uppercase, or mixed
case commands will be executed successfully. Most script commands have a direct mapping to one or more
FTP commands as of RFC959; only commands of the type […] are script execution control commands, and
do not have a direct mapping to FTP commands.
Note: There can be only one command on the same line, and one command can not spread on more
than one line. The command must be in the beginning of the line, followed by its parameters.
The tokens (commands, parameters, arguments …) must be divided by the intervals. If is it necessary to use
intervals, inner tokens, they must be surrounded by quotation marks.
Note: The quotation marks define exactly one token (command, parameter, argument …). They must be
not used inside the tokens.
The definition [@Key=…] is a mapping to a variable, whose value is resolved at runtime from the operation
parameters.
Note: Key names are case sensitive and accept only upper case. There must be no intervals in the
definition [@Key=…].
The definition [@Var=…] is a mapping to a variable, whose value is resolved at runtime from the specificData
key-value type from the request.
Only one “specificData” value for the given [@Var=…] key should exist. If more than one value exists, the first
value will be used.

FTP Adapter
Note: The Var names are case sensitive. There must be no intervals in the definition [@Var=…].
The main difference between the [@Key=…] and the [@Var=…] is that the [@Key=…] is resolved from the
operation parameter in the master data (i.e. it is mapped to an explicitly defined field with operational
meaning), and the [@Var=…] is resolved from the user defined specificData in the request (i.e. it is not
defined in advance, and it does not have an operational meaning).
9.8.2 Commands
Command Effect
open Host Port User Pass This command opens a connection to the specified FTP server with the
specified credentials. This command reads the proxy settings directly, no
overwriting is possible.
type TransferType This command sets the TransferType for the current session. This
command can be used to overcome the limitation of only BIN and ASCII
transfer types established in the GUI. The argument TransferType can be
one of the following:
• A – for ASCII type;

• E – for EBCDIC type(IBM IE only);
• I – for Binary (Image) type;
And other.
[CREATE_LOCK_FILE] File This command creates a zero-sized file, with the specified name on the
FTP server. If the file name is empty, it skips any activity, but does not exit
with error.
[LOOPSTART] These commands together define a section in the script, which will be
executed as a loop. The looping is a logical way to group the transmission
[LOOPEND] of several messages over a single session, or for batch processing. This
will prevent a reconnection overhead and its possible associated cost.
mput HostDir
Attention: The application of the mput with the following server types
is not supported:
- MVS,
- EDISwitch,
- GE MARK III,
- GE MARK 3000,
- IBM IE and
- ECODEX.
This command uploads a file to the hostDir on the remote server. The
wildcard characters ‘*’ and ‘?’ are supported in this command.
Note: This command is supported only in the script that has been
specified in the DtFtpSendFileRequest and DtFtpProcessRequest
(i.e. the sendFile and processFtp operations).

FTP Adapter
Command Effect
put attachmentId HostDir This command extracts the attachment, which corresponds to the
attachmentId in the task, and uploads it to the hostDir on the remote
server. The specification of attachmentId is optional. If it has not been
specified in the uploaded file, the first attachment in the task will be
applied.
If more than one attachment is sent via one script, it is strongly

recommended to use the attachmentId parameter in every put command in
the script. There is no guarantee in this case, that the put command
without this argument will upload the desired attachment.
The wildcard characters ‘*’ and ‘?’ are not permitted.
specified over the DtFtpSendFileRequest and DtFtpProcessRequest
parameters (i.e. the sendFile and processFtp operations).
mget HostDir This command downloads the specified HostDir from the remote FTP
server.
For this command wildcard characters ‘*’ and ‘?’ are supported in the
filename part of the HostDir. If the symbols ‘*’ and ‘?’ are used in the path
part of the HostDir, they will be not interpreted as wildcards. If wildcards
are used, and no matching files are found, the command finishes without
error. If wildcards are not used and the specified file is not found, an error
will occur. The mget without wildcards has a similar behavior to get and
should be replaced with get command in such cases.
Note: If the Delete file option is selected, the downloaded files will be
deleted immediately after the execution of the mget command. If it is
required to download the same files several times in one script and to
delete them after that, the Delete file option must not be used.
Instead, the last mget must be followed by the delete command.
specified in the DtFtpPollingRequest and DtFtpProcessRequest
parameters (i.e. the polling and processFtp operations).

FTP Adapter
Command Effect
rmget HostDir This command downloads the specified HostDir from the remote FTP
server.
Note: This command is supported only for the standard server type.
For this command, the wildcard characters ‘*’ and ‘?’ are supported both in
the filename, and in the path part of the HostDir. If the symbols ‘*’ and ‘?’
are used in the path part of the HostDir, they will be interpreted as
wildcards. If the wildcards are used and no matching files are found, the
command finishes without error. If the wildcards are not used, and the
specified file is not found, an error will occur.
The specification of the rmget parameter without the wildcards in the path
part of the HostDir leads to a similar behavior as mget, and should be
replaced with mget in this case.
deleted immediately after execution of the rmget command. If it is
required to download the same files several times in one script and to
delete them after that, the Delete file option must not be used.
Instead, the last rmget must be followed by the delete command.
get HostDir @=response This command downloads the specified HostDir from the remote FTP
server. The argument @=response is optional. If it is specified, the result
of the command (downloaded file and file details) is added to the
response, instead of new message generation. The wildcard characters ‘*’
and ‘?’ are not permitted. If the specified file is not found, an error will
occur.
deleted immediately after the get command. If it is required to
download the same files several times in one script and to delete
them after that, the Delete file option must not be used. Instead, the
last get must be followed by the delete command.
copy Source Destination This command copies the file on the FTP server side.
Source – The file that has to be copied (Specify path and file name!).
Destination – The path and the file name for the destination file.
The source file will be downloaded (as a temporary file) and uploaded. The
current append mode does not have any meaning for this command. The
overwrite mode will be forced. The current FTP server transfer mode will
be used. To ensure the transfer mode, you can set it in advance with the
type command. The wildcard characters ‘*’ and ‘?’ are not permitted. If the
source file is not found, an error will occur.

FTP Adapter
Command Effect
quote This command sends the QuoteString as quote command to the FTP
[VALID.RESPONSE.CODES= server. The section [VALID.RESPONSE.CODES=…] can be used to set
…] QuoteString which codes to expect in the result of the execution of the QuoteString.
With them the SEEBURGER FTP Adapter validates the code that the FTP
server returns. This section is case-sensitive, only upper case and no
intervals are allowed.
Note: The valid response codes must have exactly 3-digits size, and
must be separated by a comma. The character X can be used as a
wildcard (only in upper case spelling).
Example:
quote [VALID.RESPONSE.CODES=21X,421,450] stat
The section [VALID.RESPONSE.CODES=…] is not mandatory. If it does

not exist, the SEEBURGER FTP Adapter will accept the following codes:
125, 150, 2XX, 33X and 350.
delete File This command deletes a specified file from the remote FTP server. The
wildcard characters ‘*’ and ‘?’ can be used in the file name. If the file name
is empty, or there is no such file on the server, the command finishes
without error. Before deleting, the FTP Adapter executes the list command
to ensure the deletion of the correct files.
cwd Dir This command changes the working directory to Dir.
[IF_NOT_EXIST] File This command checks whether a specified file exists on the remote FTP
ScriptCommand server and executes the ScriptCommand correspondingly.
[IF_ EXIST] File

ScriptCommand
[IF_EQUAL] value1 value2 This command compares value1 and value2. If they are equal, the
ScriptCommand command executes the specified command. (Case comparison is ignored).
[STOPSUCCESS] This command breaks the script execution with a successDescription
SuccessDescription message. The description can also contain [@Key=…] or [@Var=…]
mappings.
Note: Breaks only the script part (script begin, script loop, or script
end) in which it is executed.
We discourage using the command [STOPSUCESS] outside of a loop

section.
[STOPERROR] This command aborts the script execution with error. The description can
ErrorDescription also contain [@Key=…] or [@Var=….] mappings.
close This command closes the connection to the remote FTP server.

FTP Adapter
Command Effect
PROT ProtectionLevel This command sets the data channel protection level that will be used from
both the client and the server in their transfer. The default protection level
is C (Clear). When using the implicit SSL security mode, the protection
level should be explicitly set to P (Private).
The ProtectionLevel can have the following values:
• C – Clear
• S – Safe
• E – Confidential
• P – Private
Attention: Using a protection level different from C (Clear) with the

Security mode Clear may cause the connection to abort.
Note: The protection levels S (Safe) and E (Confidential) may not be

supported by any FTP server. If the server cannot interpret the
specified protection level, it will respond with reply code 504.
set ClientKey=TRUE|FALSE This command sets the specific client side flags that allow modifying the
internal FTP client execution flow. The ClientKey can only have the values
TRUE or FALSE. There must be no blanks between the key and its
assigned value. For a list of supported client keys and their meaning,
please refer to the topic Client Side Keys (page 38) .
9.8.3 Keys
All keys are resolved from the operation parameters.

FTP Adapter
Key Comment
[@Key=HOSTDIR] Resolved from the HostDir field. Please check the HostDir syntax topic
further on.
[@Key=LOCKFILE] Resolved from the Lock File field.
[@Key=HOST] Resolved from the Host name field.
[@Key=MASK] Resolved from the Mask field.
[@Key=PORT] Resolved from the Host port field.
[@Key=USER] Resolved from the User name field.
[@Key=PASS] Resolved from the User pass field.
[@Key=TRANSFERTYPE] Resolved from the Transfer type field.
[@Key=MVS.LRECL] Resolved from the LRECL field in the MVS settings.
[@Key=MVS.BLKSIZE] Resolved from the BLKSIZE field in the MVS settings.
[@Key=MVS.RECFM] Resolved from the RECFM field in the MVS settings.
[@Key=EBMX.SENDER.ID] Resolved from the Sender ID field in the EBMX ANX settings.
[@Key=EBMX.SENDER.PASS Resolved from the Sender Pass field in the EBMX ANX settings.
]
[@Key=EBMX.RECEIVER.ID] Resolved from the Receiver ID field in the EBMX ANX settings.
[@Key=EBMX.FILE.TYPE] Resolved from the File Type field in the EBMX ANX settings.
[@Key=BAAN.CONTROL.FILE Resolved from the Control File ID field in the BAAN settings.
.ID]
[@Key=BAAN.DELETE.CONT Resolved from the Delete control file field in the BAAN settings.
ROL.FILE]
[@Key=BAAN.FROM] Resolved from the From field in the BAAN settings.
[@Key=BAAN.TO] Resolved from the To field in the BAAN settings.
[@Key=IMPLICITSSL] Resolved from the Security mode settings. Get the value TRUE or FALSE
depending on the implicit SSL usage.
Examples:
This is the default Send script, used by the Standard FTP and all non-VAN server types.
!SEND_MESSAGE default script file

open [@Key=HOST] [@Key=PORT] [@Key=USER] [@Key=PASS]
[LOOPSTART]
type [@Key=TRANSFERTYPE]
[CREATE_LOCK_FILE] [@Key=LOCKFILE]
mput [@Key=HOSTDIR]
delete [@Key=LOCKFILE]
[LOOPEND]
close
This is a modified Send script file, which enables EDI files using aliases in IBMIE.

FTP Adapter
!SEND_MESSAGE custom script for IBMIE – edi file with aliases

quote site probe 1
quote site edialiasonly 1
[LOOPSTART]
put [@Key=HOSTDIR]
[LOOPEND]
close
This is the default Poll script, used by Standard FTP and all non-VAN server types:
!POLL_MESSAGE default script file

[LOOPSTART]
[IF_EQUAL] [@Key=IMPLICITSSL] "TRUE" PROT P
[IF_EXIST] [@Key=LOCKFILE] [STOPERROR] "Lock file [@Key=LOCKFILE] exist"
mget [@Key=HOSTDIR]
[LOOPEND]
close
This is modified Poll script file that enables EDI files using aliases in IBMIE.
!POLL_MESSAGE custom script for IBMIE – edi file with aliases

quote site probe 1
quote site edialiasonly 1
[LOOPSTART]
mget [@Key=HOSTDIR]
[LOOPEND]
close
9.8.4 Client-Side Keys
Attention: The client side keys are case sensitive! They must always be written in UPPER_CASE and
they can only take the values TRUE or FALSE. There must be no blanks between the key and the
assigned value.
The following keys are supported by the SET command:

FTP Adapter
Key Description
GET_GEMARK_REPORTS
Note: This key will only take effect on the GE MARK III and the GE
MARK 3000 server types. It must be used in the script that is
specified in the DtFtpPollingRequest parameter (i.e. the polling
operation).
If this client side key is used in a custom script, it will determine either to
download or not the reports from the VAN box. If
GET_GEMARK_REPORTS=TRUE is added to the script, but no reports
are requested via the master data (FTP Connections) or
DtFtpSendFileRequest, this script command will not have any effect.
DISABLE_LIST_BEFORE_GE
T Note: This key will only take effect on the standard server types and it
must be used in the script that is specified in the DtFtpPollingRequest
parameter (i.e. polling operation).
If this client side key is used in a custom script, it disables/enables the

internal FTP mechanism to perform a LIST command before the GET
command. Please be aware that it must be used only with the GET
command and a correctly specified file name. If
DISABLE_LIST_BEFORE_GET=TRUE is added to the script, the
presence of the file cannot be warranted.
DISABLE_OS400_FILENAME
_CUT Note: This key will only take effect on the OS/400 server types, and it
must be used in the script that is specified in the
DtFtpSendFileRequest parameter (i.e. sendFile operation).
Because of the database structure of OS/400 server types, it is known that

a limitation of the file name exists. The file name must be constructed at
maximum by 10 characters for a name and 10 characters for a file
extension. For more information see the topic Server Types (page 50) in
this guide. The FTP adapter checks and modifies file names to send files
with the correct names. If DISABLE_OS400_FILENAME_CUT=TRUE is
added to the script, the FTP adapter will no longer check and modify the
file name. Please use this key only after verifying that your server supports
more than 10 characters.
9.8.5 Script Validator

The FTP adapter has been extended with a script validator which allows you to see errors on a custom script
before its execution. By default the script validator is enabled. To disable it, use the Adapter Control Center
Configuration tab for the FTP Client. In the nodeConfiguration box, change the value of the ScriptValidator
property.
It is possible that the ScriptValidator property is missing in case of a system upgrade. To add this property do
the following:
1. Export the adapter specific config files. For FTP, this is com.seeburger.jftp-config.xml
2. Open the file with any text editor and add this line to node with name nodeConfiguration
<property name="ScriptValidator" type="java.lang.Boolean">true</property>
After changes, the complete node properties must be as follows:

FTP Adapter
<node name="nodeConfiguration">
<property name="ScriptValidator" type="java.lang.Boolean">true</property>
<property name="ForceImmediateInitiation" type="java.lang.Boolean">true</property>
<property name="TransmissionTimeout">120000</property>
<property name="UseMessageIdStore" type="java.lang.Boolean">true</property>
</node>
3. Import the config files and restart/reload the FTP Client.
After completing these steps, the property will be available for changes also in the Adapter Control Center.
9.8.6 Transaction Ability

The transaction safety of the FTP Adapter depends on the script that is used.
This is an example of an insecure transaction:
The script contains a get HostDir @=response command, followed by other commands, and the Delete file
option is used in the master data. After successful downloading, the files will be deleted from the server. If
one of the next commands fails, on the next script execution (caused by the retry mechanism), the get
command will no longer download the files, since they were already deleted.
Note: The transaction safety of the FTP operations is not guaranteed, if the script that is used, is not
well designed to be transactional, or it is not suitable with the master data configuration.
9.9 Temp File

The temp can be used when Append mode is OVERWRITE or UNIQUE . When Use Temp file is selected,
the SEEBURGER FTP Adapter uses the temp file for uploading. When the temp file is uploaded, it is
renamed to the target name. If the Use Temp file is selected and if the Append mode is OVERWRITE, and a
file exists with same name, it is deleted and then the temp file is renamed to the target name. If the Use
Temp file is selected, and if the Append mode is UNIQUE, the FTP server folder is listed a second time for
the file with the same name, after the temp file is uploaded. And if such a file exists, an error will be returned.
9.10 List Settings (Charset, Locale, NLST and Custom Pattern)

There are cases when the FTP server is running on a system that uses different and/or non-US/US-ASCII
locale and character sets. The most common case is that a FTP adapter that is installed on a system using
the US locale (or compatible) tries to communicate with a FTP server that is installed on a machine with
another locale (Western European (e.g. DE, FR, …) Cyrillic, or Far-east, etc.). This scenario involves two
settings: The character set and the local language.
If the adapter and the FTP server are running on systems that use different locale settings with the same (or
similar) character sets (e.g. the adapter with US locale, and the server on DE, FR locale), no
system-dependent strings may be recognized used in LIST command results (month name, …). Or, no such
will be available respectively. If necessary, this problem can be resolved by specifying the locale with Locale
Language in the FTP Adapter's connection settings.
The locale languages are defined in the ISO-639 standard. You can find a full list of these codes at a number
of sites, such as: http://www.ics.uci.edu/pup/ietf/http/related/iso639.txt. The variant is vendor-specific. To
enable the use of this locale, the respective locale resource bundle should be installed on the JVM that is
used by the FTP Adapter. If no such is present, the default locale will be used.
Independent from the locale, if the adapter and the FTP server use different character sets, a file name on
the server may use a character that is not recognized when the file name string is processed by the FTP
Adapter. This is the case when the FTP Adapter connects to a Cyrillic or Far-eastern system. Then, the LIST

FTP Adapter
command will fail again, because the input line reader will not be able to recognize the characters. One
solution to this problem is the explicit specification (in the FTP Connection Settings) of the character set that
is used for parsing the LIST command result.
Only character sets that are supported and installed should be specified. Otherwise, the default value will be
used.
9.10.1 Simplified Listing

There are cases when the LIST command is used for listing the directory on POLL and the LIST operation
fails.
The most common reason could be a non-standard and/or a non-supported LIST command result format.
This could be caused by the FTP server running on a platform that is not directly supported by the FTP
Adapter (old mainframe, old UNIX variant …) or by a FTP server that does not comply with a known LIST
result format (some DOS servers). One possibility to support such FTP servers is the use of the NLST
command according to RFC950. This command has the same purpose – it lists the current directory but has
a defined, simple result format that consists of a single file name per line. The FTP Adapter can be
configured to use this LIST command by using the NLST command field in the FTP Adapter's Connection
Settings.
There are several implications of the usage that should be regarded:
• As the list format is very simple and contains only a file name, no additional file information will be
available in the Send operation response and the NewFile and NewReport request XML files.
• Some servers (e.g Microsoft's FTP server included in IIS) have a non-compliant behavior, and return not
only the file names, but also the sub-directory names. There is no way to automatically recognize and
filter them, because no dir flag is present. Therefore the use of the upload/download file dialog is
strongly recommended.
9.10.2 Custom Pattern

There is an option to specify custom patterns for parsing the list result from the FTP server.
Note: This pattern must match only download-able files from the list result. It does not have to match
directories.
The custom pattern is a regular expression that must keep the syntax described in the documentation for the
Pattern class - see http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html.
In addition, this syntax has the following extensions:
Extension Meaning
#n…n# This section represents the file name. It is mandatory. The “#n” and “n#”
must surround the pattern’s part, which matches the file name. The FTP
Adapter will try to download the file with the name, in result from the list
matching with this part of the pattern.
#d…d# This section represents the file date. It is optional. The “#d” and “d#” must
surround the pattern’s part, which matches the file date.
#s…s# This section represents the file size. It is optional. The “#s” and “s#” must
surround the pattern’s part, which matches the file size
There are two fields for the custom patterns:
• Custom list pattern for the whole pattern.

FTP Adapter
• Custom date pattern should be specified if Custom list pattern is usedin the “#d…d#” section. The syntax
for date pattern is described in the documentation for SimpleDateFormat class -
http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html
Example 1
Server listing:
rw-r--r-- 1 ftp ftp 141312 Feb 23 15:27 j1299LV8N5.test

rw-r--r-- 1 ftp ftp 7 Feb 17 09:43 j69GOMTZT2.see
rw-r--r-- 1 ftp ftp 181162 Feb 28 17:42 jJU57M76NH.test
Custom list pattern:
\s*-[rwx-]{9}\s+\d+\s+\S+\s+\S*\s+#s\d+s#\s+#d\w+\s+\d+\s+\S+d#\s+#n.+n#\s*
Custom date pattern:
MMM dd HH:mm
Example 2
Server listing:
02-20-06 11:01AM 2315 j532WAF3D5.see

02-20-06 11:02AM 4 jP6OLBWJLN.see
02-21-06 10:27AM 141312 jRN9JHWF44.see
10-28-05 03:07PM 7 jT6J4RD3YO.ggg
Variant 1:
\S+\s+\S+\s+\d+\s+#n.+n#
Empty
Variant 2:
#d[\d-]{8}d#\s{2}\S+\s+#s\d+s#\s+#n.+n#
MM-dd-yy
Variant 3:

FTP Adapter
#d\S+\s+\S+d#\s+#s\d+s#\s+#n.+n#
MM-dd-yy hh:mm
9.11 IP Address Caching/Dynamic IP Address Usage

All TCP-based adapters can be configured to establish a connection to a remote host either over its IP
address or its host name.
If the host name is used, this name is resolved to an IP address using a combination of local machine
configuration information and network naming services, e.g. Domain Name System (DNS) or Network
Information Service (NIS).
In the Java VM, positive and negative name resolutions are cached. The positive results of a name
resolution are permanently cached, since there is no generally applicable rule to decide whether or when a
cache entry can be safely removed. The purpose of positive address caching is prevention of DNS spoofing
attacks.
Attention: Generally, it is not recommended changing the timeout values for positive caching unless the
system is operated in an environment which excludes DNS spoofing.
Note: The positive caching of IP addresses can be configured over the Java security property
networkaddress.cache.ttl (default: -1).
The negative caching is configured over networkaddress.cache.negative.ttl (default: 10).
These properties can be set in the file <JavaVM_home>/jre/lib/security/java.security. (VM
vendor-specific properties might apply for setting this timeout by command line arguments.)
Positive caching may cause problems if the communication partner is addressed over a host name and
changes the IP address. (E.g. for moving its host to a new provider or using a host which is assigned a new
IP address dynamically and periodically).
The Java VM will not be notified about this change, since the positive IP address resolution results are
permanently cached.
The only solution to initialize the cache again is to restart the Java VM. I.e. the Java VM of the JBoss central
instance or the external Tomcat node will have to be restarted.
The communication with partners who use dynamic IP addresses is not supported. (This would require
periodic Java VM restarts).

FTP Adapter
10 Adapter Configuration
The SEEBURGER FTP Adapter has some advanced configuration capabilities that could be used to
fine-tune the adapter. All general configuration parameters for SEEBURGER adapters are described in the
Master Adapter Configuration Guide. Below some FTP Adapter specific parameters are described . They are
configured by altering the SeeConfig XML file for the FTP Adapter that is available in <bis_home>
\conf\SeeConfig\{com.seeburger.conf.user=BISAS}\ com.seeburger.jftp-config.xml file. All FTP Adapter
specific settings are available under the nodeConfiguration node.
Note:Please be careful to uncomment only the parameters that are necessary, as those configuration
settings overwrite the default used in the FTP Adapter, and could influence the FTP Adapter operation
significantly.
10.1 Timeout Setting

In case the communication regularly interrupts with a connection timeout, or a communication drop, a
timeout value can be specified using the following configuration parameter: <proper ty
name=”TransmissionTimeout”>60000</property> Shown is the default value. The value is set in milliseconds.
Change it respectively, and restart the adapter to enable it. This timeout value will be used in all socket
communication operations – connect(), read(), bind().
10.2 Dumping
The SEEBURGER FTP Adapter has the capability to dump the whole communication between it and the
FTP server at wire level in a text file, called the dump file. This file includes the binary and the ASCII decoded
data, all the data exchanged over the control and data connection, before the data encryption, and without
the proxy connection sequences. (the FTP proxy type communication is available only as this is inherent to
the control channel FTP communication). The dumping is configured with the following parameters:
<node name="DumpHandler">
<property name="EnableDumpWrite">false</property>
<node name="com.seeburger.jftp.app.dump.impl.FileDumpWriter">
<property name="FileMaxSize">10000000</property>
<property name="MaxCount">10</property>
</node>
</node>
To enable the dumping, change the EnableDumpWrite property to true. The dump file will be available in the
<bis_home>/data/dt/ftp/dump directory, with the name ftp.index.dump where the index is 0 to MaxCount-1.
Up to the MaxCount file will be available, each up to the FileMaxSize (default 10MB) bytes long. They are
overwritten on a round-robin base.

FTP Adapter
Please be careful with dumping. It should be used only on non-productive systems, when especially low-level
debugging is required. Dumping loads the system heavily, especially if high communication speed is used.
Also dump files could grow especially large, and could saturate the system's free disc space.
10.3 Logging
For further information about the configuration logging please refer to the topic Logging/Tracing/Dumping in
the Master Adapter Configuration Guide.

FTP Adapter
11 Adapter Interactions
Common Information
Interactions can be used to test the adapter, the configured master data, and the partner communication,
without creating a special business process. For example you can send a test file to the partner, or poll its
mailbox to see if the connection works. The interactions do not support any queuing (WLH) or resources.
The state of the interaction can be monitored as a result in the interactions form and not in the BIS Inspector.
Description of the common form attributes:
Attribute Description
Number of executions Configures how often an interaction is executed after the button Executed
is clicked. Default is 1.
Number of parallel executions Configures how many interactions are executed parallel. This can be used
for testing parallel transmission of files for example. The default value is 1.
The maximum parallel execution is 30.
Persist details If this flag is enabled, all information about the request and the response
will be available for monitoring. Also the request and response
attachments will be available to show.
If the flag is disabled, no information is available after the interaction is
finished. Only the protocol is shown, which states which interaction was
finished successfully and which not.
Displayed details for interaction Shows the number of the interaction for which the Request/Response tab
number is shown.
New button Creates a new interaction.
Execute button Starts the execution of the interaction.
Stop button Click this button to cancel all scheduled interactions. The running
interaction will run until it is finished, but no new one will be started.
Request tab Shows the request which is forwarded to the adapter.
Response tab Shows the response the interaction got from the adapter
Protocol tab Shows which interaction was finished successfully, and which was finished
with an error.
Using the context menu the Request/Response details can be shown.
Supported interactions:

FTP Adapter
Interaction Description
Get file Download a specified file from the FTP server.
List File listing of FTP server directory.
Poll messages Poll all messages matching a configured mask from a FTP server
directory.
Send message Sends a file to FTP server.
Description of the form fields:
Attribute Description
Get File
FTP address Configured FTP address master data.
FTP connection Configured FTP connection master data.
Remote file The absolute remote path of the file which will be downloaded.
List
Poll Messages
Send message
Path to file Complete path to the file which will be uploaded.
remote path The remote path of the file, user specific relative path.
Remote file The remote file name.

FTP Adapter
12 Troubleshooting
Message Cause
com.seeburger.jftp.app.exception.FtpExceptionConnectionError: Error • The host name or the IP
while connection to remote host address of the FTP server
is not correct.
com.seeburger.jftp.app.exception.FtpExceptionConnectionError: Error • The port of the FTP server
while opening control socket is not correct.
• The FTP server is not
com.seeburger.jftp.app.exception.FtpExceptionConnectionError: running.
Unable to connect to: /<host>:portjava.net.ConnectException: Connection
timed out • A firewall blocks the
communication with the
FTP server.
java.net.SocketException: Connection timed out
• There is not enough
transmission timeout – for
an increase check the
Timeout Settings.
java.net.UnknownHostException • This is the wrong host
name or the wrong IP
address.
com.seeburger.jftp.app.exception.FtpExceptionConfigurationError: Error • You may have not filled the
while reading MasterData fields destinationAddressId,
or connectionId in the
com.seeburger.jftp.app.exception.FtpExceptionConfigurationError: Partner request, or have entered
data not found in Database for addressID: incorrect IDs.
08a600c0-1bad-11da-b5e8-e8a70a0a12c9
com.seeburger.jftp.app.exception.FtpExceptionConfigurationError: Partner
data not found in Database for connectionID:
3c50c770-1bad-11da-b5e8-e8a70a0a12c9

FTP Adapter
Message Cause
com.seeburger.jftp.app.exception.FtpExceptionSoftProcessingError: • Check the baseDir,
Unexpected reply: relativePath, and the mask.
550 /anonymous_user/j4LP9K9FRK.see: The system cannot find the path • Check if the hostDir path
specified.
exists. Some servers return
reply 550, if you try to
com.seeburger.jftp.app.exception.FtpExceptionSoftProcessingError: upload files to an unexisting
Unexpected reply: 550 /FtpTest??: Cannot create file directory.
• Check which encoding the
com.seeburger.jftp.app.exception.FtpExceptionSoftProcessingError:
FTP server uses for
Unexpected reply: 550 Filename invalid
communication, and correct
it in the character set field.
Please refer to the List
Settings topic for details.

FTP Adapter
13 Server Type Configuration
13.1 Standard FTP (UNIX, DOS, OS/400)

The SEEBURGER’s FTP Adapter supports standard FTP servers operation according to RFC959. All
available options are supported, as Upload case, Use Temp File, Delete on Download, and so on. IMPLICIT
and AUTH_TLS encrypted connections are supported, with or without host authentication.
The following list formats are supported:
• Unix L8
• MS-Unix
• MS-DOS (IIS and the integrated Windows-based FTP server)
• OS400
Examples of List formats:
Unix
drwxr-xr-x 2 test testserver.com 48 Jul 6 2001 testdir

-rw-r--r-- 1 test testserver.com 30023 Jul 10 2001 testfile.txt
MS-Unix
drwxrwxrwx 1 owner group 0 Jan 3 10:16 testdir

-rwxrwxrwx 1 owner group 6 Jan 2 12:57 testfile.txt
MS-DOS
01-02-03 01:50PM <DIR> testdir

01-02-03 12:57PM 1286 testfile.txt
OS/400 (i5/OS)
The OS/400 FTP server holds files in the database organization, where the directories are called libraries.
The libraries structure is plain, i.e. all libraries are accessible from the root directory. I.e. HostDir can contain
maximum one library. The library name is limited to 10 characters. A special feature for the OS/400 host
system (OS/400 FTP server) is available to limit the upload file name to 10 characters, plus a 10-character
extension, because the AS400 file system has this limitation. Uploaded files with the same file name, but
different extensions forms on the OS/400 FTP result in a single file with many members.

FTP Adapter
Note: For the OS/400 FTP server, the SEEBURGER FTP Adapter supports Delete only for the file
members, not for the files!
For OS/400 FTP servers, the FTP Adapter works on file object members ( *MEM ) and stream files ( *STMF
).
Note: Please note that with standard FTP, HostDir must contain the dir path on the server and should
not be left empty. If the root directory is accessed, it must be specified explicitly with the respective
character: “\” or “/” depending on the host system's OS conventions. This is required, because some
FTP servers, especially MSDOS-based ones, do not accept the STOR and RETR commands that
contain only a file name, but require the path and file name to be specified explicitly.
13.2 HPUX
The SEEBURGER FTP Adapter supports the HPUX FTP servers. This FTP server operation is very similar
to the Standard FTP server. All options are supported, the list format is UNIX, and so any new file messages,
resulting from Poll operations will have the <unixFileDetails> element. The only non-standard feature of
HPUX FTP server is that an empty list command is not supported. Such a command could be issued, if the
HostDir in the Poll channel is left empty. In this case, the empty string will be replaced with PWD command
result.
The adapter is tested and proved to work correctly with the recent version of the HPUX (FTP server version
1.214.4 Wed Aug 2000). It is possibly that some older versions of the HPUX could have some specialties,
particularly the LIST command result format, that is not supported currently in this FTP Adapter.
13.3 Amazon
The SEEBURGER FTP Adapter supports the Amazon FTP server. This FTP server operation is very similar
to the Standard FTP server, but a special trigger file must be processed together with the actual data file.
The trigger file is file that contains the single character ‘.’, has the name of the data file, and a specific
extension that is .done by default. Another extension could be specified in the channel.
13.3.1 Send Operation

On upload (Send), after uploading the data file, the trigger file is also uploaded in the same directory. The
name of the data file is prepared as described in HostDir Syntax (page 25) topic.
13.3.2 Poll Operation

On download (Poll), the list of available data files is additionally filtered, and only files that have
corresponding trigger files are selected and downloaded.
Attention: Avoid specifying a mask in the HostDir that will filter out the trigger files.
Otherwise, no files will be downloaded at all.
All other options are supported except of the Delete on Download option. The downloaded file and its
corresponding trigger file are always deleted, irrespective of this setting.

FTP Adapter
13.4 MVS
The SEEBURGER FTP Adapter supports the MVS FTP server. This FTP server lacks all advanced host path
handling capabilities of the standard FTP server since it has a quite different file system.
• On upload, the HostDir must explicitly specify the file name.

• On download, only the path name must be specified. It is directly used in the LIST command issued to
the server.
Note: All options are supported except:

- Use Temp File,
- Upload Case,
- and the script command mput.
There are three additional message properties in the receiver channel configuration only, intended specially
for the MVS server type.
Property Description
RECL This is the record length to be used, it should be a multiple of 360.
BLKSIZE This is the block size used for IO operations buffering, the same value as
the RECL is suggested as IBM/MVS uses unblocked, fixed length records.
RECFM This is the record format, please check the IBM/MVS manual for details.
On connection establishment, their values are used to initialize the session context by issuing three quote
site <RECL|BLKSIZE|RECFM>=<field value> commands.
13.5 Novell
The SEEBURGER FTP Adapter supports the Novell FTP server. This FTP server operation is very similar to
the Standard FTP server with the only exception being the quite non-standard list format. That is why the
FTP Adapter does a simplified parsing of the LIST command result, and extracts only the file name. All
options are fully supported.
13.6 BAAN
The SEEBURGER FTP Adapter supports the BAAN FTP server. This FTP server type is quite similar to the
standard FTP server in terms of the FTP-related functionality, but has some more complicated operation
sequences. The exchange sequence is implemented as a default script only for the processFtp operation
with the BAAN server type. If required, this script can be used as a basis for a user script that extends the
exchange sequence. For details on the script file, please refer to the Scripting (page 30) topic.
Note: The following options are not supported:

- Lock File,
- Use Temp File,
- Upload Case,
- Delete on Download.
All other options are completely supported.
Operation Sequence
1. Connect to the BAAN FTP server.

FTP Adapter
2. Set the transfer type.

3. Check whether the specified control file exists on the server, quit with success if not.
4. Upload the file to the upload directory, if an attachment is included in the request.
5. Download all data from the download directory.
6. Delete the control file, if required.
7. Close the connection.
Additional Message Properties
There are several additional message properties in the channel configuration, intended specially for the
BAAN server type.
Property Description
Control file name This is the path name of the control file.
From path This is path where to search for new files to download. It must contain the
filename (with or without wildcards).
To path This is the path where to place uploaded files. It must contain the filename
(with or without wildcards).
Delete control file Specifies whether to delete the control file.
13.7 EBMX_ANX
The SEEBURGER FTP Adapter supports the DaimlerChrysler EBMX ANX/FTP gateway. The EBMX/ANX is
a DaimlerChrysler corporate information system that has a FTP gateway for the Trading Partner (TP)
communication. The FTP Adapter is a specialized FTP client (no FTP server functionality) and supports the
TP-to-ANX part of the FTP Push over ANX scenario, and the complete FTP Poll (Mailbox) scenario. Both
real-time and batch transactions are supported.

The Send operation, also called submission is an ordinary FTP upload of single file, followed by the
dcxsubmit command, containing the necessary upload parameters. The parameters are used to initiate a
DCX submission operation. The parameters are as follows:
Sender ID This is the sender identification, assigned by the EBMX administration. It is
resolved from the server specific Sender ID field.
Sender pass This is the sender's password assigned by the EBMX administration. It is
resolved from the server specific Sender password field.
Receiver ID This is the receiver identification, check operation matrix below. It is
resolved from the server specific Receiver ID field.
File name This is the name of the file placed on the host system. It is resolved from
the Mask field.
File type This is the file type, check operation matrix below. It is resolved from the
server specific File type field.

FTP Adapter
Real Time
SenderID ReceiverID File type

ASN/ASC(865) CHASE EDIX12
STARS 214 STARS EDIX12
Batch
SenderID ReceiverID File type

EDI EDI EDIX12
VISTA 510, 520, 530, 540, 550, VISTA EDIX12
630
VISTA 127 VISTA PHOLD
VICS 824, 926, 928, 997 VICS EDIX12
Loop-Back test LOOPTEST LOOPBACK
Note: EBMX is known not to process ASN/ASC transactions larger than 300kB. If you have a larger
transaction, please split it to several smaller transactions under this size, or it will fail with the following
error message: File not processed. Max. file size 300K limit exceeded.
On a successful Send, the response part will contain the following members:
Member Meaning
remoteFileName No meaning
messageId Tracking ID

No specific information is available for the Poll operation. Please consult the EBMX user documentation
and/or DaimlerChrysler for any further details.
Note: Lock File, Upload Case, Append mode, and Use Temp File”options do not have any meaning with
EBMX/ANX, and should not be used. All other options can be specified if necessary.
13.8 EDISwitch (Ford Solmis)

The SEEBURGER FTP Adapter supports the Enterprise/EDISwitch FTP server and the Ford Solmis/GEC
Hub FTP server as a single server type due to their similarity. EDISwitch is an FTP gateway to the EDISwitch
TIP server that delivers the data to the user mailboxes.
EDISwitch accepts and processes:
• EDI data.
• Non-EDI data – unformatted or binary (type ASCII or BINARY).

FTP Adapter

To Send a file to a partner, you need to specify the partnerID in the HostDir. The partner ID is usually called
trading relationship in the EDISwitch. The following syntax should be used: “%recv%aprf%snrf%type” where:
Syntax Description
recv This syntax is the receiver mailbox name.
aprf This syntax is the application reference (optional).
snrf This syntax is the sender reference number (optional).
type This syntax is the data type where you can select ‘b’ for binary data and ‘e’
for EDI data.
If you send an edifact document, the parameters recv, aprf, snrf will be extracted from edifact by the
EDISwitch. I.e. in the HostDir field you can specify: %%%%e.
If you send a binary document, you can specify in the HostDir : %<recv >%%%b, if the <recv> is the receiver
mailbox name.
Note: In some countries EDISwitch is used as a bridge to TRADANET. In this case all parameters (recv,
aprf, snrf, and type) are mandatory and must be set.
On successful Send, the response part will contains the following members:
remoteFileName This parameter has no meaning.
messageId This parameter contains the service reference number.

To download some items from your EDISwitch mailbox, you need to configure a Poll operation and specify
what you want to download in the HostDir. You can also select specific messages to download using the
following syntax:
Syntax Description
“” This syntax will download all not extracted items.
serviceref (must contain only This syntax will download the non-extracted item with the specified service
digits) reference number.
%sender This syntax will download all non-extracted items with this sender.
%sender%aprf This syntax will download all non-extracted items with this sender and this
application reference.
%%aprf This syntax will download first non-extracted items with this application
reference.
All other cases This syntax will download all non-extracted items.
On successful download, the request part of the new message will contain the following parameters:

FTP Adapter
remoteFileName This parameter contains the service reference.
fileSize This parameter has no meaning.
creationTime This parameter has no meaning.
senderID This parameter contains the sender ID.
senderRef This parameter contains the sender reference.
applicationRef This parameter contains the application reference.
13.8.3 Advanced
EDISwitch provides an option to change the password using the following syntax in the password field:
current/new/new (where current is the current password and new is the new password repeated twice). All
elements are separated by a slash. Please do not forget to change the password field to the new
password immediately after successful modification. Otherwise, your session will fail, because the password
was already changed.
Note: The Lock File, Upload Case, Use Temp File options and the script command mput are irrelevant
for EDISwitch and should not be used. All other options can be specified, if necessary.
Ford Solmis/GEC Hub uses the EDISwitch technology, but posts some limitation like:
• Using only active-mode FTP transfer.

• Accepting only EDI ANSI X12 files in ASCII mode.
• Specific mapping from the EDI data field for the SenderID.
• Application reference.
Please refer to the Ford Solmis documentation before establishing the communication.
13.9 Sterling Commerce
13.9.1 General Operation

The SEEBURGER FTP Adapter supports the Sterling Commerce FTP server type. Sterling Commerce FTP
is a gateway to the COMMERCE::Network VAN network. The Sterling Commerce FTP server complies with
the RFC950, but the communication over the Sterling Commerce FTP gateway has some limitation that are
described below:
• All data transfer must use the ASCII transfer mode.

• Only EDI data files are exchanged. Non-EDI files should be wrapped in the Sterling’s private header and
trailers. For further information, please refer to your COMMERCE:Network manual.
• The exchanged EDI files can contain, or can miss embedded CR/LF separators, By default the Sterling
Commerce expects CR/LF in the data stream, and will embed them in the received files. This behavior
can be overridden dynamically, or by a one–time change to your account. Please refer to the topic
Advanced (page 57) for further details how to configure the dynamic change.
• The FTP Adapter does support only the Standard FTP delivery method (pull scenario), and does not
support the event-driven FTP delivery method (push scenario). The reason is that the FTP/VAN adapter
is a pure FTP client, and does not support the FTP server functionality.
• The FTP Adapter has a limited support of the COMMERCE:Network reporting capabilities. The support is
limited to change the mailslot ID to the mailslot used to retrive the reports, and to download the report file.

FTP Adapter
Requesting the reports, parsing the report file, matching the report to the sent messages is outside the
capabilities of the FTP/VAN adapter.

The Send operation (upload) is straightforward with the Sterling Commerce FTP server. The HostDir is not
used in the upload process, e.g. the files are sent from the default mailslot for this connection. The default
mailslot is data with an “D” identifier. The mailslot change is possible with a custom script file. As mentioned,
only EDI files with the ASCII transfer mode can be uploaded. The uploaded file can contain as much as
9,999 EDI functional groups. The Use Temp File, Lock File, Upload Case, and Append Mode options do not
have any meaning with the Sterling Commerce FTP server, and should not be used. All other options are
available, and can be used.

The Poll operation (download) is relatively straightforward with the Sterling Commerce FTP server. Generally,
the Poll operation will download all incoming messages in this mailslot. The HostDir can be used to select
only some of the new incoming messages, but the only supported criteria is the batch number with the
syntax: #BatchNumber. The BatchNumber can be received with the LIST operation.
On successful download, the request part of the new file message will contain the following parameters:
remoteFileName #batch number
The Batch number – This is an unique number that was assigned from the
COMMERCE::Network, and identifies this batch.
fileSize No meaning
creationTime Processing time
The processing time – This is the time when the network processed this
batch.
flagsString batch status
The Batch status – this is a string that shows the batch individual status
flags. Please refer to your COMMERCE:Network manual for further details.
batchType batch type
The Batch type – this field shows the method used to transfer the batch
content, it should always have the value 1 for FTP.
mailslotID This is the mailslot ID.
Count count
The Count – This is the interchange control number for this batch.
BID BID – This is an unique value that identifies them on the
COMMERCE:Network.
Note: The FTP/VAN Adapter does not support the Concatenating Received File option of the Sterling
Commerce FTP server. This option signals that all pending message are downloaded as a single file
download operation.
13.9.4 Advanced
Streaming Mode
As mentioned above, the CR/LF mode, also called streaming mode can be changed dynamically by including
the following command in a custom script file:

FTP Adapter
“quote site ASCII_RECSEP=NONE” – disable CR/LF
“quote site ASCII_RECSEP=CRLF” – enable the CR/LF
The streaming mode setting is valid for this mailbox only. This means that CR/LF separators in the EDI
document will not be transferred directly to the partner, but will appear only, if he has configured his mailbox
to do so. On receiving, if enabled, line separators will appear after each EDI segment, but at least on every
500 bytes. On send, if enabled, line separators should appear at least once every 500 bytes.
Change Mailslot
The Mailslot is a way to group some messages by their types on sending/receiving. The default mailslot and
the one supposed for data exchange is D, from data. If the user wants, he could use the R mailslot for
reports processing, O for orders, I for invoice and so on. Mailslots can be changed with the cd SX999FTn
command where the N is the required mailslot ID. Multiple change mailslot commands are allowed in a single
session. Please use only capital letters for mailslot ID’s. Please note that a mailslot ID cannot be specified in
the HostDir like a directory path for example. The only way to issue the cd command and to change the
mailslot is to use a custom script file.
13.10 Sterling IIB

The SEEBURGER FTP Adapter supports the Sterling IIB FTP server type. The Sterling IIB FTP server
complies with the RFC950, but the communication over the Sterling IIB FTP gateway has some limitations
that are described below:
• All data transfer must use the ASCII transfer mode.

• Only EDI data files are exchanged. Non-EDI files should be wrapped in the Sterling’s private header and
trailers. For further information, please refer to your COMMERCE:Network manual.
• The uploaded EDI files can contain, or can miss embedded CR/LF separators. While processing, they are
removed from the EDI data. Any EDI file received from the Sterling IIB will not contain any separators.
• The FTP/VAN Adapter does support only the Standard FTP delivery method (pull scenario), and does not
support the event-driven FTP delivery method (push scenario). The reason is that the FTP/VAN adapter
is a pure FTP client, and does not support FTP server functionality.

The Send operation (upload) is straightforward with the Sterling IIB FTP server. The field HostDir is not used
in the upload process, e.g. the files are first uploaded to the \send folder, and then moved (using the rename
command) to the \send\commit folder.
As mentioned, only EDI files with the ASCII transfer mode can be uploaded. The uploaded file can contain as
much as 9,999 EDI functional groups. The Use Temp File, Lock File, Upload Case, and Append Mode
options do not have any meaning with the Sterling IIB FTP, and should not be used. All other options are
available and can be used.

The Poll operation (download) is relatively straight forward with the Sterling IIB FTP server. Generally, the
Poll operation will list the \receive folder, and will download all files found there. The list command results are
recognized, and parsed as a standard UNIX list command results. On successful download, the request part
of the new file message contains the following parameters:

FTP Adapter
Parameter Meaning
remoteFileName This parameter contains the file name.
creationTime This parameter contains the processing time.
permissionString This parameter contains the permission string.
ownerName This parameter contains the FTP user ID.
ownerGroup This parameter always contains users.
Note: It is not necessary to explicitly delete downloaded files by activating the Delete on Download
option. They will automatically be removed from the incoming mailbox, if the download was successful.
The Use Temp file, Lock File, Upload Case, and Append Mode options do not have any meaning with
the Sterling IIB FTP and should not be used. All other options are available and can be used.
13.11 IBM IE

The SEEBURGER FTP Adapter supports the I BM Information Exchange/FTP (in short IBM IE) server type.
IBM IE is the IBM Global Network EDI service that allows trading partners to exchange EDI data and files.
IBM IE/FTP is a FTP protocol gateway that emulates a standard FTP server (according to RFC950) and
enables communication with the IE Network. Using the FTP Adapter, the client connects to the IBM IE/FTP
interface via TCP/IP and submits FTP commands. The IBM IE/FTP interface converts FTP commands to
appropriate IE Network commands and sends them to the IE Network via SNA LU 6.2 for processing.
Some of the most important characteristics of IBMIE are:
• Secure transfer over SSL with client and server authentication.

• EDI data and non-EDI files exchange, EDI files can contain several envelopes.
• Supported EDI types are: EDIFACT, ANSI X12, UNTDI and UCS.
• Message status notifications with reports – DISPATCHED, DISPLAYED, FAILED, DELETED and
EXPIRED reports are available.
• Synchronous and asynchronous error notifications with full details on the error.
• Full EDI envelope processing information is available in the TransmissionReport XML file as described
below.
The SEEBURGER FTP Adapter also poses some limitations over the IBMIE exchanges:
• Asynchronous reports (DISPATCHED, DISPLAYED, FAILED, DELETED, TIMEOUT) are not supported
when sending EDI documents. The reason is that each frame of an EDI document is processed
separately and independently by the IE Network. Every frame is transferred separately, and is received as
a separate file by the receiver partner.
But the IE/FTP interface does not provide any feature to correlate the received envelope to the uploaded
EDI document. This prevents the correlation of the incoming report for an envelope to the envelope of the
file that was uploaded. If reports are requested on Send and an EDI file is detected, a warning message
will be logged and the outbound message mapping will immediately receive the state FINISHED.
• Message-arrival notifications are not supported.
• Library members, support files, upload/download, message archiving using the IE/FTP interface
provisions, and audit trails are not supported since this is IE management functionality that is outside the
scope of this adapter. This functionality could be achieved with an ordinary command-line FTP client. For
further reference, please consult the IBM IE documentation.

FTP Adapter
• All EDI files that are to be sent with EDI processing enabled can have multiple envelopes, but each file
must consist of a of only one EDI format. The IE/FTP interface does not support mixed-format EDI data
files.
• The alias table type cannot be specified when sending EDI data. Please check below for clues how to
overcome this limitation.
For some common problems and their possible solution, please refer to IBM IE FAQ .
Message Charges
Attention: This is only a general information on message charges. For more detailed information,
please request the IE charges reference from your service provider.
Every time trading partners exchange messages with each other, the Information Exchange assigns two
charges:
• A send-side charge for sending the message.

• A receive-side charge for receiving the message.
If both trading partners are on the same Information Exchange system, these charges may be:
• Paid by the sender.

• Paid by the receiver.
• Split between the sender and the receiver.
If a sender sends a message to a trading partner that is connected to a messaging service other than the
sender’s local information exchange system, restrictions on payment options may apply.
IBM IE does not charge for receiving or viewing messages generated by *SYSTEM**ERRMSG*, e.g. all
reports are generated with this ID.

As already described, both EDI and non-EDI files can be sent to the trading partners. Each of these cases is
described below.
Partner Address and Aliases
When specifying partner addresses in the HostDir for a send operation, you could use the following syntax:
• account.userid - A trading partner on your local Information Exchange system.

• sysid.account.userid - A trading partner on another Information Exchange system. Each system has a
unique system ID such as BRA, EUR, JPN, USA and USQ.
• (gxxx).aliasname - Global alias table.
• (oxxx).aliasname - Organizational alias table.
• (pxxx).aliasname - Private alias table.
• (list).listname - Central list.

FTP Adapter
Note: library, *system*.*errmsg* meaning system message selection, and support files that are
available additionally in the IBMIE user manual are not allowed when using FTP/VAN Adapter.
Send Operation – Non-EDI files .
To send a non-EDI file, the recipient address should be specified in the HostDir. It should use the IE partner
naming scheme address/msgclass where address is the address of the receiver party that should comply
with the partner address syntax described above.
The second part, msgclass is an optional message class string, 1-8 chars. If not specified, a default
message class “*” is used.
On successful Send, the response part contains the following parameters:
remoteFileName This is the composite address.
messageId This is the message ID.
system This is the recipient IE system.
address This is the recipient IE address.
msgClass This is the message class.
description This is the text description of the sent operation.
Send Operation – EDI File .
To send an EDI file, the value edi should be specified in the HostDir. This will enable the EDI processing in
the IE/FTP Interface. In this case, partner address and message class are taken from the respective EDI
frame fields. Below is a short reference for the fields used in the different EDI formats supported:
EDIFACT
The first sub-element (0010) of the composite element S003 (interchange recipient) is the recipient address.
The second sub-element (0007) of the composite element S003 is the EDI qualifier.
• If the qualifier is ZZ or bb and the EDIALIASONLY is OFF, the recipient address is treated as the partner
address.
• If the qualifier is not ZZ or bb or the EDIALIASONLY is ON, the recipient address is treated as the alias.
The type G ( global) alias table is used, where the table ID is E qq where qq is the qualifier.
If the data element 0026 (Application Reference Field) is provided, the IE/FTP interface extracts the first eight
characters, and uses them. Otherwise, the MSGCLASS defaults to #EE.
ANSI X12
The value in positions 55 to 69, the interchange receiver element (ISA08), is the recipient’s address. The
value in positions 52 and 53, the EDI qualifier element (ISA07), is the EDI qualifier.
• If the qualifier is ZZ or bb and the EDIALIASONLY is OFF, the recipient address is treated as the partner
address. The partner address elements account and the userID are delimited after the first seven
characters, or by space whichever comes first.
• If the qualifier is not ZZ or bb or the EDIALIASONLY is ON, the recipient address is treated as the alias.
The type G (global) alias table is used, where the table ID is Xqq where qq is the qualifier.
MSGCLASS cannot be specified and is permanently set to #E2.

FTP Adapter
Note: X.12 binary and security segments can only be reliably transmitted, if the file type is set to Binary.
The reason is that they could contain non-ASCII data and will not be processed successfully, if the
character set conversions are applied.
UNTDI
The first sub-element of the composite element UNTO (0004) is the recipient code address, and the second
sub-element is the recipient clear address.
• If the recipient code address is blank, the clear address is treated as the partner address.
• If the code address is not blank, it is treated as an alias. The global alias table GUTD is used.
• If the data element 0012 (application reference field) is provided, the IE/FTP interface extracts the first
eight characters and uses them. Otherwise, the MSGCLASS defaults to #EU.
Note: The EDI file should not include the data element 0008 (sender’s transmission reference), because
this reference will overwrite the MSGNAME field that is used internally in the FTP/VAN Adapter for
report correlation. If absolutely necessary, please do not request reports when sending such EDI files,
because reports will not work correctly.
UCS
The value of the Application Receiver’s Code element (BG04) from the BG is used as the recipient’s address.
The recipient’s address is always treated as an alias in the GUCS table. The MSGCLASS could not be
specified, and is permanently set to #EC.
On successful Send, the response part will contains the following:
remoteFileName This is the composite address of the sender.
messageId This is the message ID.
ediSuccessNumber This is the number of successfully processed EDI frames.
ediErrorNumber This is the number of erroneous EDI frames.
description This is the text description of the sent operation.
The next members exist only, if the success frames exist
replyCode This is the reply code, see table below for details.
ediType This is the EDI type, see table below for details.
offset This is the offset to start of the EDI envelope, in bytes.
length This is the length of the EDI envelope, in bytes.
address This is the recipient address of this envelope, see the table below for
details.
userClass This is the message class of this envelope.
controlNumber This is the EDI control number, extracted from the EDI envelope.
description This is the text description for the status of this envelope.

FTP Adapter
Reply Codes:
Reply code Description

00 No error (EDI interchange sent).
01 The User ID detected is in invalid format.
02 Not authorized to send to User ID.
03 The User ID does not exist.
11 The EDI format error.
12 Cannot determine EDI type.
13 Error with IE/Communications.
14 X.12 Binary or Security segment and not TYPE I.
15 Mixed EDI types detected.
16 The EDI header error.
17 The EDI control number mismatch.
EDI Types:
EDI type Description

E EDIFACT
T UN/TDI
X X.12
U UCS
Address Field Syntax:
Address type Format

Single User ID DTBLID DESTACCT. DESTUID where DTBLID is the
IE destination system, DESTACCT is destination
account and DESTUID is the destination user ID.
Alias DTBLTYP DTBLID.ALIAS where DTBLTYP is the
alias table type: G – global alias type, O –
organizational alias type, P – private alias type. The
DTBLID is the alias table name and the ALIAS is the
destination alias name.
List TEXT LISTNAME where TEXT is LIST and
LISTNAME is the destination list name.

The Poll operation can use a selection string in the HostDir. The selection string is generally the address of
the trading partner who sends messages. Use either a specific partner address or the wildcard “*.*“ that
denotes all partners. A message class can also be specified, /msgclass, it could also be “*” that denotes all
message classes. The wildcard character “?” (as prefix or suffix only) can be used as a substitute for any
single character. If this field is left empty, the default address “*.*/*” is assumed, i.e. all partners with all
message classes.

FTP Adapter
The selection criteria applies only to files coming from trading partners, but not to reports (which are files in
specific format) coming from the partner *SYSTEM*.*ERRMSG*. All available reports are downloaded and
processed on every Poll operation.
Note: By default, the received EDI files do not have line delimiters. The delimiters stripping is carried
out by the IBMIE EDI parser while processing the EDI envelopes. If necessary, line delimiters can be
enabled with ENABLEDEL command in a custom script file.
On successful download, the request part of the new file message will contain the following:
remoteFileName This is the composite address of the sender.
fileSize This is the file size.
creationTime This is the creation time.
senderID This is the sender address.
msgKey This is the message key.
Please refer to the Polling Operation topic for further details.

The DtReport part of a new report message contains the following key-value parts:
Key Value contains

ibmie.UniqueIdentifier This is the message unique identifier.
ibmie.MsgType This is the message type, can be either MESSAGE or GROUP.
ibmie.MsgText This is the additional text description of the report action.
ibmie.MsgReceiver This is the recipient address.
Comments (0)
13.11.4 Common
Please note that sending and receiving have to use the same Transfer Type setting, or the transmitted file will
be corrupted. Additionally, binary files should always use the BINARY TransferType setting, or they will be
corrupted while transmitted. The reason for this requirement is that internally, the IE Network host system
uses the EBCDIC character set, and converts the incoming ASCII file to EBCDIC during the file upload.
Then, during the download, the file is again converted to ASCII. If the file is binary, this conversion is not
guaranteed to be transparent, because of the escape sequences that can be found. As a result, if the
transfer type is not the same during upload and download, the conversion will damage the file.
13.11.5 Security
There exists a possibility to change the password used to access the partner mailbox. Please use the
following syntax in the password field: oldpassword/newpassword. This will change the password on the first
call to this channel, either Send or Poll and the password field should be changed immediately to the
newpassword, or the next operation will fail, because the password was already changed. If you have three
consecutive password failures when attempting to log on, the IE/FTP interface drops your TCP/IP control
connection, and disallows all subsequent logon attempts until a system-defined timer expires.
Please note that the IE/FTP interface allows only a single connection for a single mailbox, This means that if
multiple channels are defined to access the same mailbox, for example one receiver channel for the Send
operation, and one sender channel for the Poll operation with the same partner settings, a resource should
be defined, and used in both of them.

FTP Adapter
Note: The IE/FTP interface supports only AUTH TLS security setting.
13.11.6 Custom Script File Commands

The SEEBURGER FTP Adapter provides configuration options for the processing of the IE/FTP interface to
an extend likely to be used by an average user. If more profound control is required, a custom script file can
be created and configured that issues site commands. These commands modify the rest of the processing
options that are available. For an example of a corresponding script, refer to the topic Scripting.
Note: The script command mput is not supported for IBM IE. Please do not use this command in
custom scripts.
Follows a short list of the available processing options:
Option Effect
probe [1|0] Useful only combined with the Send operation. If enabled, more severe
error checking is applied over the recipient partner address. This can be
especially useful when using aliases
xlate [lie|xtable] This option specifies the ASCII-EBCDIC conversion table to be used when
exchanging data with the IE/FTP interface. The parameter ie specifies the
usage of the standard IE translation table where xtable requires the
application of a specific table. Please check with your account information
for the list of available tables
msgchrg [1|2|3|4|5|6] This option specifies how the message charges are separated between
the sender and the recipient. The following list gives more details:
• 1
The receiver pays all message charges.
• 2
The receiver pays all message charges if agreed to; otherwise, charges
are split.
• 3
The receiver pays all message charges if agreed to, or charges are
split if agreed to by receiver; otherwise, sender pays all charges.
• 4
The charges are split if agreed to by receiver; otherwise, sender pays
all charges.
• 5
The charges are split.
• 6
The sender pays all message charges.
msgretn [n] This option specifies the message retention period, in days. The parameter
must be a number between 0 and 180. 0 corresponds to the system
default of 30 days.
edicrlf [0|1] This option enables or disables the carriage-return and the line-feed
(CR/LF) when receiving EDI data from the IE/FTP interface.
edialiasonly [0|1] This option enables or disables EDIALIASONLY processing, when sending
EDI files. Please refer to the Send Operation – EDI Processing topic for
further details.
The following processing options are internally used by the FTP Adapter. False usage can damage the
adapter's functionality.

FTP Adapter
• system
• liststyle
• confirm
• resp226
• resetopts
• edireplybuf
• edireplies
• msgrcpts
• msgname
• msgseqn
• passthrue
• edionly
• edicdhonly
• putopts
• getopts
• autogetopts
• forceopts
13.12 EDI*Express (GE MARK III)

The SEEBURGER FTP Adapter supports the TCP/IP FTP Intermediate Mailbox Processing Interface to the
GEIS EDI*Express (GE MARK III) service, in short the GE_MARK_III server type. The EDI*Express is a
communication network used for immediate delivery of EDI exchanges between business partners. The
EDI*Express Intermediate Server is an interface component that provides immediate mailbox access to the
EDI*Express using the FTP protocol. Some of the most important characteristics of the GE_MARK_III are:
• Complete support of all report capabilities of the GE_MARK_III including DISPATCHED, DISPLAYED and
FAILED reports.
• SSTA report file is downloaded only, if reports are pending in the MessageIdStore.
• The full EDI envelope processing information is available in the TransmissionReport XML, as described
below.
The SEEBURGER FTP Adapter also poses some limitations over the GE_MARK_III exchanges:
• Only EDI files can be transferred. This is general operation requirement of the EDI*Express service.
• Open receive of interchanges (event-driven processing) is not supported.
• The EDI file to be send in ASCII mode must not contain any line delimiters ( 0x0d and 0x0A ) as data or
segment termination. This is due to the internal transcoding to/from the EBCDIC character set that the
EDI*Express executes on send and receive respectively.
• Reports (DISPATCHED, DISPLAYED, FAILED) are not supported when sending multi-envelope EDI
documents. The reason is that each frame from an EDI document is processed separately, and
independently by the EDI*Express. Every frame is transferred separately and is received as a separate
file by the receiver partner. But the EDI*Express interface does not present any way to correlate the
received envelope to the uploaded EDI document. This prevents the correlation of the incoming report for
an envelope to the multi-envelope file that was uploaded. If this happens, there is a possibility of report
miss-handling and/or business process mess-up. However, there is no way the FTP/VAN module can
recognize that multi-envelope EDI documents are transferred, and so it is completely the user's
responsibility to ensure that reports are not requested for a multi-envelope EDI file.

FTP Adapter
• If reports are requested on Send and a multi-envelope EDI file is detected, a warning message will be
logged and the Outbound message mapping will immediately receive the state FINISHED.
Price List
Attention: This price list must serve only as an orientation for the interchange prices. An actual price
list must be requested from the EDI*Express service provider.
Interchange Service Normal Tariff Night Tariff

Sending and Receiving: Price per 0.22€ 0.19€
interchange plus taxation per one
interchange.
Sending and Receiving: Interchange per 0.18€ 0.15€
KC - up to 40 KC's
Sending and Receiving: Interchange per 0.14€ 0.11€
KC - over 40 KC's
KC = Kilocharacter
Optional Service Tariff

Status report (SSTA): Electronic format per KC 0.14€
Status report (SSTA): Print format 0.71€
KC = Kilocharacter
To prevent downloading the SSTA reports every time when there is a pending report in the MessageIdStore,
the FTP Client proposes a sample scenario for cheap polling of reports (page 81).
Note: The script command mput is not supported for the GE MARK III and GE MARK 3000. Please do
not use this command in custom scripts.
To send an EDI file, no recipient partner address information should be entered in the Partner Master Data
fields, because all necessary address information is taken directly from the EDI file while it is parsed by the
EDI*Express service.
Please note that the interchange control number (ILOG) is assigned by the EDI*Express service on an
upload file bases. If the EDI file contains more than one interchange, each one will have a different IC control
number. The IC control number is not available in responses, because EDI*Express does not provide a
corresponding feature.

Generally, the Poll operation will download all incoming messages in the mailbox. The field HostDir can be
used to select only some of the new income messages based on their MFile name. Wildcard symbols “?” and
“*” are also supported. The MFile names can be extracted by the LIST operation result.
On a successful download, the request part of the new file message will contain the following:

FTP Adapter
remoteFileName This is the MFile name.
creationTime This is the file mailbox time.
senderID This is the sender.
ilog This is the ILOG.
iccontrol This is the IC Control number.
The DtReport part of a new report message will contain the following key-value parts:
Key Value contains

gemark.ReportText The full report text from which the other segments are parsed and filled.
gemark.IcControlNumber This is the interchange control number.
gemark.IcConrolDate This is the interchange control date.
gemark.DocumentType This is the document type code.
gemark.GeisReceiptDate This is the EDI*Express receipt data.
gemark.Frame0001. This is the error code (only if exists error frames).
ErrorCode
gemark.Frame0001. ErrorField This is the error field number (only if exists error frames).
gemark.Frame0001. This is the error segment number (only if exists error frames).
ErrorSegment
gemark.Frame0001. This is the error message (only if exists error frames).
ErrorMessage
gemark.Frame0001. This is the target/source flag ( “T”/”S” ) (only if exists error frames).
TargetSorceFlag
gemark.Frame0002.... (Only if further error frames exist).
…more frames … (Only if further error frames exist).
Note: The element with key gemark.DocumentType contains the document type code as assigned by
the EDI*Express service.
Zero, one or more elements with keys gemark.FrameNNNN.xxxxx elements can be present. A group
with equal number represents one error description frame that is returned by the EDI*Express service.
The SEEBURGER FTP Adapter uses SSTA reports in EF2 format as its information source for any reports
that are to be generated and sent to the XI system. As requesting SSTA reports involves financial overheads,
the SSTA report is only requested, if it has been detected that a previous Send operation has requested a
DISPLAYED and/or DISPATCHED report. When the requested report is received, the message mapping, as
available in the MessageMonitor, is finished and no further requests for SSTA reports are issued. This
mechanism has a limitation, so that a FAILED report for messages that have already been sent, can only be
received, if there is at least one pending DISPLAYED or DISPATCHED report request. This requirement does
not impose transfer unreliability, because whenever completely reliable transfer is required, positive reports
will be used (DISPLAYED, DISPATCHED or both). Then, on every poll, an SSTA file will be downloaded and
processed. As a result, any existing FAILED reports will also be received.
Note: keeps the reports. After this period, any information is discarded and lost for the FTP/VAN
module. A report should be requested on regular bases, at least once in the retention period. The
retention period is the time that EDI*Express The default retention period is 7 days and can be changed
on request to the EDI*Express support staff.

FTP Adapter
13.13 EDI*Express (GE MARK 3000)

The SEEBURGER FTP Adapter supports the TCP/IP FTP Intermediate Mailbox Processing Interface to the
GEIS EDI*Express (GE MARK 3000) service, in short GE_MARK_3000 server type. This is a variant of the
GEIS EDI*Express service with minor technical differences that are handled by the SEEBURGER FTP/VAN
Adapter. The same capabilities and limitations apply as described in the GEIS (GE_MARK_III) VAN topic
with the following exceptions:
• Message classes are supported. The message class string (6-characters size) can be specified while
sending and will be available in the <gemarkFileDetails> element if a new message is received.
• The file size field is available and is parsed on Poll operation. It is also available in the <
receivedDocument> element.
• The <messageId> sub-element of the <sentFileDetails> element contains both ILOG and IC control
number in the format: ilog.iccontrol.
13.14 EXITE (ECODEX)

The SEEBURGER FTP Adapter supports the IBM Exite(Ecodex)/FTP (in short ECODEX) server type.
ECODEX is the IBM-Austria EDI service that allows a trading partner to exchange EDI data. ECODEX/FTP
is a FTP protocol gateway that emulates a standard FTP server (according to RFC950) and enables
communication with the IBM BusinessContact Network (BC). Using the FTP/VAN adapter, the client
connects to the ECODEX /FTP interface via TCP/IP and submits FTP commands, The ECODEX /FTP
interface converts FTP commands to the appropriate IBM BC command, and sends them for processing by
the IBM BC service.
Some of the most important characteristics of IBMIE are:
• The message status notifications with reports – DISPATCHED, FAILED and EXPIRED reports are
available.
• The full EDI envelope processing information is available in the TransmissionReport XML file, as
described below.
• The message classes are supported. A message class string (6-characters size) can be specified while
sending, and will be available in the <ecodexFileDetails> element if a new message is received.
The SEEBURGER FTP Adapter also poses some limitations over the ECODEX exchanges:
• Only EDIFACT files can be transferred. This is a general operation requirement of the IBM BC service.
• Sedas Order, Sedas Invoice and General file types are not supported.
• Inhouse formats are not supported.
• Reports (DISPATCHED, FAILED) are not supported when sending multi-envelope EDI documents. The
reason is that each frame from an EDI document is processed separately and independently by IBM BC.
Every frame is transferred separately, and is received as a separate file by the receiver partner. But IBM
BC service does not present any way to correlate the received envelope to the uploaded EDI document.
This prevents the correlation of the incoming report for an envelope to the multi-envelope file that was
uploaded. If this happens, there is a possibility of report miss-handling and/or business process mess-up.
However, there is no way the FTP/VAN module can recognize that multi-envelope EDI documents are
transferred. I.e. it is the user's responsibility to ensure that reports are not requested for a
multi-envelope EDI file.

FTP Adapter
• Reports are generated on the basis of PS* and PR* file parsing results, and not on the acknowledgement
option supported by the system. The ser(F) and ack() commands are not used in the send script file to
generate or request reports.
• The additional service parameter z(P) is not supported.
Price List
Attention: This is a general information on the EXITE price list and must serve only as an orientation.
Please request full and updated price lists from your service provider.
Every interchange is calculated in units and depends on the gateway type. Examples:
• TYPE I: Internet gateway connections inbound and outbound - sending and receiving from 1 to 1000
interchange costs 0.00500 Units
• TYPE II: IBM Information Exchange inbound and outbound - sending and receiving from 1 to 1000
interchange costs 0.01500 Units
1 Unit costs € 17.50 (January 2008)
Note: The script command mput is not supported for EXITE. Please, do not use this command in
custom scripts.
To send an EDIFACT file, no recipient partner address information should be entered in the channel fields,
because all the necessary address information is taken directly from the EDIFACT file while it is parsed by
the IBM BC service.
If the EDIFACT file contains more than one interchange, each one will have a different LFD number. The LFD
number is not available in responses, because the IBM BC does not always provide it when sending.

Generally, the Poll operation will download all incoming messages to the mailbox. The field HostDir is not
used by this VAN. On successful download, the request part of the new file message will contain the
following:
remoteFileName This is the file name e.g. transactionId + “_” + Lfd number.
fileSize This is the frame size in bytes.
creationTime This is the send time.
jobID This is the job ID.
senderID This is the sender address.
lfdNumber This is the LFD number.
refNumber This is the reference number of the frame.
msgClass This is the message class of the frame.
The DtReport part of a new report message will contain the following key-value parts:

FTP Adapter
Key Value contains

ecodex.JobID This is the job ID.
ecodex.BytesTotal This are the transferred bytes total.
ecodex.BytesExite This are the transferred bytes over Exite.
ecodex.BytesGateway This are the transferred bytes over gateway.
ecodex.FramesTotal This are the transferred frames total.
ecodex.FramesExite This are the transferred frames over Exite.
ecodex.FramesGateway This are the Transferred frames over gateway.
ecodex.ErrorFrame0001. This is the error code (only if exists error frames).
ErrorCode
ecodex.ErrorFrame0001. This is the error description (only if exists error frames).
ErrorText
ecodex.ErrorFrame0002… (Only if exists more error frames).
…more error frames … (Only if exists more error frames).
ecodex.SuccessFrame0001. This is the sender address (only if exists success frames).
SenderID
ecodex.SuccessFrame0001. This is the date (only if exists success frames).
SendDate
ecodex.SuccessFrame0001. This is the LFD number (only if exists success frames).
LfdNumber
ecodex.SuccessFrame0001. This is the reference number of the frame (only if exists success frames).
RefNumber
ecodex.SuccessFrame0001. This is the length (only if exists success frames).
Length
ecodex.SuccessFrame0001. This is the message class of the frame (only if exists success frames).
MsgClass
ecodex.SuccessFrame0002… (Only if exists more success frames).
…more success frames … (Only if exists more success frames).
If a positive report (DISPATCHED) is received, elements with the keys ecodex.SuccessFrameNNNN.xxxxx

will be presented, describing the frame that this reports correlates to. If a negative report (FAILED) is
received, the elements with keys ecodex.ErrorFromeNNNN.xxxxx will be presented.

FTP Adapter
14 Known Restrictions
• Implicit SSL Secure Connection is not applicable for use with FTP Proxy servers!
• For OS400 FTP Server, the SEEBURGER FTP Adapter supports deletion only for the file members, not
for the files!
• On sending the bracket symbols ‘(‘ and ‘)’ are not allowed in the file name, and will be removed if they are
specified in the configuration mask.
For applicable common restrictions, please refer to the Master Adapter Installation Guide.

FTP Adapter
A Checklist
During the setup and configuration procedure of the BIS FTP solution, the following information must be
available:
X Action
General
• The DNS host name or IP address of the FTP server.

• The port of the FTP server.
• The FTP server type.
For using SSL (Implicit or AUTH_TLS)
• The partner's public certificate and own private key will be required.

FTP Adapter
B Sample Scenario
B.1 Sending Messages

This topic describes the creation of a sample scenario for uploading a file to a partner.
Action Illustration
1. Create an FTP address in
the BIS front-end. Parameter Value
Name Local_address
User anonymous
Password *********
Account
Relative path anonymous_user\
Mask *.*
Default encoding UTF-8
2. Create an FTP connection

in the BIS front-end. Parameter Value
Name Local_connection
Server type Standart
Host localhost
Port 21
Use TLS No
Connection mode Passive
Port range
Keep alive false
Proxy mode <No proxy>

FTP Adapter
Action Illustration
3. Creating a process with a
HotFolder newFile and a
FTP sendFile operation in
the Process Designer.
4. Assign the input values for

the FTP sendFile operation. Parameter Value
The address and clientId seeutil:getEnv()
connection IDs can be
originAddressId
retrieved from the
front-end: Open the originAddressName
Administration tab of the destinationAddressI '19e35db1-14c8-11df-8e2e-0f000a0a1231'
Address and Connection d
configuration.
destinationAddressN
5. Also fill the queue element ame
with a value like
FTP-Queue. connectionId '1ecb0300-14c8-11df-8e2e-0f000a0a1231'
6. Save and deploy the connectionName
process. correlationId
subject
attachments variable="vrHotFolderEvent" part="eventData"
query="/hotfolder:eventData/hotfolder:inref"
scriptFile
script
queue 'FTP-Queue'
7. Go to the BIS Front-end

and open the Worklist Parameter Value
Handler tab. Name FTP-Queue
8. Then create a new FTP Partner *
queue with the name you
have entered in the process Port type DtFTPComponent
above.
9. Select Port type
DtFTPComponent.
10. Save the queue.

FTP Adapter
Action Illustration
11. Open the queue, open the
Nodes tab and add a FTP
node to the queue.
Figure B-1: Add an FTP node
12. Create an initiator rule

forwarding the hotFolder Parameter Value
event to the new FTP Name send
sendFile process. The
Port HotFolder/FileEvent/newFile
same rule can be used also
with polling process, which Expression //groupName='PORT_01'
starts with hotFolder event. Routing Type process
Target port HotFolder/FileEvent/newFile
You can test the scenario by starting the FTP Adapter and putting a file to the hotfolder directory specified in
the rule. The file is then uploaded to the partner.
B.2 Receiving Messages

This scenario describes the polling of partner directory and downloading the files.
Action Illustration
1. Create a FTP address and (You can use those from Send scenario.)
connection.
Attention: Please be careful with Delete Option – if checked, the
downloaded files will be deleted from FTP server directory.
2. Create a process
containing the FTP
initiateMessage operation.
Save and deploy the
process.
Figure B-2: Create a process
3. Create an initiator rule.

FTP Adapter
Action Illustration
4. Create a process with
HotFolder newFile and FTP
polling operation.
Figure B-3: Create a process
5. Assign the input values for (You can use those from Send scenario.)
the FTP polling operation.
6. Save and deploy the
process.
You can test the scenario by starting the FTP Adapter and putting a file to the hotfolder directory specified in
your rule for polling. Then the files will be downloaded from the FTP server.

FTP Adapter
C Secured FTP (FTP Over SSH)
C.1 Overview
Secured FTP is not a standardized protocol. It is a commonly accepted name for tunneling FTP-connections
through SSH. There are two different possibilities how this can be achieved. SSH supports port-forwardings,
which can be defined within your SSH application.
This method provides the securing of the control channel of the FTP with SSH. It requires the creation of a
port-forwarding from a local port (e.g. 2121) to the remote hosts port 21. Then you can connect the FTP
client (or the FTP Adapter) to the local host with the specified local port (e.g. 2121). You have to use the
passive mode to establish a working connection between the FTP server and your client. When operating in
a passive mode, the server sends the client a address/port which the client can connect to as data channel.
Since only the control channel of the connection is secured, all data is transferred in plain text over possible
insecure TCP connections. But all control commands are sent via the SSH tunnel. So the password of your
FTP login is encrypted.
A second possibility which most SSH clients offer is dynamic port forwarding. With this method the SSH
client works as a local SOCKS proxy. As the SEEBURGER FTP Adapter supports SOCKS proxies, this is the
preferred method of tunneling your FTP connections over SSH.
C.2 Establishing the SSH Connection

It is possible to use any SSH client you want, as long as it supports dynamic port forwarding as a SOCKS
proxy. One client which implements this feature is the open source application PuTTY. PuTTY is free and
available for many different operating systems like Windows, UNIX, Linux. It also supports a wide range of
hardware platforms. It can be downloaded from
• http://www.chiark.greenend.org.uk/~sgtatham/putty/
PuTTY comes with a command line application called plink. Plink is controlled via command-line arguments
which makes it easier to include in the batch scripts. A sample execution of Plink would be the following
• Windows: D:\Path\to\Plink.exe -P <SSH port> -l <SSH user> -pw <password>

-D <local listener port of the SOCKS proxy> <host>
• Linux: /path/to/plink -P <SSH port> -l <SSH user> -pw <password> -D <local listener port of the SOCKS
proxy> <host>
For example, if Plink is installed in D:\Programme\PuTTY, and it is called with the parameters
D:\Programme\PuTTY\Plink.exe –P 22 –l testuser –pw test –D 2121 test.example.com, the result would be
an established connection to the host test.example.com with a local socks proxy listening on port 2121.

FTP Adapter
You can also provide a client certificate for authentication. Please refer to the PuTTY documentation for
further details.
C.3 Configuring FTP
C.3.1 Configure a Local SOCKS Proxy

1. First you have to specify the local SOCKS proxy you have created with Plink.
2. Therefore open within the BIS Front-end the Proxy Configuration and add a new server.
3. For the Host type in localhost and as Port specify the value you have used as local listener port of the
SOCKS proxy.
4. In our example this is 2121.
5. As server type you have to select SOCKS with protocol version 5.
Parameter Value
Name SSHTunnelProxy
Host localhost
Port 2121
User
Password
Realm
Server type SOCKS
Version SOCKS 5
Upstream proxy <not defined>
• See the example configuration.
C.3.2 Configure an FTP Address

1. Now add your FTP account details to the FTP configuration as an FTP address.
2. Select a relative path and a file mask to poll the desired files.
Parameter Value
Name TestUser
User testuser
Password ********
Account
Relative path test\
Mask myTestFile.txt
Default encoding UTF-8

FTP Adapter
C.3.3 Configure an FTP Connection

1. Specify the original host name of the FTP server you want to communicate within the Configuration dialog
in the FTP connection.
2. The same goes for the port settings (usually port 21 is used for FTP).
3. Remember to set the proxy mode to <Specific proxy> and select your local SOCKS proxy from C.3.1.
Note: You have to use the Passive connection mode to be able to use the FTP with a SOCKS proxy.
Parameter Value
Name test.example.com
Server type Standard
Host test.example.com
Port 21
Use TLS No
Connection mode Passive
Port range
Keep alive false
Proxy mode Specific proxy
Proxy alias SSHTunnelProxy
C.4 Note
There are some topics you have to remember when using FTP over SSH with a local SOCKS proxy:
1. Make sure your proxy is available when FTP tries to send or receive files. Plink does not support any
retry-mechanisms, if the network connection fails. It just exits silently. So you may have to write a script
which checks if Plink is available.
2. As stated above, the connection mode has to be <Passive>.
3. You have to make sure that the host is already known by Plink. Otherwise it will print a question whether
to add the server to the known hosts file.

FTP Adapter
4 Sample Scenario for cheap polling of GE MARK

III reports
The GE MARK III reports are payed and they are generated on-the-fly, e.g. in time of their request. To
prevent unnecessary payment, the FTP Client has an internal check. Reports are downloaded only, if they
are requested in FTP Connections form, or in request.
If a customer has a running polling every hour, and reports are requested, the FTP Client will download
reports every hour. This is not a desired behavior when the traffic is high, and respectively the price.
Proposed Solution
The FTP Client proposes the following solution: Not to download the reports on every polling, but instead
once a day. This is enough to update the MessageIDStore entries, and to correlate the reports.
Note: Be careful with the reports timeout. If the timeout setting is too small, the report can correlate with
state EXPIRE.
1. Create a new scheduler task for polling.

2. Create a custom script, which will not download reports. Script example:

[LOOPSTART]
set GET_GEMARK_REPORTS=FALSE
mget [@Key=HOSTDIR]
[LOOPEND]
close
3. Configure the Script URI field in the new polling scheduler task to point to the full path of the custom
script. For more information about how to enter the path, see Scripting (page 30).
4. Change the execution time of the old polling to be once a day.
The result from this configuration is that the new polling will download every hour messages from the GE
MARK III, but not reports. And the old polling operation will download once a day messages and reports, and
also will correlate the downloaded reports with their messages.
Additional Features
The FTP Client also provides a way for downloading SSTA reports in plain text for archiving purposes.

FTP Adapter
Attention: If DISPATCHED or DISPLAYED reports are requested, downloading SSTA in plain text will
not update the MessageIDStore entries. To do this, you must run the normal FTP scripting functionality
which will download messages and reports. This is only a text file for archiving purposes.
1. Create a copy of your GE MARK III FTP Connection and change the server type field to Standard.
2. Create a new scheduler task for polling, which uses the copied connection.
3. Create custom script for downloading the SSTA report in plain text. Script example:

[LOOPSTART]
set DISABLE_LIST_BEFORE_GET=TRUE
type A
cwd reports
quote site parm=ND=30
get ssta
[LOOPEND]
close
3. (Optional) Change the number of days for which the report is requested. The default value in the script is
30 days, so the report would be generated for the day that it is requested, and 29 days before that (only if
the GE MARK III is still keeping these records. The GE MARK III default value for keeping the reports is 7
days). Change the value 30 to your preference (script: quote site parm=ND=30).
4. Configure the Script URI field in the new polling scheduler task to point to the full path of the custom
script. For more information about how to enter the path, see Scripting (page 30).

FTP Adapter
5 FAQ
Q: How can a script be modified to issue a LIST command? Are there any commands like ls or dir?
A: The commands ls and dir are script commands of the Windows-based FTP command line.
These commands are then translated into FTP commands (according to RFC959). The ls command
corresponds to NLST; the dir command corresponds to LIST. The FTP Adapter has his own script language.
With its script, a LIST command cannot be issued, because the FTP Client always performs an internal LIST
command before executing other commands. To see the complete list of the FTP client's script commands,
please refer to Commands (page 32).
Q: The FTP client tries to connect to a standard server. But when polling, the following reply message is
returned: LIST command not allowed. Because of the FTP client's internal mechanism for issuing LIST
commands in every polling operation and in unique sendings, none of the processes can finish with success.
A: Servers that do not support LIST commands are rare. Such servers may support NLST (simplified list)
instead of LIST. There are two possibilities to work around this problem:
• Enable the NLST command. To do this, check the Use NLST command in FTP Connections. For more
information please refer to the topic Simplified Listing (page 41).
• The other possibility is to use a custom script. But then no file name patterns can be applied. The file
name must be specified correctly to execute a direct get without a LIST. See the script example:

[LOOPSTART]
set DISABLE_LIST_BEFORE_GET=TRUE
get [@Key=HOSTDIR]
[LOOPEND]
close
Q: A custom FTP script is required. Which data must be included in the loop section?
A: All the process-dependent data should be included in the section that is delimited by the expressions
[LOOPSTART] and [LOOPEND] .
Example: The TYPE command (ASCII or Binary), which depends on the payload. In the script's first section,
the session is created. If there are session-dependent parameters, they should be included here. In the
script's end section, normally the session is closed.
Q: Is it possible to synchronize parallel sending and polling of two FTP directories using a LOCK file?
A: No.
A LOCK file is used to prevent parallel sending and polling actions of a directory. To ensure this, the sending
operation always writes a LOCK file and the polling operation is aware whether this file exists. If so, polling is
not performed.

FTP Adapter
A problem occurs with simulaneous sendings and polling actions. Parallel sending actions will always
write/overwrite the LOCK file, but they will also delete it. This LOCK file deletion can may be performed too
early (when the first sending process finishes), and can trigger a polling action before the end of parallel
sending actions. For synchronization of parallel sending and polling actions, it is recommended to use a
grouped WLH queue or resource management.
5.1 IBM IE
Q: Sometimes, polling operations finish with the following exception:
com.seeburger.jftp.app.exception.FtpExceptionHardProcessingError: Original messageId contains invalid
message type, valid are O,E but found:0002697600001
All the files are downloaded from the VAN box. Which is its cause?
A: This error occurs with downloads of messages that have not been sent by the FTP client. When sending
to IBM IE, the FTP Adapter defines an unique MessageID starting with E for EDIFACT and O for ordinary
message. Correspondingly, it expects to find the defined MessageID in the received report. The reason for
this problem is that another software is simultaneously working with the VAN box used by the FTP client. This
is not an allowed case for working with reports, because there is no way to divide them properly in the
directory listing.
Q: When trying to communicate with IBM IE, a lot of 421 replies are received. No sending nor polling can be
performed.
A: IBM IE VAN returns 421 replies because it does not allow two sessions directed to one box. For limiting
the access to the VAN box (running send and poll operations), there are two possibilities:
• For resource management -refer to the topic Resource Management in the Master Adapter Configuration
Guide.
• Create a logical resource representing box-connection(s).

• Create a relation between the resource and the queue(s) running FTP orders.
• For grouped queue(s) - refer to the topic Synchronization of Partner-Specific Orders and also the
Partner-Specific Sending/Connecting to a Mailbox.
• The important thing here is to define one queue for each box-connection.
Which one of the two possibilities is more suitable depends on the use case. If there are many processes
with different queues, the resource management is preferred. But if there is one sending and one polling, it is
better to assign all these operations to a SINGLE GROUPED FTP Queue, to ensure that only one
connection is made to the VAN.
Q: After the update, the FTP process for sending to IBM IE VAN fails with configuration error User message
class is more than 8 characters. What has been changed?
A: IBM IE has a length restriction for the message class. It can be between 1 and 8 alphanumeric characters.
A check for the message class length has been implemented to prevent pointless transfers that finish with a
negative FTP reply: 553 error in composite address. Please check your master data configuration (or request
data) and reduce the length if necessary.
Q: When connecting to IBM IE, the SSL handshake is too slow. Downloading small files takes a lot of time.
What can cause this?

FTP Adapter
A: This is most probably a network related issue. It appears to be a bottleneck when creating sockets. This is
because of the DNS: 1) when the client connects using a symbolic name or 2) when the server does a
reverse lookup to determine who the client is. There are two ways to work around this issue:
• Alter DNS lookup

• Or set the remote server name in the hosts file, thus avoiding the network lookup.

FTP Adapter: Version: v6.3.4 Q2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FTP Adapter: Version: v6.3.4 Q2

Uploaded by

Copyright:

Available Formats

FTP Adapter

November 10, 2010

1 Terms and Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

4.2 Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

4.3 Certificate Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

4.5 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

7 Master Data Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7.2 Configuring FTP Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

8.3 polling (Polling Messages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8.4 processFtp (FTP Processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.5 listBox (List) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.6 getFile (Get). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.7 Receiving Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.7.1 initiateMessage (Initiate to the System). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.7.2 Return into Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.8 initiateDuplicateMessage (Receiving Duplicate Messages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.9 Receiving Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.10 Report Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.10.1 Correlation Outside of the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.10.2 Correlation Within the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.11 Adapter Invocation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.12 Direct Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.13 Synchronous Adapter Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.14 Worklist Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9.1.1 SEND Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

9.1.2 POLL Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

9.2 Lock File Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.3 Keep-Alive Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.4 Connection Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.4.2 PASSIVE Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

9.5 Security Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

9.6 TLS Client Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9.6.1 Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9.7 Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.8.1 Script Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.8.4 Client-Side Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9.8.5 Script Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9.8.6 Transaction Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.9 Temp File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.10 List Settings (Charset, Locale, NLST and Custom Pattern) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.10.1 Simplified Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.10.2 Custom Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.11 IP Address Caching/Dynamic IP Address Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

13 Server Type Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

13.3.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

13.3.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

13.7.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

13.7.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

13.8 EDISwitch (Ford Solmis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

13.8.1 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

13.8.2 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

13.9.1 General Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

13.9.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

13.9.3 Poll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

13.10 Sterling IIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

13.10.1 General Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

13.10.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

13.10.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

13.11.1 General Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

13.11.2 Send Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

13.11.3 Poll Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

13.11.6 Custom Script File Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

13.12 EDI*Express (GE MARK III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66