cancel
Showing results for 
Search instead for 
Did you mean: 

File sender adapter (FTP) -> processing mode "Archive"

Former Member
0 Kudos

Hello all

We're polling files from an external FTP server. For this I created a scenario on XI according to this thread:

...

When setting processing mode to "Archive" in the file sender adapter (ftp) it polls the file, stores it to the archive directory I specified and then tries to delete the file on the FTP server side. This returns me an error because we're not allowed to delete the retrieved files on the FTP server!

Because of this error the file adapter stops further processing and does not poll all the other files.

How can I disable this deletion mechanism while keeping processing mode to "Archive"?!?!?

We do not want to use processing mode "Delete" or "Test" and we don't see other options to influence this behaviour.

Thanks for any guideance on this one in advance!

Kind regards,

Renaud

Accepted Solutions (1)

Accepted Solutions (1)

bhavesh_kantilal
Active Contributor
0 Kudos

Hi,

You can look into the option of using an OS command in your Sender File Adapter.

<b>Keep the mode as TEST. In the OS command , write a simple OS command to move it to the corresponding Directoy.</b>

Regards,

Bhavesh

Former Member
0 Kudos

Hi Bhavesh

Where are the files being stored if I set the mode to TEST?!? There's no option to specify a directory if you set TEST mode.

BR

Renaud

bhavesh_kantilal
Active Contributor
0 Kudos

renaud,

When you say test, the file's contents will be passed to the integration engine by the file adapter. The file will not be deleted / moved or archived.

When you say Archive, the file will be deleted and then aa copy of the file will be moved to the Archive Folder.

As you told, you do not have the access rights to delete the file, what I suggest is , you write a simple script that will move the file from the source directory to the archive directoy .

For this , take a look the RUN OS COMMAND BEFORE ? AFTER MESSAGE PROCESSING in this link,

http://help.sap.com/saphelp_nw04/helpdata/en/e3/94007075cae04f930cc4c034e411e1/content.htm

Or, you can get the DELETE credentials for the user Id being used to access the files. So that the file will be archived using the normal file adapter 's ARCHIVE option.

Regards,

Bhavesh

Former Member
0 Kudos

Hi,

If it is in test mode,the file wont get deleted in ur source direcory.So tha adpater will keep polling the file and the server will be flooded with messages.If it is in the delete mode file will be deleted,archive mode it will be moved in to the archived directory but in the test mode file will not be deleted from ur source directory and will be polled continously by the adapter

cheers

jithesh

Former Member
0 Kudos

Hi jithesh, Bhavesh

Thanks for your help!

In the meantime I was able to partly solve it! This is what I've done:

a)

b) in file sender adapter (FTP) I set processing mode to TEST and flagged some adapter specific attributes (e.g. FileName, Directory, SourceFileTimeStamp)

c) in file receiver adapter (NFS) I set target directory to some locally available drive & folder and the file name schema to %message:FileName%. File creation mode is set to CREATE. I did not enable variable substitution. In adapter specific attributes I flagged FileName.

This way the XI polls for files on the FTP server and stores them on my local drive & folder.

Now I have to dynamically determine YYYYMMDD from the file timestamp (SourceFileTimeStamp) in order to put the files to a folder called YYYYMMDD.

I set the poll interval (sec) to poll once daily. The files (4) on the FTP server we need to retrieve get updated every 2 weeks (+/- some days). This way I can "archive" the retrieved files and it also doesn't matter whether or not I already retrieved them... they will be overwritten in the correct target directory.

So far the concept... "just" need to implement it.

Do you or someone else know how to pull YYYYMMDD out from SourceFileTimeStamp in order to become able to use it in variable substitution in the file receiver adapter?

Kind regards,

Renaud

bhavesh_kantilal
Active Contributor
0 Kudos

Renaud,

I. Using this code, you can get the Source Filename in you mapping.

<i><b>DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

DynamicConfigurationKey key = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/File","FileName");

// Get Sourcefilename

String oldfilename=conf.get(key);</b></i>

II. AM not sure why you are complicating the scenario, but if your requirement currently is to create a file name with the same name as the source name and then apend the time stamp to it. This can also be done,

1. In sender FIle adapter , ADAPETR SPECIFIC ATTRIBUTES --> SELECT FILENAME

2. In receiver file adapter , Adapter sepeciic attributes --> FIlename is selected.

In the FIlename field of the receiver file adapter , give some dummy name.Now, the same file name of the source will be used as the filename of the target.

