UnzipSplitterBean – Split zip entries into child messages
Introduction
When working with compressed ZIP files, the standard PayloadZipBean module can be configured in a communication channel to extract the entries from compressed files. However, the functionality of the module is limited whereby the main payload will be replaced by the first entry of the compressed file, while the other entries will be added as attachments to the same message.
Sometimes, the entries in the compressed file need to be further processed, and if they are of the same format, the same processing needs to be applied on each of the entries. This will necessitate custom Java development to access the attachments and apply transformation for each of the attachments.
UnzipSplitterBean aims to fill this gap by combining the logic in Java Mapping: Unzip file and create additional attachments and AttachmentSplitterBean – Split attachments into child messages. It allows for the extraction of the zip entries into separate child messages, thereby allowing the usual processing via graphical mapping instead of requiring custom Java to access the attachments.
Source Code and Deployment Archive
UnzipSplitterBean belongs in the same adapter module project as FormatConversionBean. Refer to following blog for the location of source code and/or EAR deployment file.
FormatConversionBean – One Bean to rule them all!
Module Parameter Reference
The JNDI name for the module is listed below for adding the module to the processing chain of a communication channel.
Module name = Custom_AF_Modules/UnzipSplitterBean
Below is a list of the parameters for configuration of the module. Certain parameters will automatically inherit the default values if it is not configured.
| Parameter Name | Allowed Values | Default Value | Remarks |
|---|---|---|---|
| reuse |
Y, N |
Y |
|
| mimeType | Valid MIME types | application/xml | Sets the MIME type used as the prefix of the content type of the child messages |
| fileNameAttr | FileName | Dynamic Configuration attribute used to store zip entry’s file name in child message | |
| fileNameNS | http://sap.com/xi/XI/System/File | Dynamic Configuration namespace used to store zip entry’s file name in child message | |
| mode |
binding, channel |
Required field when reuse = ‘N’. Determines which channel the child messages should be sent to
|
|
| adapterType | Valid adapter types in the PI system |
Required field when reuse = ‘N’ and mode = ‘binding’. Adapter type for the channel where the child messages will be sent to |
|
| adapterNS |
Required field when reuse = ‘N’ and mode = ‘binding’. Adapter namespace for the channel where the child messages will be sent to |
||
| fromParty |
Available when reuse = ‘N’ and mode = ‘binding’. Sender Party of sender agreement where the child messages will be sent to |
||
| fromService |
Required field when reuse = ‘N’ and mode = ‘binding’. Sender Service of sender agreement where the child messages will be sent to |
||
| toParty |
Available when reuse = ‘N’ and mode = ‘binding’. Receiver Party of sender agreement where the child messages will be sent to |
||
| toService |
Available when reuse = ‘N’ and mode = ‘binding’. Receiver Service of sender agreement where the child messages will be sent to |
||
| interfaceName |
Required field when reuse = ‘N’ and mode = ‘binding’. Sender interface name of sender agreement where the child messages will be sent to |
||
| interfaceNamespace |
Required field when reuse = ‘N’ and mode = ‘binding’. Sender interface namespace of sender agreement where the child messages will be sent to |
||
| channelID |
Required field when reuse = ‘N’ and mode = ‘channel’. Object ID of the channel where the child messages will be sent to |
||
| messageLog |
pre, post |
Saves a log version of the message that is viewable in Message Monitor
|
|
| logLocation | Name of log version when messageLog is populated. Location defaulted to value in messageLog if logLocation not populated |
Example Scenarios
Scenario 1
Sender SFTP channel will pick up zip file and split the entries into separate messages. Default setting used for the module so same scenario will be reused for the child messages. The unzipped content will be delivered to an SFTP folder without further transformation.
Design
Configuration
The sender channel will pick up all files ending with .zip extension.
The module is configured with no additional parameters.
Testing
The following compressed file with 3 entries will be used for testing.
From the audit log, the module extracts the 3 entries, the first one will replace the main payload, while the other two will be dispatched as child messages to the same sender channel.
The main payload is replaced by the first entry of the compressed file.
In the audit log of the child message, processing by the module is skipped as the child message is already decompressed.
Following is the payload for the child messages.
And finally, all the messages are delivered to the target folder.
Scenario 2
The above scenario is enhanced so that the child messages are extracted and routed to a different scenario. The original compressed file will be delivered to the target folder unchanged.
Design
In addition to the iFlow in the above scenario, an additional iFlow is configured for routing the child messages to the target SFTP folder. The sender channel will be a SOAP sender.
Configuration
The module configuration in the original SFTP channel (of iFlow 1) is configured as follows, so that the child messages are routed to the second iFlow. The header details (sender system/party, namespace and adapter type) should match the sender of the second iFlow above.
Testing
From the results of the testing, there will be 1 message for the first iFlow and 3 child messages for the second iFlow.
From the audit log, it is observed that all the zip entries are dispatched as child messages.
And finally, the original compressed file and the zip entries are delivered to the target folder.
Conclusion
As shown by the example scenarios above, processing of entries within a compressed file can be simplified with the use of UnzipSplitterBean. Although the examples show simplified passthrough processing of the child messages, these can be further enhance like any typical scenario, i.e. additional modules (FCC), graphical mapping, etc. It is much simpler to handle the entries as messages instead of attachments of a parent message.
Eng Swee your blogs are always very helpful and life saver.
As usual this is very nice and helpful blog as we have many requirement where we have to work with the zip and this will really help as the standard module doesn't have many functionality and is very limited.
Hi Asif
Thank you for your kind words. It's always a pleasure to know that the solutions provided have been beneficial to others in the community 😉
Best regards
Eng Swee
Hi,
what kind of zip files are possible? Only zip or also gzip?
Kind regards,
Thorsten
Hi Thorsten
Only Zip as a start. Shouldn't be too difficult to add support for Gzip. Will update this post when that is added.
Thanks for the feedback.
Regards
Eng Swee
Wait a sec! The idea of the module is to extract Zip files that contain multiple entries. GZip only supports compression of a single file.
Hi Eng,
when i’m using Custom_AF_Modules/UnzipSplitterBean in sender communication channel. i have error in  Communication Channel Monitoring:
 do i have do anything other configuring?
Thanks!
Hi Eng Swee Yeoh ,
Will it work for two level compressed file(.tar–>.gz–>.txt) where I have to read .txt files for further process
Please suggest for this requirement.
Regards
Umesh