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	Y = Indicates that the same scenario will be used for the child messages. Therefore the main payload will be replaced by the first entry from the compressed file N = Indicates that the child messages will be routed to a different binding of another scenario
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 binding = Channel is determined via lookup of matching sender agreement based on child message header details channel = Channel is determined from Object ID of channel (found under Object Properties of Comm Channel in Swing version of Integration Directory). The child message header details are determined from corresponding binding of the channel. When using this mode, ensure that the comm channel is only used in a single sender agreement/ICO/iFlow
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 pre = logs main message before splitting post = logs main message after splitting
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.