Problem statement : Files will arrive all through the day to an PI source directory. Once during end of the day PI needs to zip the files and send it to target locations. The files which arrive in PI might come with multiple file extensions or names. The files might arrive any time all throughout the day. The target server expects file name of the zip file produced in a specific format.
Scenario design: Divide the scenario in two integrated configurations (ICO). The first ICO will read the files and write them to a target directory (TEMP). The first ICO will also generate a blank file (start.txt). This blank file called start.txt will stay in a different TEMP1 directory . This file start.txt acts a signal to start the zipping process. The zipping process is carried on by second ICO. The second ICO looks if any "start.txt" blank file is present in TEMP1 directory. If such a file exists then sender channel of second ICO picks up start.txt from TEMP1 directory. A custom module in second ICO then starts reading all the files from TEMP directory. These files are the ones which needs to be zipped. The second ICO reads the files and zips all of them to produce a single file with ".zip". The files which were zipped are archived reading them by sender channel of second ICO. Thus after zipping is over the TEMP directory will contain only the zip file because all other files are now lying withing the zip file itself. This zip file is moved to TEMP1 directory and the file start.txt is deleted.
From TEMP1 directory this zip file is read by the second ICO during polling again and written to target folder as specified in receiver channel. The second ICO reads the start.txt file and the zip file both. However while writing to target server only the zip file is written and start.txt gets deleted. This entire scenario involves no ESR objects hence had to create custom adapter modules one for each scenario to design the scenario. The sender channels of both the ICO's needs to be scheduled using availability time planning This is important because only one of the channels can be polling at a time but not both. This is to ensure while second ICO is doing the zipping, the first ICO should not keep sending files in the TEMP directory.
Implementation:
First ICO
Sender channel of ICO1. This channel picks up all files to be zipped.
Custom adapter module applied in sender communication channel with following details
The module parameters are explained below
Provide receiver as business component , the same business component will feature in second ICO2.
Provide name of the receiver channel in first ICO.
In the target directory provide name of a temporary folder where files will get deposited for zipping through out the day. This directory is different from source directory of the second ICO. the source directory of the second ICO has been mentioned in module parameter shown above.
Define Adapter-Specific Message Attributes in both sender and receiver channel of ICO1.
Select the Advanced tab page.To save adapter attributes in the message header of the XI message, select Set Adapter-Specific Message Attributes.To apply the following attributes in the XI message header, tick on the corresponding indicators:File Name (technical name: FileName). This setting has to be applied on both sender and receiver communication channels of ICO1.
This ends the creation of first ICO configuration.
Second Integrated Configuration design (ICO2)
-------------------------
Overall design of ICO2 is shown below. I have intentionally erased certain names as part of nondisclosure agreement.
Now let us see the sender communication channel parameters of ICO2.
This is the channel which holds the module to zip the files which are kept in target directory mentioned in receiver channel of ICO1 (explained earlier).
Process all empty files for empty file handling options.
Set the Adapter specific message attributes for filename and directory as shown below
The sender channel of ICO2 plays vital role in zipping the files. This channel picks up only the blank file start.txt created by ICO1 and the zip files present in the source directory. The zipping of files present in target folder pointed out by receiver channel of ICO1 is done by custom adpater module present in the sender channel of ICO2. Details of the module and its parameters is shown below
Parameters used in module used for zipping the files are shown below
The parameters have been explained below
The parameters marked as optional may not be mentioned at all. The zip file produced will have a sample name as shown INFO_PRICE_LIST.D190608.T095033.zip. Without use of optional parameters the filename will be INFO_PRICE_LIST.zip.
Let us try to understand rest of set up of ICO2.
The receiver communication channel setting for ICO2 will be as shown below for vital parameters
The ASMA parameter for file name should be ticked on for both sender and receiver channels.
The target directory of the receiver adapter will be the final directory where zipped files will arrive at end of day each day. Use availability time planning for sender communication channels of ICO1 and ICO2. Only one of the two sender channels will be open at a time. In my case for ICO1 the sender channel was open between time 12:15 AM - 11:59 PM. For ICO2 the availability time planning is from 12:00 AM- 12:14 AM. This ICO1 picks up files through entire day whilst ICO2 will zip files only for 15 minutes. Ensure polling interval for sender channel in second ICO will be equal to 4 minutes. This completes the configuration of the scenario.
Let us check the results
All files have arrived in target directory of ICO1 as shown below
The first module in ICO1 has created a blank file start.txt in source folder of sender channel being used in ICO2.
Now the sender channel of ICO2 picks up this start.txt file and trigger the module to zip all files. Finally after the module works you get the zip file in the target directory of receiver channel of ICO2.
The ear files provided in the link above needs to be deployed in PI/PO server either through NWDS or with help of BASIS team.
The various logs will be available in message monitoring as shown below when files will be zipped.
The final zip file can be found in target directory pointed out by receiver file channel in ICO2.
Scenario design: Divide the scenario in two integrated configurations (ICO). The first ICO will read the files and write them to a target directory (TEMP). The first ICO will also generate a blank file (start.txt). This blank file called start.txt will stay in a different TEMP1 directory . This file start.txt acts a signal to start the zipping process. The zipping process is carried on by second ICO. The second ICO looks if any "start.txt" blank file is present in TEMP1 directory. If such a file exists then sender channel of second ICO picks up start.txt from TEMP1 directory. A custom module in second ICO then starts reading all the files from TEMP directory. These files are the ones which needs to be zipped. The second ICO reads the files and zips all of them to produce a single file with ".zip". The files which were zipped are archived reading them by sender channel of second ICO. Thus after zipping is over the TEMP directory will contain only the zip file because all other files are now lying withing the zip file itself. This zip file is moved to TEMP1 directory and the file start.txt is deleted.
From TEMP1 directory this zip file is read by the second ICO during polling again and written to target folder as specified in receiver channel. The second ICO reads the start.txt file and the zip file both. However while writing to target server only the zip file is written and start.txt gets deleted. This entire scenario involves no ESR objects hence had to create custom adapter modules one for each scenario to design the scenario. The sender channels of both the ICO's needs to be scheduled using availability time planning This is important because only one of the channels can be polling at a time but not both. This is to ensure while second ICO is doing the zipping, the first ICO should not keep sending files in the TEMP directory.
Implementation:
First ICO
Sender channel of ICO1. This channel picks up all files to be zipped.
Custom adapter module applied in sender communication channel with following details
The module parameters are explained below
Provide receiver as business component , the same business component will feature in second ICO2.
Provide name of the receiver channel in first ICO.
In the target directory provide name of a temporary folder where files will get deposited for zipping through out the day. This directory is different from source directory of the second ICO. the source directory of the second ICO has been mentioned in module parameter shown above.
Define Adapter-Specific Message Attributes in both sender and receiver channel of ICO1.
Select the Advanced tab page.To save adapter attributes in the message header of the XI message, select Set Adapter-Specific Message Attributes.To apply the following attributes in the XI message header, tick on the corresponding indicators:File Name (technical name: FileName). This setting has to be applied on both sender and receiver communication channels of ICO1.
This ends the creation of first ICO configuration.
Second Integrated Configuration design (ICO2)
-------------------------
Overall design of ICO2 is shown below. I have intentionally erased certain names as part of nondisclosure agreement.
Now let us see the sender communication channel parameters of ICO2.
This is the channel which holds the module to zip the files which are kept in target directory mentioned in receiver channel of ICO1 (explained earlier).
Process all empty files for empty file handling options.
Set the Adapter specific message attributes for filename and directory as shown below
The sender channel of ICO2 plays vital role in zipping the files. This channel picks up only the blank file start.txt created by ICO1 and the zip files present in the source directory. The zipping of files present in target folder pointed out by receiver channel of ICO1 is done by custom adpater module present in the sender channel of ICO2. Details of the module and its parameters is shown below
Parameters used in module used for zipping the files are shown below
The parameters have been explained below
The parameters marked as optional may not be mentioned at all. The zip file produced will have a sample name as shown INFO_PRICE_LIST.D190608.T095033.zip. Without use of optional parameters the filename will be INFO_PRICE_LIST.zip.
Let us try to understand rest of set up of ICO2.
The receiver communication channel setting for ICO2 will be as shown below for vital parameters
The ASMA parameter for file name should be ticked on for both sender and receiver channels.
The target directory of the receiver adapter will be the final directory where zipped files will arrive at end of day each day. Use availability time planning for sender communication channels of ICO1 and ICO2. Only one of the two sender channels will be open at a time. In my case for ICO1 the sender channel was open between time 12:15 AM - 11:59 PM. For ICO2 the availability time planning is from 12:00 AM- 12:14 AM. This ICO1 picks up files through entire day whilst ICO2 will zip files only for 15 minutes. Ensure polling interval for sender channel in second ICO will be equal to 4 minutes. This completes the configuration of the scenario.
Let us check the results
All files have arrived in target directory of ICO1 as shown below
The first module in ICO1 has created a blank file start.txt in source folder of sender channel being used in ICO2.
Now the sender channel of ICO2 picks up this start.txt file and trigger the module to zip all files. Finally after the module works you get the zip file in the target directory of receiver channel of ICO2.
The enterprise application archive (*.ear) files for the zip module are provided in this link.
The ear files provided in the link above needs to be deployed in PI/PO server either through NWDS or with help of BASIS team.
The various logs will be available in message monitoring as shown below when files will be zipped.
The final zip file can be found in target directory pointed out by receiver file channel in ICO2.
Variations of the Scenario
- If each of the files are to be zipped then use standard module provided by SAP. Details on using this standard module can be seen in this wonderful blog.
- If the file are needed to be zipped multiple times in a day set the polling interval of ICO2 accordingly and apply availability time planning in both channels.
- In the case that files with different extensions are to be zipped in separate files then the first ICO needs little modification. In case for example all PDF files be zipped together, all exel files be zipped together , all text files be zipped together likewise. Then the number of target directories in ICO1 must be increased as the number of different file extensions possible. Thus ICO1 will have n receiver channels (n>1). Depending on filename the target receiver or the the target directory name will be decided using context object called "FileName". For each channel separate receiver business component will be necessary.
- SAP Managed Tags:
8 Comments