To append the time stamp, in your Recievr FIle adapter, select the option Creation Mode --> Add timre stamp.

Regards,

Bhavesh

Former Member
0 Kudos

Hi Bhavesh

Sorry to sometimes explain things in a complicated way... Let's try again:

I have no problem with the file name but with the source file <b>timestamp</b>. I don't want to add a timestamp to the filename! I want to use the timestamp of the source file to dynamically create a target directory name with it and then to put the files I retrieved (polled) from FTP server 1:1 into this target directory.

Ex.

File on FTP-Server   Timestamp of File
----------------------------------------
a_file.zip           2006-07-27 13.23.15

The file "a_file.zip" shall be retrieved from FTP server and stored to a local drive into a folder called d:\dataexch\20060727\.

The subfolder name 20060727 needs to be determined from the source file timestamp (in above ex. = 2006-07-27 13.23.15).

Hope this clarifies things

Kind regards,

Renaud

bhavesh_kantilal
Active Contributor
0 Kudos

Hi Renaud,

Cant you ask the Application system creating the file to append the TIMESTAMP with the filename? This is the only way you can get the SOurce File STamp.

As for creating a dirtectoy dynamically, in yor receiver file adapter, dump the file in a dummy directoy and then you will have to write a script in your FIle adapter to read the filename, get the timestamp value out of the filename, create the folder and then move the filename from the dummy folder to the new folder.

Regards,

Bhavesh

Former Member
0 Kudos

Hi Bhavesh

Sorry for the late answer. Unfortunately I can't ask the application system to provide file names containing a timestamp within. The files are provided by an external partner and are retrieved by several others as well.

In the meantime I managed to achieve this:

In repository I created dummy data types, message types and message interfaces. No mapping programs and interface mappings!

In configuration I created the necessary communication channels (1 ftp sender, 1 file receiver) and the required receiver and interface determinations as well as the sender and receiver agreements.

The result of this is:

I'm able to poll some specific files via ftp from remote host. The file names are file1.arj, file2.arj, file3.arj and file4.arj. All 4 files have the same SourceFileTimestamp (e.g. "20060727T053900Z").

I'm able to store those 4 files 1:1 in a target directory with the same file names. Until here I did NOT need to follow this blog: <a href="/people/michal.krawczyk2/blog/2005/11/10/xi-the-same-filename-from-a-sender-to-a-receiver-file-adapter--sp14: The same filename from a sender to a receiver file adapter - SP14</a>.

As of this blog it is possible to access adapter specific attributes and make them available in message mapping using user defined functions. This way I'm able to get the SourceFileTimestamp from the polled files and use it in a message mapping. This way I'm also able to use it in variable substitution on file receiver adapter (syntax = "payload:root,1,fileTS,1") in order to dynamically create a directory with this syntax: YYYYMMDD.

So far so good... but the only remaining BIG problem now is, that as soon as the mapping is activated and assigned in the interface determination, the created files contain the XML payload instead of the original binary content. Where has it gone? How should the target message type look like so that it can carry over the original binary file content?

BTW: isn't it possible to post screenshots? Would be much more easier to explain things... so sorry to anyone if I wasn't clear enough!

TIA and best regards,

Renaud

bhavesh_kantilal
Active Contributor
0 Kudos

Reanud,

To be frank am seriosuly lost here in what the entire requirement here is

<i>In repository I created dummy data types, message types and message interfaces. No mapping programs and interface mappings!</i>

Well, in this case you are using XI as a mere FTP service.

So far so good.

But, if you are going to change the filename in the Message mapping by appendding a time stamp and then creating the directory dynamically, then you will need to have a Content Conversion on both the sender and receiver file adapter which will actually complicate things.

So, the better and more simple way to do this is .

1. Use XI as the FTP service.

2. Dump all Files in a Dummy Directory.

3. In the receiver file adapter , use the TIMESTAMP option to append the Timestamp to the file.

Now, you can write a Script that will get executed from the file adapter that will pick these files from the dummy directory, extract the TImeStamp, create the folder dynamically and then move files to this new folder.

Let me know if i have understood the requirements correct. and if this solution is feasible.

Regards,

Bhavesh

Answers (1)

Answers (1)

Former Member
0 Kudos

Hiiii,

Chk out this thread

this has the reply for ur answer

cheers

jithesh

Former Member
0 Kudos

Hi jithesh

Just read through it... doesn't fit to my problem. But there are some other interesting info that I'll keep in mind.

Thanks!

BR,

Renaud