This blog describes the options for message zipping and compressing of messages in Cloud Integration. It explains the different flow steps and the respective configuration options.
In some integration scenarios messages have to be exchanged in a zipped and/or compressed format. Cloud Integration offers different flow steps for different use cases.
The ZIP Encoder can be used to zip a single message during integration flow processing.
The ZIP Encoder can be found in the palette under Message Transformers -> Encoders -> ZIP Compression. This flow step has no further configuration parameters, it simply zips a message into a zip archive.
The GZIP Encoder can be used to compress a single message with the gzip algorithm during integration flow processing.
The GZIP Encoder can be found in the palette under Message Transformers -> Encoders -> GZIP Compression. This flow step has no further configuration parameters, it simply compresses a message.
The ZIP Decoder can be used to un-zip a single message from a zip archive during integration flow processing. Only one message may be contained in the archive, or else an error will be raised.
The ZIP Decoder can be found in the palette under Message Transformers -> Decoders -> ZIP Decompression. This flow step has no further configuration parameters, it simply un-zips a message from a zip message archive.
The GZIP Decoder can be used to un-compress a single gzip-compressed message during integration flow processing.
The GZIP Decoder can be found in the palette under Message Transformers -> Decoders -> GZIP Decompression. This flow step has no further configuration parameters, it simply un-compresses a message.
The ZIP Splitter can be used to un-zip a zip archive containing multiple files. It splits them into single messages and processes them one after the other.
The ZIP Splitter can be found in the palette under Routing -> Splitter -> Zip Splitter. This flow step has two configuration parameters:
Using the File Name Pattern field, you can define a pattern for the files from the zip archive, which have to be processed. If you, for example, want to process only xml files from the archive and ignore the others, you can define *.xml. If no information is given in this field all files from the archive are processed.
Expressions such as ab*, a.*, *a*, ?b, and so on, are supported. Note that the expression * replaces no character or an arbitrary number of characters. The expression ? replaces exactly one arbitrary character.
Examples:
By using the Stop on Exception field, you can define if the split process shall stop if there has been an error during the processing of one of the split messages or if the split process shall continue to process the next file from the archive.
The ZIP Aggregate or ZIP Gather can be used to zip several messages coming from different branches or splits into a zip archive.
The ZIP Gather can be found in the palette under Routing -> Gather. In the Gather step you can select Zip as Aggregation Algorithm. This Aggregation Algorithm can be used for all Incoming Formats. The flow step has one configuration parameter:
In the File Name field you can enter a simple expression to create the file name for the files in the archive. For example, with ${header.id}.xml you can create the files with different names based on the header id. The header has to be set before the gather step. You need to make sure that the file name is unique within the archive, or else there will be an error during processing because multiple files cannot have the same name within a zip archive. If nothing is defined in the field, the header CamelFileName is evaluated. In case neither an expression nor the CamelFileName header is specified during runtime a unique file name is generated.
The TAR Splitter can be used to un-tar a tar archive containing multiple files. It splits them into single messages and processes them one after the other.
The TAR Splitter can be found in the palette under Routing -> Splitter -> Tar Splitter. This flow step has two configuration parameters:
Using the File Name Pattern field, you can define a pattern for the files from the tar archive, which have to be processed. If you, for example, want to process only xml files from the archive and ignore the others, you can define *.xml. If no information is given in this field all files from the archive are processed.
Expressions such as ab*, a.*, *a*, ?b, and so on, are supported. Note that the expression * replaces no character or an arbitrary number of characters. The expression ? replaces exactly one arbitrary character.
Examples:
By using the Stop on Exception field, you can define if the split process shall stop if there has been an error during the processing of one of the split messages or if the split process shall continue to process the next file from the archive.
The TAR Aggregate or TAR Gather can be used to combine several messages coming from different branches or splits into a tar archive.
The TAR Gather can be found in the palette under Routing -> Gather. In the Gather step you can select Tar as Aggregation Algorithm. This Aggregation Algorithm can be used for all Incoming Formats. The flow step has one configuration parameter:
In the File Name field you can enter a simple expression to create the file name for the files in the archive. For example, with ${header.id}.xml you can create the files with different names based on the header id. The header has to be set before the gather step. You need to make sure that the file name is unique within the archive, or else there will be an error during processing because multiple files cannot have the same name within a zip archive. If nothing is defined in the field, the header CamelFileName is evaluated. In case neither an expression nor the CamelFileName header is specified during runtime a unique file name is generated.
ZIP and Compress Capabilities in Cloud Integration
In some integration scenarios messages have to be exchanged in a zipped and/or compressed format. Cloud Integration offers different flow steps for different use cases.
ZIP Encoder
The ZIP Encoder can be used to zip a single message during integration flow processing.
The ZIP Encoder can be found in the palette under Message Transformers -> Encoders -> ZIP Compression. This flow step has no further configuration parameters, it simply zips a message into a zip archive.
GZIP Encoder
The GZIP Encoder can be used to compress a single message with the gzip algorithm during integration flow processing.
The GZIP Encoder can be found in the palette under Message Transformers -> Encoders -> GZIP Compression. This flow step has no further configuration parameters, it simply compresses a message.
ZIP Decoder
The ZIP Decoder can be used to un-zip a single message from a zip archive during integration flow processing. Only one message may be contained in the archive, or else an error will be raised.
The ZIP Decoder can be found in the palette under Message Transformers -> Decoders -> ZIP Decompression. This flow step has no further configuration parameters, it simply un-zips a message from a zip message archive.
GZIP Decoder
The GZIP Decoder can be used to un-compress a single gzip-compressed message during integration flow processing.
The GZIP Decoder can be found in the palette under Message Transformers -> Decoders -> GZIP Decompression. This flow step has no further configuration parameters, it simply un-compresses a message.
ZIP Splitter (available with the update in May 2020)
The ZIP Splitter can be used to un-zip a zip archive containing multiple files. It splits them into single messages and processes them one after the other.
The ZIP Splitter can be found in the palette under Routing -> Splitter -> Zip Splitter. This flow step has two configuration parameters:
Using the File Name Pattern field, you can define a pattern for the files from the zip archive, which have to be processed. If you, for example, want to process only xml files from the archive and ignore the others, you can define *.xml. If no information is given in this field all files from the archive are processed.
Expressions such as ab*, a.*, *a*, ?b, and so on, are supported. Note that the expression * replaces no character or an arbitrary number of characters. The expression ? replaces exactly one arbitrary character.
Examples:
- If you specify file*.txt as the File Name Pattern, the following files are processed: file1.txt, file2.txt, as well as file.txt and file1234.txt, and so on.
- If you specify file?.txt as the File Name Pattern, the following files are processed: file1.txt, file2.txt, and so on, but not the files file.txt or file1234.txt.
By using the Stop on Exception field, you can define if the split process shall stop if there has been an error during the processing of one of the split messages or if the split process shall continue to process the next file from the archive.
ZIP Aggregate (available with the update in May 2020)
The ZIP Aggregate or ZIP Gather can be used to zip several messages coming from different branches or splits into a zip archive.
The ZIP Gather can be found in the palette under Routing -> Gather. In the Gather step you can select Zip as Aggregation Algorithm. This Aggregation Algorithm can be used for all Incoming Formats. The flow step has one configuration parameter:
In the File Name field you can enter a simple expression to create the file name for the files in the archive. For example, with ${header.id}.xml you can create the files with different names based on the header id. The header has to be set before the gather step. You need to make sure that the file name is unique within the archive, or else there will be an error during processing because multiple files cannot have the same name within a zip archive. If nothing is defined in the field, the header CamelFileName is evaluated. In case neither an expression nor the CamelFileName header is specified during runtime a unique file name is generated.
TAR Splitter (will be available with the update in June 2020)
The TAR Splitter can be used to un-tar a tar archive containing multiple files. It splits them into single messages and processes them one after the other.
The TAR Splitter can be found in the palette under Routing -> Splitter -> Tar Splitter. This flow step has two configuration parameters:
Using the File Name Pattern field, you can define a pattern for the files from the tar archive, which have to be processed. If you, for example, want to process only xml files from the archive and ignore the others, you can define *.xml. If no information is given in this field all files from the archive are processed.
Expressions such as ab*, a.*, *a*, ?b, and so on, are supported. Note that the expression * replaces no character or an arbitrary number of characters. The expression ? replaces exactly one arbitrary character.
Examples:
- If you specify file*.txt as the File Name Pattern, the following files are processed: file1.txt, file2.txt, as well as file.txt and file1234.txt, and so on.
- If you specify file?.txt as the File Name Pattern, the following files are processed: file1.txt, file2.txt, and so on, but not the files file.txt or file1234.txt.
By using the Stop on Exception field, you can define if the split process shall stop if there has been an error during the processing of one of the split messages or if the split process shall continue to process the next file from the archive.
TAR Aggregate (will be available with the update in June 2020)
The TAR Aggregate or TAR Gather can be used to combine several messages coming from different branches or splits into a tar archive.
The TAR Gather can be found in the palette under Routing -> Gather. In the Gather step you can select Tar as Aggregation Algorithm. This Aggregation Algorithm can be used for all Incoming Formats. The flow step has one configuration parameter:
In the File Name field you can enter a simple expression to create the file name for the files in the archive. For example, with ${header.id}.xml you can create the files with different names based on the header id. The header has to be set before the gather step. You need to make sure that the file name is unique within the archive, or else there will be an error during processing because multiple files cannot have the same name within a zip archive. If nothing is defined in the field, the header CamelFileName is evaluated. In case neither an expression nor the CamelFileName header is specified during runtime a unique file name is generated.
- SAP Managed Tags:
19 Comments
