Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata
 
 

Dynamic file name and directory in Receiver File Adapter - summary of possibilities

Link to Content's target Space :

SAP PI/XI Guidelines and Best Practices

Applies to:

SAP Process Integration (screenshots and code examples come from SAP PI 7.1)

Summary

A summary of PI's capabilities to dynamically set the file name and file directory in a Receiver File scenario. Consider this as a reference to get familiar with the options available and their strenghts and weaknesses.

Author(s):  

   
Company:     Business Consulting Center
Created on:    2012-02-28
Author(s) Bio

Grzegorz Głowacki is a Senior SAP XI/PI & Systems Integration Consultant at BCC. Experienced with SAP since 2008. Participated in numerous differentiated SAP projects of various complexity, in several countries. Specialties: SAP PI/XI (Process Integration / Exchange Infrastructure), ALE, EDI, IDOC, ABAP programming, SAP Business Connector.

Table of Contents

Introduction

So many times I felt like I was between a rock and a hard place, when developing an integration scenario. The reason was that I have found a BAPI that perfectly matched my requirements, but did not want to go for a BAPI-RFC scenario, because of no monitoring available in the backend system. And on the other hand, I would be glad to stay with pure SAP standard functionality, for support reasons. Moreover, I found out in SDN Forums that I was not the only one to face this dilemma.

But I am happy to announce to all of you that there is a way to have your cake and eat the cake. You can stay with SAP standard AND enable monitoring at the same time, for standard BAPI scenarios. I would even say more: there are two ways to achieve this, both having some strong and weak sides, and it is up to you to decide which one matches your requirements better.
Many questions arise in the SDN Forum about how to dynamically generate the file name or target directory in the Receiver File Adapter, for some particular requirements. For this reason, I have decided to provide a summary of available options, with some configuration guidelines and a list of pros and cons for each option. The options available are as follows, in the order of preference (with a recommendation to use the upper-most one on the list that matches your requirements):

  1. File Construction Mode in Communication Channel parameters,
  2. Variable Substitution,
  3. Adapter-Specific Message Attributes (and Dynamic Configuration),
  4. Running OS command after message processing.

File Construction Mode

This is by far the simplest solution, and it can only match the simplest requirements. You can find the respective option in the Processing tab page of your receiver file Communication Channel. You have the following options for File Construction Mode: Create, Append, Add Time Stamp, Add Message ID, and Add Counter (only for NFS Transport Protocol). The last three of them lead to the file name being generated dynamically.  As of SAP Help description, this was originally designed to guarantee that no file is overwritten, but you could possibly also use it for some business requirements. However, you cannot influence the way the dynamic part of the file name is generated. Following rules apply:

Add Time Stamp: the time stamp is added as the last part of the name, directly before the extension, and it is always formatted yyyyMMdd-HHmmss-SSS.

Add Message ID: PI’s message ID is added to the file name, formatted as xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Add Counter: a consecutive number is added to the file name, directly before the extension. This is only possible with the NFS Transport Protocol. Refer here for configuration details: http://help.sap.com/saphelp_nwpi71/helpdata/en/44/6830e67f2a6d12e10000000a1553f6/content.htm

Example filenames:
xi_output_20120213-180304-425.xml (with xi_output_.xml and Add Time Stamp)
xi_output_005056a4-7bae-1ee1-95df-3964c12edd64.xml (with xi_output_.xml and Add Message ID)
xi_output_0002.xml (xi_output_.xml and Add Counter) 

Pros and cons:
+ The easiest implementation of all possible options,
- Limited options to influence the file name,
- No flexibility.

Variable Substitution

This is another capability of the receiver file Communication Channel that you might use to influence the file name or path under which the file is generated. The idea is simple here: in the Variable Substitution on the  Advanced tab page, you define some variables that you later use in Target Directory or File Name Scheme on the Target tab page. There are two types of variables you can define: connected to message header attributes, and payload-based. In header attributes, you can for instance get access to the sender & receiver service, interface name or message ID. On the other hand, the payload-based variables let you get access to the contents of the message that is delivered to the receiver, with some kind of a query that you define in the variable definition. This gives you quite a lot of possiblities to create the file name that you need.

