Background
I had a requirement recently which dealt with incoming Zip files. Basically, there are a few files in the Zip file and each of them will be used differently in subsequent processing, i.e. fileA will be processed by interface A, fileB by interface B. In order to achieve this, it is important to preserve the filename for each file in the Zip file. Additionally, a copy of original Zip file needs to be saved in the target directory too.
This requirement could not be achieved by using the standard module PayloadZipBean because:
- The main payload is replaced with the contents of the first file in the Zip file
- The filename of the first file that replaces the main payload is no longer available
In this article, I will share the custom Java mapping that was developed to fulfill this requirement. The core logic is to:
- Unzip main payload and create additional attachments for each file in Zip file
- Retain filename of each file
Source code
Below is a snippet of the portion of the code which deals with the unzipping and attachment creation.
ZipInputStream is used to read the compressed data. The logic loops through getting each ZipEntry to retrieve the content of each file. The filename is retrieved and used to create the additional attachment for the message.
// Unzip input file ZipInputStream zis = new ZipInputStream(new ByteArrayInputStream(content)); ZipEntry ze = null; // Loop through all entries in the zip file while((ze = zis.getNextEntry()) != null) { byte[] zipContent = getInputStreamBytes(zis); // Create attachment String name = ze.getName(); String ctype = "text/plain;name=\"" + name +"\""; if (outAtt != null) { Attachment att = outAtt.create(name, ctype, zipContent); outAtt.setAttachment(att); } zis.closeEntry(); } zis.close();The full source code can be found in the following public repository on GitHub:
GitHub repository for PI_JavaMapping_UnzipAttach
Additionally,the JAR file is also available for direct download from GitHub:
com.equalize.xpi.esr.mapping.unzip.jar
Testing
Below are some screenshots of a test run using the Java mapping.
Firstly, we have a Zip file in the source folder. This Zip file contains two files within it.
From the message log, we can see that the original payload (logged with MessageLoggerBean) does not contain any attachments.
After the mapping step (AM) is performed, there is now two additional attachments in the message.
The message is then delivered to an SFTP receiver channel (with Store Attachments checked.) The channel processes all three files - main payload and 2 attachments.
Finally, we can see the 3 files in the target folder. The name of the first file is retained as is, while the two attachments have filenames which are concatenation of the main payload filename and the attachment name, i.e. <main_filename>_<attachment_name>
Reference
For further reference on dealing with Zip files, the following article covers the reverse flow - incoming payload with multiple attachments are compressed into a single Zip outgoing payload