Table of Contents
1. Information to Include in OSS Message
2. Read-Only File Processing
3. File Locking / Incomplete Processing
4. FTP Sender File Processing in Cluster Environment
5. File Receiver: Overwrite Protection
6. Acknowledgements
7. File Construction Mode "Add Time Stamp" and "Add Counter" in Cluster Environment
8. FTP Adapter Timeout Configuration
9. Module Development: Accessing the Source File Name from a Module
10. <RecordSetName>.fieldContentFormatting=nothing and SXMB_MONI
11. File Sender: Processing Multiple Source Directories
12. File Sender: Quality of Service EOIO (Exactly Once In Order)
13. File Receiver: FTP Problems for Large Files with Microsoft IIS
14. Memory Requirements
15. Operating System Command
16. File Encoding
17. Empty File Encoding Parameter
18. File Sender: Scheduling
19. Secure FTP (FTPS)
20. File Sender: Special Characters in File Names
21. File Sender: Performance Issues After Configuring A Large Amount Of Channels
22. File Sender: File Modification Check For Transport Protocol "FTP"
23. FTP: Active Data Connection Support
24. FTPS: Server certificate rejected by ChainVerifier
25. FTP Proxy Support
26. FTP Connection Problems
27. FTP Directory Listing Semantics
28. sftp Support
29. File Content Conversion fieldFixedType Parameter Not Working
30. Missing Features After Upgrade
31. Empty File Processing
32. File Construction Mode "Add Counter": Counter Reset
33. FTPS: "AUTH TLS" Command Unrecognized
34. FTP: Directory Specification / CWD Command
35. File Sender Error Handling
36. FTP: Adapter Polls More Frequently Than Configured
37. FTP: sun.io.MalformedInputException
38. Windows (SMB) Shares
39. FTP Sender: 550 File Not Found
40. Known Problems and Incompatibilities for FTP servers
41. Test FTP Server Connection
42. Channel prioritization using OS command
43. J2EE engine hangs with File/FTP sender channels
44. File Receiver with append mode on multiple cluster nodes
45. Receiver File Adapter stuck while using temporary file.
46. How to manually delete hanging Enqueue-Locks
47. Effect of setting Maximum Concurrency and poolWaitingTime
Questions and Answers
1. Information to Include in OSS Message
Q: I need to open an OSS message regarding the File Adapter with SAP. Which information should I put into the message?
A: Refer to note 854536.
2. Read-Only File Processing
Q: I have configured a File Adapter sender channel to process a source file to which it only has read-only access (e.g., because it has been written by a different OS user). The file is not processed, but the channel is nevertheless listed as working in the Adapter Monitoring. Have I encountered a bug?
A: This behavior is by design: The File Adapter sender channel does not process read-only files by default. As this is intended, you will never see an error message indicating this condition in the Adapter Monitoring or log. To enable processing of read-only files, set the "Files Locked (Read-Only)" flag for the respective sender channel.
3. File Locking / Incomplete Processing
Q: I sometimes observe that files are processed only partially, i.e., only a fragment from the file's start is converted into an XI message. Nevertheless, the file is usually archived completely. Does the File Sender Adapter honor if another process has locked a file for exclusive use?
A: Unfortunately, the J2EE 1.3 technology the File Adapter is built upon does not support file locking. This limitation affects the File Adapter's operation. Depending on whether the JRE implementation for the operating system under which the adapter runs uses mandatory file locking or advisory file locking, opening a file that is currently being written to by another process will fail or not.
If opening the file fails, no problem exists and the adapter will try to open the file each poll interval until it succeeds.
However, if opening the file is not prevented by the operating system, the adapter starts to process the file although it is still being modified. Since XI 3.0 SP11 / PI 7.0 there is a parameter named "Msecs to Wait Before Modification Check" in the advanced settings of the File Sender channel configuration to work around this issue. This setting causes the File Adapter to wait a certain time after reading, but before sending a file to the Adapter Engine. If the file has been modified (which is basically determined by comparing the size of the read data with the current file size of the input file) after the configured interval has elapsed, the adapter aborts the processing of the file and tries to process the file again after the retry interval has elapsed.
If this option is not available for the settings you would like to use, the following algorithm (to be implemented in your application) may be used to ensure that the File Adapter only processes completely written files:
Create the file using an extension, which does not get processed by the File Adapter, e.g., ".tmp"
Write the file content
Rename the file to its final name, so the File Adapter will notice its existence and pick it up
4. FTP Sender File Processing in Cluster Environment
Q: When running the File Adapter in an environment with more than a single J2EE server instance, the same file is fetched by multiple cluster nodes at once. How do I solve this problem?
A: Initially, make sure that you do NOT use the processing mode "Test" for your File Sender channel. This mode is intended to be used only for testing purposes and is not guaranteed to work in a cluster environment.
Additionally, activate the "Advanced Mode" for the respective sender channel. No further configuration changes are necessary. Alternatively, upgrade to XI 3.0 SP11 Patch Level 2 or XI 3.0 SP12. Later XI 3.0 versions / PI 7.0 are not affected.
5. File Receiver: Overwrite Protection
Q: When running a File Adapter Receiver <= XI 3.0 SP9 with a File Construction Mode "Create", target files are overwritten although the "Overwrite Existing Files" setting is not active in the Receiver channel. How do I solve this problem?
A: This problem has been corrected with XI 3.0 SP10. PI 7.0 is not affected.
6. Acknowledgements
Q: Does the File Adapter support acknowledgements?
A: You need to distinguish system acknowledgements (indicating that a message has been received by the target system) and application acknowledgements (indicating that the message has been successfully processed by the application on the receiver side).
The receiver of an XI message will only send an acknowledgement back to the sender if the sender has requested one. However, the File Adapter has no functionality that relies on the receipt of an acknowledgement, so it never requests one.
On the other hand, if a File Adapter Receiver receives a request to send an acknowledgement, it will do so for a system acknowledgement request. Application acknowledgements are not supported at all as the File Receiver has no way to determine if the written file has been correctly processed by the back-end application, which is what a positive application acknowledgement would imply.
7. File Construction Mode "Add Time Stamp" and "Add Counter" in Cluster Environment
Q: We have set up a File Adapter Receiver on an XI installation with multiple server nodes. The receiver channel is configured to use the File Construction Mode "Add Time Stamp" or "Add Counter". We have noticed, that sporadically two messages are written to the same file name. How can we work around this issue?
A: If you are using the transport protocol "File System (NFS)", apply note 869234. For the transport protocol "File Transfer Protocol (FTP)" the time stamp and counter is not guaranteed to be unique across cluster nodes, so two messages delivered to the same receiver channel at the same time on different cluster nodes might cause the target to be overwritten by the second message. If you need to create truly unique files by the receiver, use the File Construction Mode "Add Message ID".
8. FTP Adapter Timeout Configuration
Q: We are using the FTP Adapter to send or receive messages from/to an FTP server, which is sporadically experiencing connectivity problems. This causes the FTP Adapter to hang. Is there any way to configure a timeout?
A: Refer to note 849089.
9. Module Development: Accessing the Source File Name from a Module
Q: When processing a message originating from a File Adapter Sender channel, how do I access the original name of the file read by the File Sender channel from within a module?
A: See note 819761 for a HOWTO.
10. <RecordSetName>.fieldContentFormatting=nothing and SXMB_MONI
Q: We have configured a File Sender Adapter with File Content Conversion not to remove the whitespace around fixed-width fields from the input file by setting the parameter <RecordSetName>.fieldContentFormatting to "nothing". Nevertheless, the whitespace seems to be trimmed as we can see in SXMB_MONI. Have we encountered a bug?
A: SXI_MONITOR displays an interpreted version of the XML payload, which unfortunately hides the whitespace. Nevertheless, this whitespace is still present in the generated XML file as you will see if you send the message to a File Adapter Receiver that writes the payload to a file.
