-
Notifications
You must be signed in to change notification settings - Fork 1
FILE FTP adapter module parameters
N.B. Данные параметры адаптера доступны и корректно работают в зависимости от версии, SP и PL компонент системы. Просьба не ругать авторов, если ваша версия компонент ниже требуемого
N.B. Минимальная версия SP указана ниже для каждой версии NetWeaver. Отражён минимальный SP, который содержит указанную функциональность. Функциональность может быть доступна только начиная с определённого PL в рамках указанной или последующих SP. Детали применимости -- см. релевантные ноты
Описанные ниже параметры ведутся через табличную настройку, скрытую за опцией Advanced Mode.
| Parameter | Default | Note | Direction | NW 7.31 | NW 7.40 | NW 7.50 |
|---|---|---|---|---|---|---|
| messageLog | false | 2017386 | Receiver | SP011 | SP006 | SP000 |
| messageLog | false | 2046567 | Sender | SP013 | SP008 | SP000 |
| archiveOnException | IGNORE | 2074009 | Sender | SP008 | SP003 | SP000 |
| rfc2640 | false | 2532088 2628188 | Sender/Receiver | SP020 | SP015 | SP009 |
| ftp.forceUTF8 | false | 2532088 2628188 | Sender/Receiver | SP020 | SP015 | SP009 |
| useCanonicalPath | false | 1470921 | Sender | SP000 | SP000 | SP000 |
| ftp.site.sender | (null) | 3023753 | Sender | ※ | ※ | SP021 |
| clusterSyncMode | (see note) | 2029410 | Sender | SP012 | SP007 | SP000 |
| delArchWhenFailed | false | 2485595 | Sender | SP017 | SP012 | SP005 |
| strictHostnameChecking | true | 1591971 | Sender/Receiver | SP003 | SP000 | SP000 |
| ignoreFileModificationError | false | 1859954 | Sender | SP009 | SP004 | SP000 |
| nullCauseModException | false | 1963283 | Sender | SP009 | SP004 | SP000 |
| nonBlockMode | false | 2328288 | Sender | SP015 | SP010 | SP002 |
| triggerFileOption | false | 2300326 | Sender | SP019 | SP014 | SP004 |
| timestampPrecisionSec | false | 2789888 | Sender | ※ | ※ | SP0016 |
| timestampPosition | offline | 2476322 | Sender | SP017 | SP012 | SP005 |
| processACLFile | false | 2609936 | Sender | SP019 | SP014 | SP007 |
| ftpDirList | ignoreSubDirectory | 2549863 | Sender | SP017 | SP012 | SP006 |
| ignoreFileNameCaseSensitivity | false | 2522987 | Sender | SP018 | SP013 | SP006 |
| checkMaxFileSizeWithChunk | false | 2650038 | Sender | SP021 | SP016 | SP010 |
| retainAdditionalFileName | false | 2772088 | Sender | ※ | ※ | SP015 |
| retainFileName | false | 2948130 | Sender | ※ | ※ | SP015 |
| maxNoFilesPerPolling | -1 | 2786478 | Sender | ※ | ※ | SP016 |
| oscomamnd.trace | false | 1334947 | Sender/Receiver | SP000 | SP000 | SP000 |
| storeAttachments | false | 2772112 | Receiver | ※ | ※ | SP015 |
| poolWaitingTime | 0 | 1473299 | Receiver | SP000 | SP000 | SP000 |
| retain.attachment.name | false | 2772112 | Receiver | ※ | ※ | SP015 |
| retain.unzip.attachment | false | 2779800 | Receiver | ※ | ※ | SP012 |
| ftp.site | (null) | 1530149 | Receiver | SP000 | SP000 | SP000 |
| ftp.ignoreChangeDirectory | false | 1530149 | Receiver | SP000 | SP000 | SP000 |
| ftp.fileExistenceCheck | false | 1686989 | Receiver | SP006 | SP000 | SP000 |
File Adapter is being used in the business scenario for message processing at receiver/sender side. When using the file content conversion(FCC) for the file receiver adapter, it's currently not possible to display the content of the converted payload in the message monitoring. Only solution is to access the actual file on file system level, which is not always possible for the interface support team or business.
Advance Development.
File Content Conversion has to be configured in File receiver / sender channel.
This is a new development in PI File Adapter. To get this feature, please configure an advanced mode parameter messageLog to true. By default the value is false.
Archiving faulty files in file adapter does not work properly. Faulty source files are not archived in file adapter even if 'Archive faulty source files option' is selected.
File adapter is designed in a way that it archives the files only for specific exceptions that is thrown from module processor. If any exception apart from these exceptions is caught, file adapter does not recognize this as a permanent error and hence the file is not archived.
The above behaviour of file adapter is now enhanced so that, the file is archived if an additional parameter archiveOnException is set to a string value, which is the cause of the exception that is caught by file adapter.
For example, if the processing of file in file adapter fails due to an exception in an IDOC module with the following exception and cause :
'com.sap.aii.af.idoc.exception.IDOCModuleException', cause: 'java.lang.ArrayIndexOutOfBoundsException'.
To archive the file in this case, one has to add an additional parameter archiveOnException in the advanced mode of the sender channel. Then set the value of this parameter to the cause of the exception i,e ArrayIndexOutOfBoundsException. This value is also available in the audit log.
In general, the parameter archiveOnException has to be set to a string value that is equal to the cause of the module exception. This is now considered as a permanent error and the file will be archived.
Certain FTP servers (like Windows IIS, WS-FTP server) fail to write file names containing special characters or German Umlauts to the target Directory.
Some FTP servers don't use UTF-8 encoding unless the client specifically sends a OPTS UTF8 ON command. If this command is not send from the FTP client, the servers are not able to parse the file names that contain special characters.
Advance development to support special characters in FTP servers that require the client to explicitly send a OPTS UTF8 ON command. To enable the feature, the user has to set the following additional parameters under Advanced tab in the File channel in FTP mode.
rfc2640 = true
ftp.forceUTF8 = true
One file is processed more that once even though the Processing Mode in the configured file sender communication channel is set to Delete or Archive. The corresponding file sender communication channel is configured with the File System (NFS) transport protocol and the Source Directory is a relative path to the file location. Additionally, the file adapter is running in an environment with more than one J2EE server instance or node.
Files configured in the Source Directory of the file sender communication channels are by default resolved by their 'absolute' path. However, this 'absolute' path may not be unique and this could lead to multiple file processing. This could happen when all of the below prerequisites are true:
- The file sender communication channel is configured with the File System (NFS) transport protocol;
- The Source Directory of the file sender communication channel is set to a relative path;
- The file adapter is running in a cluster environment.
On the other hand, each file has one 'canonical' path which is unique for that file in the system. Thus, in order to guarantee that a file is processed only once in the afore-mentioned case, canonical path resolution should be enabled. This could be done by using the useCanonicalPath additional parameter to the file sender communication channel configuration.
To correct this problem apply the following steps:
- Apply the patch matching your support package version as listed in the patch table below;
- Ensure that all files are processed by the communication channels that you are going to reconfigure as described in step 3. Otherwise, if a message for a file is already sent and the post-send operations like file delete or archive are still not executed, then the described reconfiguration may cause duplicate file processing.
- For each problematic file sender communication channel add the entry useCanonicalPath in the Additional Parameters list with value true. This parameter will be ignored if the transport protocol is not set to File System (NFS). Note that the canonical path will be used internally to resolve the file, so there will be no change in the Audit Log of the messages.
In the current PI File adapter, it supports Site command only in File receiver adapter. Currently, there is no option available in the File Sender Adapter to send commands to the FTP Server in the same session. The SITE command along with various parameters is required to be executed on the MVS mainframe system for specific requirements
Special development
To overcome the above limitation and to ensure that File Sender Adapter sends the SITE command to the MVS mainframe systems, the below mentioned enhancement has been introduced. As a result of this development, FTP Sender adapter is now able to execute SITE command, followed by a set of parameters on the mainframe system during message processing. This feature will be an extension to the already existing support SAP Note: 1530149 – Execution of SITE command by FTP receiver adapter
The enhancement involves the following new functionalities:
-
Execution of the SITE command: An advanced mode parameter ftp.site.sender has been introduced that can be configured in the communication channel of FTP Sender Adapter. The value for this parameter could be set as per the requirement. If this parameter is set in the advanced mode table, then the SITE command followed by a set of parameters will be executed on the FTP server after user authentication step. File Adapter will not evaluate what comes after the SITE command and simply passes the set of parameters to the target system.
-
Response to FTP Status/Error codes: After execution of the SITE command, the response code returned by the FTP server will be handled by File Adapter as listed below:
- If the FTP return code is '200', then the command will be treated as successful. The response text will be populated in the audit log and message processing continues.
- If the FTP return code is of type '2xx' series, then it will be treated as 'WARNING'. The response text will be populated in the audit log and message processing continues.
- If the FTP return code is any code other than above two, then it will be treated as 'ERROR'. The response text will be populated in the audit log and message processing will be stopped.
You run a PI installation with several application servers and multiple server nodes on each instance. You have configured a scenario using File Sender communication channel and notice that the channel processes files from a random cluster node. You are not satisfied with the load balancing performed by the system and would like to be able to define which cluster node should process the files.
To avoid duplicate processing of files the File Adapter should ensure that only one cluster node may process the files at a certain moment in time. For that purpose it provides two options to synchronize cluster nodes configured with clusterSyncMode additional parameter in Advanced Mode channel configuration:
clusterSyncMode=scheduler (default) – in this mode the sender’s channel polling job is scheduled to be executed at a single server node; after configured number of executions it may relocate to a different server node; clusterSyncMode=lock – in this mode the sender’s channel polling job is scheduled to be executed at each server node but only the one that succeeds to obtain the channel lock may process the files; it could happen that more than one server nodes may process files during one poll interval, one after another, as there might be some time difference in the job schedule at different nodes. In both cases there is no way to control which exactly server node will process available files.
Follow these steps to configure the File sender channel to schedule its polling job at specific node:
- Open channel configuration in Integration Builder in edit mode;
- Go to Advanced tab and select Advanced Mode option;
- Add Additional Parameter with Name clusterSyncMode and Value node<clusterNodeID>[lock], where the <clusterNodeID> corresponds to the Cluster ID shown in SAP Management Console under AS Java Process Table (<instanceID>50 for server0, <instanceID>51 for server1, <instanceID>52 for server2, etc.) and lock is an optional suffix that defines how the system will behave in case the configured cluster node is not available or becomes unavailable, for example: clusterSyncMode=node9569350 will schedule the job to run at server0 of instance ID95693. In case the node is/becomes unavailable, at the next poll time the surviving nodes will report errors, the channel will go in error state (visible in Communication Channel Monitoring) and alerts can be triggered for the channel to automatically inform the PI Administrators about the problem. If the configured node does not come up and the channel is not reassigned to a different node in 10 minutes, new series of errors (and alerts) will be reported at the next poll time by surviving nodes. To receive the alerts the corresponding Alert Rules have to be configured for the Adapter Engine, clusterSyncMode=node9569352lock will schedule the job to run at server2 of instance ID95693. In case the node is/becomes unavailable, the rest of the server nodes will behave as in lock mode – the one that succeeds to acquire the channel lock will process the files.
Be aware that after transporting/importing a channel configuration that uses the new clusterSyncMode from a different system, the value should be adapted to use <clusterNodeID> of existing cluster node in the current system.
Note that this change will not affect the existing File Sender Channels for which clusterSyncMode is specified as lock or scheduler. Those for which clusterSyncMode is not explicitly specified as Additional Parameter will continue to use the mode specified with the value of service property fileSender.clusterSyncMode of XPI Adapter: File service.
File Adapter is being used in the business scenario for message processing. In FTP mode(at sender side) while trying to process the file(Delete/ Archive) after sending the message to Messaging System, the FTP operation for deletion or archiving might fails due to FTPEx exception. Until the retry happens the file will not be deleted or archived and there is always a chance of getting DuplicateMessageException as processing starts from the begining again.
Currently the File adapter(FTP Mode) implementation is designed in such a way that the file will not be deleted or archived until it resolves the FTPEx exception while executing the FTP commands for delete or archive respectively.
File Adapter in FTP mode of processing and configuring either delete or archive and when the FTP command execution fails with FTPEx exception.
This is a new enhancement in File Adapter(in FTP mode). To get this feature, please configure an advanced mode parameter delArchWhenFailed to true. By default the value is false.
You have File Sender/Receiver communication channels configured with an FTP transport protocol using SSL/TLS(FTPS). Some FTP Servers may return different IP address for the Data Connection that does not correspond to the IP that is used to initiate the Control connection(Command Channel). Despite that the Client Certificate is installed correctly in the keystore, the adapter throws: Peer certificate rejected by ChainVerifier.
When the File communication channels are set to FTPS and the Data Connection is in passive mode, the FTPS Client(File adapter) send PASV command to an FTPS server which returns the IP and the port on which it listens for the data channel. Some FTPS Servers may return different IP address for the data channel from the command channel IP address which cause Peer certificate rejected by ChainVerifier .
A new property set in the Advanced Parameters in the File communication channel is introduced: strictHostnameChecking. Its default value is true which means that the File Adapter performs a strict host name check. If this property is set to false, this check is omitted which allows to create successfull data connection to a different from command connection IP address.
File Adapter is being used in the business scenario for message processing and additional parameter "Msecs to Wait Before Modification Check" has been configured (as mentioned in Q3 of note 821267) in File Sender channel to avoid incomplete Processing of files. While processing the files, it has been noticed that, when the file is modified, adapter aborts file processing and the following ERROR message has been shown in the Audit Log of XI Message: Channel <name>: Sending file "<file name>" failed: File has been modified during processing. Expected XXX bytes, found XXX bytes -Retrying
Program error
An advanced mode parameter ignoreFileModificationError has been introduced that can be configured in the communication channel of File Sender Adapter. The value for this parameter could be set as per the requirement. If this parameter is set to true in the advanced mode table and file is changed during processing, the message "Channel <name>: Sending file "<file name>" failed: File has been modified during processing. Expected XXX bytes, found XXX bytes -Retrying" with Type "Warning" will be shown in the Audit Log instead of Type "Error". The File will be processed successfully when two consecutive files will be found with same length.
The default value for the parameter ignoreFileModificationError is false, which means that, the message will be shown as Type "Error" in Audit Log like before.
File adapter is being used at the sender side and Archive faulty Source Files option is selected to archive files when the processing of the file fails with permanent error. When the Exception thrown from the configured module (ModuleException(me)) does not have any cause(i,e me.getCause is null), the file is not archived in the specified ErrorArchive directory.
Program Error.
When the Exception thrown from the configured module does not have any cause, file adapter does not consider it as permanent error. Hence the file is not archived in the Error Archive directory.
The issue is resolved by code changes. In the advanced tab of the sender channel configuration, add the parameter nullCauseModException and set the value to true. Now the file will be archived to the specified error archive Directory. By default, the value of the parameter is false.
File adapter is used at the sender side with Enable Duplicate Handling feature selected in the channel. When a file is identified as a duplicate, a DuplicateMessageException is thrown and the remaining files in the source folder are blocked and cannot be processed. The issue happens with both NFS and FTP mode. Below error is visible in default traces:
The current duplicate count for file (filename) with last modified time XXXX has exceeded the default message alert threshold value and this message will be skipped without processing.
The duplicate handling feature was implemented in such a way that if a file processing fails beacuse of a DuplicateMessageException, then further processing of the files will not happen.
Code correction is done so that when a file is identified as a duplicate, DuplicateMessageException is thrown for this file and remaining files in the source folder are processed. In every successive poll, this file will be identified as a duplicate with an error message until and unless it is removed from the source folder. To get this solution, an advanced parameter nonBlockMode has to be added with value set to true in the Advanced mode table of the file sender channel. Default value of this parameter is false.
When an application writes a batch of files to the source directory, the File Adapter should not pick up the files until the entire batch is written. The files should be processed once the batch is complete.
The completion of the batch is indicated by writing a file with .trigger to the source directory.
The feature prevents the File Adapter from picking up files from an incomplete batch.
The Additional Parameter triggerFileOption is to be set to true in the Advanced Tab of the Sender Channel configuration. In the source directory, the files will not be picked up by the File Adapter until the trigger file (a file with .trigger extension) is written. The file name and the content of the trigger file does not matter. Once the trigger file is written, all source files written before the trigger file, are processed. If there are multiple trigger files in the source directory, source files written before the latest trigger file are processed. Once the source files are processed, the trigger file(s) is (or are) deleted.
If the user does not have the permissions to delete the trigger file, an error saying UNABLE_TO_DELETE_TRIGGER_FILE is displayed in the channel monitor page.
You are using FTP sender channel and you have configured additional parameter triggerFileOption = true. You have observed some of the source files are not processed in correct batch. For example:
Files in Source Directory:
1.txt with time 10:20:04 AM
2.txt with time 10:21:54 AM
3.txt with time 10:22:05 AM
x.trigger with time 10:22:50 AM
In FTP sender channel:
File Name: *.txt
You have observed, 3.txt was not processed in the current batch (File 3.txt was written before x.trigger but has same timestamp as the up to minutes precision)
As per the current design, we are getting the timestamp from FTP LIST command. But FTP LIST command has limitation as it considers the timestamp only up to minutes (i.e., HH:MM). So, we are getting same timesatmp 10:22 for both File 3.txt and x.trigger. Hence, files like 3.txt are not processed in the correct batch.
A new additional parameter in FTP sender channel is introduced: timestampPrecisionSec. By default, the parameter is set to false. When the value is false, adapter will have the default existing behavior (get the timestamp using LIST command). When set to true along with triggerFileOption = true, all the source files written before the trigger file will be processed.
Note: If your FTP server follows the specification RFC 3659 (FTP command MDTM), then FTP server will return the timestamp precision to seconds. So, set parameter timestampPrecisionSec= true, if your FTP server follows the specification RFC 3659.
RFC 3659 specification can be found at: https://tools.ietf.org/html/rfc3659#page-8.
The sender side configuration of file adapter has an option to add timestamp to the filename during message processing. Add timestamp option is available for both archive processing mode and archive faulty source files. Positioning of timestamp in these two cases is not similar i.e. in archive processing mode the timestamp is prefixed to the filename and for archive faulty source file the timestamp is suffixed to the filename.
File adapter is designed in a way that timestamp is prefixed for archive processing mode and is suffixed for archive faulty source file.
A new additional parameter in File sender channel is introduced: timestampPosition. If this parameter is set to prefix then the timestamp for both archive processing mode and archive faulty source file is prefixed to the filename or else if the parameter is set to suffix then the timestamp for both archive processing mode and archive faulty source file is suffixed to the filename.
The default behaviour (offline) will be existing behaviour i.e. prefix for archive processing mode and suffix for archive faulty source file. When the parameter is not set it will have default behaviour.
Access Control List (ACL) on file system provides better file security and a more flexible permission mechanism. Files with an ACL permission is not processed from file adapter.
In the existing design, files which have file permission of format <user><group><other> (i.e. -rwxrw-r--, -r--r--r-- etc) are treated as a valid file during file processing.
Files with an ACL has an additional "+" along with the file permission (i.e. -rwxrw-r--+, -r--r--r--+ etc). These files are not treated as valid and will not be processed from file sender channel.
A new additional parameter in File sender channel is introduced: processACLFile. The default value of this parameter is false.
Set the paramter to true, to process the files which has an Access control list (ACL) permission.
Files from subdirectories are recursively listed when wildcard(*) is used in the filename configuration at sender side.
Some ftp servers recursively list files from subdirectories when a wildcard(*) is used as a part of filename.
A new additional parameter in File sender channel is introduced: ftpDirList.
The default value of this parameter is ignoreSubDirectory. When the parameter's value is ignoreSubDirectory, the files present in the subdirectories are ignored and are not processed. It is not required to set this parameter explicitly as this is the default behavior.
If the parameter is set to verifyRecursive, an additional check will be performed to verify if the files listed are present in the source directory. As an additional check is included, message processing might require some additional time.
If the parameter is set to none, no check for recursive listing is done. This might lead to processing of files from subdirectories, which might cause exceptions like FileNotFound.
If the parameter is set to both, the behavior of both ignoreSubDirectory and verifyRecursive are enabled together.
With this source code changes, the additional parameter ftp.ignoreOsForListCmd from note "2511742 - FTP servers behave differently by returning different output structures for file listing command" can be skipped.
You have used wildcard in file name of Sender FTP channel along with “Msecs to Wait Before Modification Check”.
The current observations are:
- When “Msecs to Wait Before Modification Check” is not configured, filenames are matched ignoring the case of file name(case-insensitive).
- When “Msecs to Wait Before Modification Check” is configured, it is failing with error - FILE NOT FOUND.
In some FTP Servers file listing is done without considering the case sensitivity of file names. This depends on the OS on which the FTP server resides. Usually on Unix systems, the pattern matching is case-sensitive, and on Windows systems the pattern matching is case-insensitive.
Example:
Files in Source Directory: TEST.TXT and input.txt
File name in channel configuration: *.txt
Case 1: Case-sensitive Matching will return input.txt
Case 2: Case-insensitive Matching will return both TEST.TXT and input.txt
In the existing design, when wildcard is configured along with “Msecs to Wait Before Modification Check”, file matching is case sensitive.
A new additional parameter in File sender channel is introduced: ignoreFileNameCaseSensitivity. The default value of this parameter is false. If you set this parameter to true along with “Msecs to Wait Before Modification Check”, then file name is matched ignoring the case of file name (case-insensitive).
Note: Set this parameter only if “Msecs to Wait Before Modification Check” is configured and your FTP server list files without considering the case sensitivity.
You are using sender file channel with QOS: EOIO. When "Maximum File Size" is configured along with "Chunk Mode"
- Sometimes file is processed even if the File Size is greater than the configured "Maximum File Size" and
- Sometimes you are getting error: The input file has exceeded the maximum size of xxx bytes and file is not processed
According to the current design, when "Max File Size" is configured along with "Chunk Mode", then it considers the "Maximum chunk size" and starts reading the chunk
- If "Maximum File Size" < "Maximum chunk size", we observe Error: The input file has exceeded the maximum size of xxx bytes and file transfer is aborted
- If "Maximum File Size" > "Maximum chunk size", file is processed according to "Maximum chunk size".
A new additional parameter in File sender channel is introduced: checkMaxFileSizeWithChunk. The default value of this parameter is false. If you set this parameter to true along with “Chunk Mode” and “Maximum File Size” -
- You get Error: The input file has exceeded the maximum size of xxx byte, if the File Size is greater than the "Maximum File Size".
- File is processed according to the “Maximum chunk size”, if the File Size is less than the "Maximum File Size".
In file adapter when Additional File(s) configuration is set, the attachment name in the message properties is set to the name configured in the File List parameter by default.
As per existing design, by default name of the additional file is set as mentioned above.
A new additional parameter in the File sender channel is introduced: retainAdditionalFileName. By default the parameter is set to false.
When the value is false, adapter will have the default existing behavior. When the value is true, the original name of the additional file is retained in the message properties.
In sender file adapter, file name in the message properties is set to MainDocument by default.
As per existing design, by default name file is set as mentioned above in message properties
A new additional parameter in the File sender channel is introduced: retainFileName. By default the parameter is set to false.
When the value is false, adapter will have the default existing behavior. When the value is true, the original name of the file is retained in the message properties.
When there is a large number of files in the source directory, reading all the files in a single polling interval might cause high overhead on the server node.
In the existing design, it is not possible to restrict the maximum number of files to be read per polling cycle.
A new additional parameter is introduced at file sender channel: maxNoFilesPerPolling. Default value of the parameter is -1. By default, all the files from the source directory are read in a single polling interval. To limit the maximum number of files that should be polled in a single polling interval, set the parameter to a desired positive integer value (1, 2 .. so on).
NOTE: If the value for this parameter is set to 0, all the files present in the existing directory will be picked up in single polling interval.
The "OS command execution error" can be logged only when the File Adapter trace level is set to "Debug". These errors are not logged when File Adapter trace level is set to "Error"
This is corrected to be available when the trace level is set to "error" by using an advance mode parameter. Configure the advance mode parameter oscomamnd.trace and value true in the Advanced Mode tab of the file sender or receiver channel depending where the OS command is being executed.
If the value of oscomamnd.trace is set to true then the trace file will contain the trace statements when the trace level is set to Error If this parameter is not configured, then the trace statements will be logged only when the trace level is set to Debug
#storeAttachments
Store attachment feature is missing in FTP mode.
Missing feature.
To avail store attachment feature in FTP mode, set storeAttachments in the Advanced Mode tab. Default value of the parameter is false. When the parameter is set to true, attachments are stored in the target directory.
By default the attachment name is <attachmentName>_<MainPayload_name>. To retain the filename of the attachment, set the parameter retain.attachment.name to true.
FTP/JDBC Adapter is being used in the business scenario for message processing. At the receiver side, Maximum Concurrency Parameter is used to acquire parallel FTP/DB connections for the same receiver FTP/JDBC channel. When Maximum concurrency is 1, then the value of the parameter poolWaitingTime will be 0 (by default). This is to make sure that the channel can wait infinitely to get the FTP/DB connection. For more information about these parameters please have a look at point 47 in SAP Note 821267. Due to the above settings of poolWaitingTime, the thread of receiver file/jdbc adapter will remain in runnable state leaving the message in waiting status forever.
Special development
As a result of this special development, threads of receiver file/jdbc adapter will be prevented to go into 'wait' status forever. Now, the parameter poolWaitingTime can be set to some positive value (i.e., > 0) under Advanced Mode tab in the channel configuration even if Maximum Concurrency is 1. In this case, the value of the parameter poolWaitingTime will be taken from the channel configuration while execution. If the parameter poolWaitingTime is not set in the Advanced Mode tab, then no action would be taken on the message processing and the behaviour will be same as before: message will wait in the resource pool till it gets the resource.
PayloadZipBean is used to unzip files and retain.attachment.name is set to true in the Advanced Mode tab of File Adapter receiver to retain the filenames from the zip file. But one of the attachment file names gets replaced by main file name and remaining attachments retain the filenames from zip file.
PayloadZipBean unzips all the files, setting the first one as a main payload of the XI message and all the rest as attachments.
Main payload name will get overwritten with the receiver side configurations.
Source code changes to resolve the issue.
Use the parameter retain.unzip.attachment to retain the filename of main payload.
retain.unzip.attachment : Default value of the parameter is false. When PayloadZipBean is used to unzip the file and retain.attachment.name is set to true, by default one of the attachment file names gets replaced by main file name and remaining attachments retain the filenames from zip file. This is the default behavior ( i.e. when the parameter value is false). When PayloadZipBean is used to unzip the file, the first one in the zip file is set as main payload of the XI message and its filename is overwritten with receiver side configurations. To retain the filename of the main payload with the attachment name, set this parameter to true.
FTP Adapter is being used in the business scenario for message processing. At the receiver side, the SITE command along with various parameters is required to be executed on the MVS mainframe system for specific requirements. For eg., some parameters like record format (RECFM), record length (LRECL), block size (BLKSIZE) etc are required to be sent in order to send the file in a specific format to the MVS Mainframe system. Currently, there is no option available in the File Receiver Adapter to send commands to the mainframe systems that is not in the same network where PI is installed.
Special development
To overcome the above limitation and to ensure that File Receiver Adapter sends the SITE command to the MVS mainframe systems, the below mentioned enhancement has been introduced. As a result of this development, FTP receiver adapter is now able to execute SITE command, followed by a set of parameters on the mainframe system during message processing.
The enhancement involves the following new functionalities:
Execution of the SITE command:
An advanced mode parameter ftp.site has been introduced that can be configured in the communication channel of FTP Receiver Adapter. The value for this parameter could be set as per the requirement. If this parameter is set in the advanced mode table, then the SITE command followed by a set of parameters will be executed on the FTP server after user authentication step. FTP server will not evaluate what comes after the SITE command and simply passes the set of parameters to the target system. When the target system, i.e. the MVS mainframe receives these parameters, it prepares to create the incoming file using these parameters.
The default value for the parameter ftp.site is (null).
Response to FTP Status/Error codes: After execution of the SITE command, the response code returned by the FTP server will be handled by File Adapter as listed below:
- If the FTP return code is '200', then the command will be treated as successful. The response text will be populated in the audit log and message processing continues.
- If the FTP return code is of type '2xx' series, then it will be treated as 'WARNING'. The response text will be populated in the audit log and message processing continues.
- If the FTP return code is any code other than above two, then it will be treated as 'ERROR'. The response text will be populated in the audit log and message processing will be stopped.
Suppressing CWD command: An advanced mode parameter ftp.ignoreChangeDirectory has been introduced. If this parameter is set to true, the 'CWD' command will not be executed and the file will be placed in the default directory, not the directory specified in the communication channel configuration. This is a feature that would also be useful for communication with non-MVS systems where we want the target server to decide where to place the file.
The default value for the parameter ftp.ignoreChangeDirectory is false.
FTP Adapter is being used in the business scenario for message processing. During file processing, it is noticed, that, the file is getting overwritten to the FTP server, even if it already exists and overwrite option is unchecked. This issue occurs only if the ftp server resides on the Unix environment. The configuration in such scenario would be as follows: File Construction Mode=Create, Overwrite Existing File=false, Write Mode= Use Temporary File.
Advance development
An advanced mode parameter ftp.fileExistenceCheck has been introduced. If this parameter is set to true, then the additional check from File Adapter side will be performed to check whether the file already exists in the target directory or not. If the file already exists, then an exception is thrown indicating the same. Else normal execution continues.
The default value for the parameter ftp.fileExistenceCheck is false.