This blog is the extension of following blogs.
Whenever large (binary) file needs to be transferred by using PI, there might be a chance for Out of Memory error which might results in server restart. Technically, it often fails in the sender adapter.
The most popular work around is to split the file in to multiple parts in Sender Adapter and Combining them in Receiver Adapter (via OS Scripts)
From PI 7.30 onwards File/FTP adapter natively supports transferring large size files by splitting them in to smaller chunks based on the configured size. Each chunk will be processed as an individual XI Message in sender adapter and all the chunks are combined based on the sequence in receiver adapter. Since all the chunks have to be combined in the actual order, QoS EOIO has to be used to enable this feature.
Select 'EOIO' as a QoS under Processing tab.
After that select 'Advanced Mode' under 'Advanced' Tab
You can choose the required chunk size option from the given list of 1, 2, 5, 10, 20 and 50 MB.
Custom values which are not possible in default options can also be configured in additional parameters.
Parameter Name | Possible Values |
chunkMode | Non emptry string will be considered as true |
chunkSizeKB | Positive Numeric Value |
Sender Adapter will create XI message with additional dynamic headers for each chunk and forwarded to Messaging System for IRD processing.
For this example, chunk size is configured as 2 MB and the below input file (~4.5 MB) is used.
For demo purpose and to identify/analyze how the actual split happens, the input file is created with the data like below ( 1 to 600000)
As per the configuration, three chunks should be created with the size of 2 MB, 2MB and ~500 KB.
Transferring first 2 MB
Transferring next 2 MB (Total 4 MB)
Transferring the remaining ~500 KB (Total ~4.5 MB)
The entire chunk mode related dynamic headers will be set under the namespace http://sap.com/xi/XI/System/Generic
Header | Value |
ChunkStart | Start of the Chunk (Position of bytes) |
ChunkMode | Active/End |
ChunkKey | Unique Key (Same for all the chunks for a particular file) |
The corresponding screenshots for all 3 chunks are given below.
If multiple files sent from different file sender channels, receiver adapter uses the chunk key to identify the proper output file(for combining). During the creation(and append) of output file, it uses the chunk key like below.
In Temp mode, the temp files won’t be deleted till the last chunk is received.
If the input file is very large, it would normally take more time to be transferred completely. If there is any server failure in the middle, the transfer can resumed from the chunk it stopped (Not from the beginning)
Though this feature operates only on binary mode, text file is used to analyze how the split happens during chunk creation.
As per the above screenshots, the split never cosiders the payload. It's just a binary split. So the following limitations would apply
Technically, other type of receiver adapters can be used. But it won't have the option to combine the chunks.
No. File receiver will automatically identify & combine the chunks using dynamic headers.
Yes. But significantly affects the performance. Smaller chunk size creates more chunks (more XI messages)
If chunks are stuck in the EOIO queue, it can be monitored with
http://host:port/MessagingSystem/monitor/sequenceMonitor.jsp
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
10 | |
7 | |
7 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 |