cancel
Showing results for 
Search instead for 
Did you mean: 

File to RFC , Fiel should be deleted only when RFC success ?

Former Member
0 Kudos

Hi Friends ,

I am working on FIle to RFC scenario. In our scenario <b>FIle has to be deleted only when RFC succesfully done the process</b>.

<b> 1. Can you please suuges how to do this ?

2. What is the way to process file as One by one ?</b>

In our scenario many files will come at a time . So, file adapter will picks up all the file at a time and ata a time push to RFC right ? So, connection issue is coming ? So ,

<b> 3. How to send next file only when previous succesfully got executed ?</b>

Expecting your replys as soon as possible

Regards.,

Shyam

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi

In the Usual case also Files get deleted only when they have been processed.Just choose the processing mode to delete in the Sender File Adapter.

Thanks

Former Member
0 Kudos

Hi monika,

Thanks for your reply. But, FIle will be deleted only when it send to IS ( Measns process finished ) , but in our case we need to delete only when RFC has to process that data with out errors

Regards.,

Shyam

Former Member
0 Kudos

Hi

It will not delete the file until the data has been processed.RFC must be sending the data to a table , so unless the data is not entered into the table it doesnt delete it.

Thanks

Former Member
0 Kudos

Hi,

I think it is not possible to delete the file after the RFC is executed successfully at file adapter level.There is one way to do this but a little complicated. In BPM you can check if the receiving system has processed the request successfully otherwise you can create back the same file in the same location using receiver file adapter. Let us see if some one has a better solution.

Regards,

Sudheer.

Former Member
0 Kudos

Monika,

I think this is not the case"It will not delete the file until the data has been processed.RFC must be sending the data to a table , so unless the data is not entered into the table it doesnt delete it"

File adapter deletes the file no matter whether data has been posted or not to the receiving system,to SAP with RFC in this case.

lets say mapping failed ,if you keep files Sender file adapter with delete mode then file adapter keeps on deleting the files but the data will be stuck in XI without posting to SAP with RFC.

I think it happens that way. any comments? thank you.

Former Member
0 Kudos

Hey

>>I think it happens that way. any comments? thank you

yes you are correct,file will be deleted from the source directory irrespective of whether RFC is posted correctly or not.

Thanx

Aamir

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi ,

In simple terms ...file gets deleted ..as soon as it is picked by file adapter ..when the processing mode is set to delete ..

however in order to meet your requirement here is what you can do ..

since RFC behaves in a synchronous fashion what you can do ...instead of mode ...deletion you can have . move the file to the different location using archive mode ..

From which you can either delete it manually ...however if you want to fully automate this process as well ..

you may map the response of the rfc ...to another rfc ..which will have a code to play around with is file ...you may have to use bPM for the same.

In order to process file one by one ..

you can use the quality of service EOIO.

but ....in this case ...RFC may not be a good idea to handel these files ..

so you can either go for idocs or ...abap server proxy .

as load is clearly large.

How to send next file only when previous succesfully got executed ?

you may use BPM for the same ..which send a file ...wait for the response ...of rfc ,...take appropriate action based on the response of the rfc ..

like moving / deleting file ..et cetra

Former Member
0 Kudos

Hi,

Just a small doubt. Why dont you use the archive option to save the file in a different location so that even if you have some problems with the RFC processing you still have the original file so that you can resend it again. I think this approach is a better.

Regards,

Sudheer.