31. Empty File Processing
Q: How does the File Adapter handle empty files and messages with a zero-sized payload?
A: Up to and including XI 3.0 SP18 / PI 7.0 SP9 empty files in the sender adapter will not trigger the creation of a message. If an empty message is sent to a receiver channel, no output file will be created.
Starting with XI 3.0 SP19 / PI 7.0 SP10 the channel's behavior can be configured in Integration Builder.
Q: I configure the receiver channel with File content conversion mode and I set the 'Empty Message Handling' option to ignore. Input payload to the receiver channel is generated out of mapping and it does not have any record sets. However, this payload has a root element. Why does file receiver create empty output file with zero byte size in the target directory? Example of such a payload generated from mapping is as follows: <?xml version="1.0" encoding="UTF-8"?> <ns1:test xmlns:ns1="http://abcd.com/ab"></ns1:test>
A: If the message payload is empty (i.e., zero bytes in size), then File adapter's empty message handling feature does NOT write files into the target directory. On the other hand, if the payload is a valid XML document (as shown in example) that is generated from mapping with just a root element in it, the File Adapter does not treat it as an empty message and accordingly it writes to the target directory. To achieve your objective of not writing files (that have just a single root element) into the target directory, following could be done: - Either modify your mapping so that empty message payload without a root element is generated. This could be done only by creating a Java mapping and implement the logic to convert from root element to an empty text. This can not be done using Message Mapping tool. - or, use a module based approach, e.g., using the StrictXml2PlainBean, where such a valid XML payload is converted to an empty payload before the file receiver channel is invoked.
32. File Construction Mode "Add Counter": Counter Reset
Q: After configuring a File Adapter receiver channel with the File Construction Mode set to "Add Counter", I noticed that the counter gets reset each time I restart the J2EE engine.
A: This behavior is by design. The current counter value is not persisted, but only kept in memory. It is intended to generate distinct file names, but not strictly increasing numbers. After a J2EE restart, the File Adapter will start writing messages beginning with the smallest free counter number (skipping existing larger numbers).
33. FTPS: "AUTH TLS" Command Unrecognized
Q: After configuring a File Adapter channel with the Transport Protocol "FTP" and connection security set to "FTPS", I receive the following error in the adapter monitoring: Syntax error, command unrecognized: 'AUTH TLS'
What is causing this?
A: Your FTP server implementation does not implement FTPS as specified in RFC 4217. For details, contact your FTP server vendor.
34. FTP: Directory Specification / CWD Command
Q: Is there any way to configure a File Adapter channel with the Transport Protocol "FTP" without an explicit source / target directory, so that no CWD command will be issued?
A: The directory specification is mandatory. According RFC 1123 an FTP server is required to support the CWD command.
35. File Sender Error Handling
Q: I have configured a File Sender channel with File Content Conversion or a custom-developed module, which may throw an exception. When the File Adapter encounters an invalid file, which triggers a conversion error or an exception in a module, the adapter will enter a retry interval and upon each following processing attempt try to process the faulty file. This basically prevents the File Adapter from picking up files that are located after the fauilty file according to the configured sort order. How can I change this behavior?
A: This is by design. When the File Adapter encounters an invalid file, manually remove this file from the configured source directory. You can configure an alerting rule to get notified each time this occurs.
We are currently evaluating possible solutions that could be used to skip this manual interaction.
36. FTP: Adapter Polls More Frequently Than Configured
Q: I have configured a File Adapter Sender channel with the transport protocol "FTP". When no file is present in the configured input directory, the adapter connects to the FTP server at least once a second or even more frequently. What is causing this?
A: Most likely, this behavior is caused by an implementation error in the FTP server, which you are connecting to:
The FTP protocol specification (RFC 959) requires that when issuing a NLST command to retrieve a file list for a given wildcard pattern a list of valid file names gets returned. Error messages must be transmitted via the control channel. From the specification:
"NAME LIST (NLST)
This command causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor; a null argument implies the current directory. The server will return a stream of names of files and no other information. The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by <CRLF> or <NL>. (Again the user must ensure that the TYPE is correct.) This command is intended to return information that can be used by a program to further process the files automatically. For example, in the implementation of a "multiple get" function."
However, your FTP server returns a human-readable error message in the data connection instead of a file list when no files match the wildcard pattern (the channel's file name mask) provided to the NLST command, which is - in compliance with RFC 959 - interpreted as a file name by the File Adapter.
An example FTP session:
[...]
ftp> ls file*.txt
200 PORT command successful.
150 ASCII data connection for /bin/ls
file*.txt: No such file or directory
226 ASCII Transfer complete.
[...]
The line causing the problems reads:
file*.txt: No such file or directory
As this line is interpreted as a file name by the File Adapter (as per RFC 959), the File Adapter will try to retrieve this file, which will - of course - fail. However, as the FTP server has returned at least one (although invalid) file name, the File Adapter will immediately poll again for new files. This is by design and cannot be configured.
The root cause of the problem is the incorrect reply of your FTP server, so you will have to contact your FTP server vendor for a correction, which provides a RFC 959 compliant implementation of the FTP protocol.
37. FTP: sun.io.MalformedInputException
Q: I am trying to connect the File Adapter to an FTP server, which uses non-ASCII replys over the control connection, e.g. the server replys contain German umlauts or accented characters. However, the File Adapter just displays an error referring to sun.io.MalformedInputException when trying to establish the connection. How can I solve this?
A: Configure the "file.encoding" system property to match the encoding returned by the FTP server. For details, refer to the answer to Q20.
38. Windows (SMB) Shares
Q: Using a File Adapter channel I would like to retrieve files from and/or write files to a Windows (SMB) share. Which considerations do I need to take into account?
A: When the Adapter Engine hosting the File Adapter service is running under Microsoft Windows, make sure that the share is accessible for the user "SAPService<SID>" under which the File Adapter is operating. If the share is mapped to a drive letter, make sure that this mapping exists for the "SAPService<SID>" user. UNC paths are typically supported under Microsoft Windows. When the Adapter Engine hosting the File Adapter service is running under UNIX, make sure that the SMB share is mounted into the local file system hierarchy and accessible to the "<sid>adm" user. Note that UNC paths are typically not supported under UNIX. For details, contact your operating system vendor.
39. FTP Sender: 550 File Not Found
Q: I have configured an FTP sender channel, which however fails to retrieve files during each polling interval. Instead, it gives an error message similar to: "550 File Not Found" (the actual wording depends of the FTP server software, which is not provided by SAP). How can I fix this?
A: Configure an absolute source directory (usually starting with a slash) instead of a relative one.
40. Known Problems and Incompatibilities for FTP Servers
Q: What are the known problems and incompatibilites for third party FTP server implementations ?
A: Please refer to note 1052867.
41. Test FTP Server Connection.
Q: How to Test FTP Server Connection.?
A: Please refer to note 1085539.
42. Channel prioritization using OS command
Q: I wish to configure two sender File channels sothat second sender channel processes only after first sender channel has finished sending message to XI using an external OS command . I wish to select quality of service as Exactly Once In order(EOIO) for both channels and wish to configure the same queue name for both channels. This way, I want to see that all the messages from second channel are processed only after first channel. Is this supported ?.
A: This is not supported as each channel execution is independent of other channel. Though this may seem to work for most cases we do not guarentee that "at all times" message order is guarenteed. One of the reasons is, though messages from two channels go into the same queue, they may not arrive at the queue in the order that we expect.
43. J2EE engine hangs with File/FTP sender channels.
Q: J2EE engine hangs with the File/FTP sender channels. How to resolve this ?
A: The reason for this is, some times due to network level issues, a message is waiting forever for a response from a FTP server which is down for some time. Adapter does not know this and try to poll FTP server again with second message. This goes on and on and eventually we would have J2EE engine hanging. To solve this, following things need to be applied:
1) Set FTP timeout to appropraite value if channel is FTP sender channel.
2) In advanced mode table options, add a new parameter 'clusterSyncMode' and its value set to 'lock'. This parameter is without single quotes and case-sensitive. Please read SAP note 801926 to know more about this option.
3) Last but not least, make sure that you are in latest patches of SP19/SP20/SP21/SP22 for SAPXIAFC component of XI 3.0 release and SP10/SP11/SP12/SP13/SP14 for SAPXIAFC component of XI 7.0 release. Any patch which is released after 11th of Febraury 2008 for the above releases is fine.
44. File Receiver with "append" mode on multiple cluster nodes.
Our landscape has file receiver channels configured to use "append" operation. J2EE engine is running on multiple clustered nodes with mulitple central instances and multiple dialog instances. Central instance is running on one physical host and dialog instance is running on another physical host. All cluster nodes need to access the same file to write data in append mode. Do we support this case ?
A: Detailed answer is given in SAP note 1162687.
45. Receiver File Adapter stuck while using temporary file.
Q :The thread of receiver file adapter remains in runnable while
Communication channel has the following configuration
File Construction Mode=Create, Overwrite Existing File=false, Write Mode= Use Temporary File.
A :The Receiver file adapter thread is stuck in the runnable state when the temporary file is used and over writing of existing file is set to false. Since the temporary file was not being deleted and the overwriting of existing file i.e. target file was set to false, the thread would never end. This problem has been fixed by deleting the temporary file after being named to the target file.
The error is corrected with SAPXIAF06P patch#8 (Support Package -level #06).
46. How to manually delete hanging Enqueue-Locks
Q :During the OOM error the J2ee engine goes down while the lock in the enqueue server still persists.When the channel comes back during restart as the effect of OOM error it will not able to get the cluster wide enqueue lock as the previous lock remains there in the enqueue server.How do I resolve this?
A :The existing (hanging) enqueue server locks for the corresponding FILE channels(with FILE Lock Arguments) can be deleted manually by following procedure:
1. Stop the corresponding FILE channel.
2. Open Visual Administrator.
3. Route to correspondig server.
4. Expand services and go to Locking adapter.
5. In the locking adapter service go to Display locks tab and click on refesh button then you will able to see the list of all the available locks.
6. Select the existing (hanging) enqueue lock with FILE Argument from the list.
7. Click on "Delete Selected Locks" button.
47. Effect of setting Maximum Concurrency and poolWaitingTime
Q: What is the meaning of different values of Maximum Concurrency? How should be poolWaitingTime set for different values of Maximum Concurrency?
A: Maximum Concurrency Parameter is used to acquire parallel FTP connections for the same receiver File/FTP channel.
Maximum Concurrency = 1
This is the default value of Maximum Concurrency. This means a single receiver File/FTP channel can acquire only one FTP connection. This case does not offer any parallel processing of messaging by single channel.
Maximum Concurrency > 1
This ensures that resource pool size (FTP conneciton size) is limited to specified value per single File/FTP receiver channel. For instance, setting this parameter to 2 will ensure that a single receiver File/FTP channel can acquire 2 FTP connections in parallel(if needed).
poolWaitingTime
This timeout value will define the maximum waiting time to get the connection from resource pool. If connection is not available within this time, we return the message to Messaging System and the message is in retry mode.
The configuration of this timeout requires the use of an advanced mode configuration parameter.
To configure a timeout for the File/FTP receiver channels, please enable the "Advanced Mode" for the respective File/FTP communication channel in the Integration Directory and add an entry "poolWaitingTime" and set to a time in Milli Secs (without any quotation marks) to the "Additional Parameters" section. This parameter is case-sensitive.
The default value of this parameter is 5000 Milli Secs.
The default value ensures a channel will wait 5000 Milli Secs before aquiring connection.
1. Maximum Concurrency = 1
When Maximum concurrency is set to 1, poolWaitingTime should be set to 0. This makes sure that the channel can wait infinitely to get the FTP connection. This will prevent messages to get into error state un-necessarily.
2. Maximum Concurrency > 1
Before setting this, please apply note 1136790. For Maximum Concurrency > 1, this note should be applied and then only proceed with the following.
When Maximum Concurrency > 1 poolWaitingTime must be set to an optimal value. This should be more or less equal to time required to aquire a connection on a remote FTP/DB. If this is not known, set this to 1 min(60000 Milli Secs). This will ensure that, if channel cannot get the FTP connection with in the time specified then after 3 retries the thread will be released for other channels and message back-log can be reduced.