For example, let us assume that you need to use the customer number as a file name part for a customer master data scenario, and the name of the interface as the directory (to match the company's general naming convention policy). You could use the following configuration to dynamically set target directory and file name:


In my case, the result full file path was:

directory\SI_Customer\xi_output_1234.xml

If you require further guidelines on how to define and configure variables, refer to this help document: http://help.sap.com/saphelp_nwpi71/helpdata/en/44/6a316af5a23672e10000000a114a6b/content.htm

Make sure to use lowercase variable names, otherwise they might not work as you expect!

Pros and cons:
+ Simple enough in implementation,
+ Greater possibilities, compared with File Construction Mode,
+ Possible to use message payload to generate file name and path,
- Still far from freely defining the file name and directory (for instance, no way to define conditions),
- For payload-based variables, no conversions are possible (values can only be used exactly the way they appear in outbound message payload).

Adapter-Specific Message Attributes and Dynamic Configuration

Finally there is the most powerful tool for dynamically generating the file name or directory. The main principle here is that you can declare the file name and directory during Message Mapping, so you can create most sophisticated file name schemes. Let us assume that the requirement is similar to option #2 example, but a whole number with leading zeros is required, although the zeros are removed in the mapping to target format. There are two configuration steps to be performed: design part in the Enterprise Services Repository, and configuration part in Integration Directory.

Design part
In your message mapping, you will need a simple UDF, let us name it setFileName. In my case, it had the Execution Type "Single Values", one input parameter variablePart of type string, and the following content:
Finally there is the most powerful tool for dynamically generating the file name or directory. The main principle here is that you can declare the file name and directory during Message Mapping, so you can create most sophisticated file name schemes. Let us assume that the requirement is similar to option #2 example, but a whole number with leading zeros is required, although the zeros are removed in the mapping to target format. There are two configuration steps to be performed: design part in the Enterprise Services Repository, and configuration part in Integration Directory.

Design part

In your message mapping, you will need a simple UDF, let us name it setFileName. In my case, it had the Execution Type "Single Values", one input parameter variablePart of type string, and the following content:

String filename = new String("");
DynamicConfiguration conf1 = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
DynamicConfigurationKey key1 = DynamicConfigurationKey.create("http:/"+"/sap.com/xi/XI/System/File","FileName");
filename = "xi_output_" + variablePart + ".xml";
conf1.put(key1,filename);
return variablePart;

Now you just use this function in your message mapping, passing the desired value as an input parameter:

Configuration part

In addition to setting the Dynamic Configuration key in the Message Mapping, you also need to make PI use the dynamically configured value as the file name. For this purpose, find your receiver file Communication Channel in Integration Directory, go to the Advanced tab page and mark the "Use Adapter-Specific Message Attributes", as well as "File Name" checkboxes. You might also want to mark "Directory" or "Fail If Adapter-Specific Message Attributes Missing" if relevant.


The result file name is: directory\ xi_output_0000001234.xml, which was exactly the requirement.
Pros and cons:
+ Using graphical mapping functions and Java code, you can define the file name absolutely freely,
+ You can use this option in parallel with option #1 if required,
- ESR objects are required (no way to use this option in case of scenarios including Integration Directory objects only).

Run Operating System Command After Message Processing

The last approach for changing the file name is using the operating system command after message processing to change the temporary file name set by PI. You can additionally use OS Environment Variables to build the file name. Processing with OS command is a powerful tool and is underestimated sometimes, but still it should be used wisely and only if other options are not possible for some reason (too limited possibilities of the first two options above and no ESR objects for ASMA, for instance). 

As an example, you could use the following OS Command to rename the file to some random number (between 0 and 32767):


You can find more Environment Variables in Windows OS here: http://vlaurie.com/computers2/Articles/environment.htm

Pros and cons:
+ Lots of flexibility and possibilities,
+ Can be used in configuration-only scenarios (no ESR objects required),
- The exact OS command syntax is operating system-dependent,
- Only possible with NFS Transport Protocol that way,
- Processing the OS command never fails a message, even if the OS command execution was not successful, which might lead to inconsistencies.

Related Content

Find some interesting related content under the following links:

http://wiki.sdn.sap.com/wiki/display/XI/Sample+Code+-+Dynamic+Configuration+in+Java+and+ABAP+Mapping

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/4645  - blog by Michal Krawczyk
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13704- blog by Shabarish Vijaykumar
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3507  -  blog by William Li
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/18151- blog by Praveen Gujjeti
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/24056- blog by Venkata Ramesh Boppana
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/4623  - blog by Daniel Graversen

5 Comments

  1. Thank you for your blog! It was very helpfull!

    Please add to your blog post that the variable name for "Variable Substitution" needs to be in lowercase. Because it won't work if you have characters in uppercase.

     

    BR

    1. Thanks Carlos. I mentioned this lowercase requirement in the respective chapter.

      Regards, Greg

  2. Former Member

    Thank you for explaining all possible ways of creating file name dynamically.

    I would like to add 1 point to it. ASMA ( Adapter Specific Message Attributes) can be used even in case of scenarios using only Integration Directory (ID) objects. For example: In case of File-to-File bypass scenarios involving only ID objects, if we need to create file with the same name as it is coming with, we can do it simply by checking ASMA parameters on both sender and receiver channels.

    Regards,

    Mohit

  3. Thanks for sharing!

  4. Former Member

    Thanks a lot !!