cancel
Showing results for 
Search instead for 
Did you mean: 

RFC to FTP scenario

0 Kudos

Hello, everybody.

I have a synchronous RFC to FTP scenario. The FM sends an internal table which is converted to a text file. Until here it is working perfectly. I have not used BPM yet.

Now I need to know whether the FTP really worked, to take actions according to its return code. Are there ways to get the return code from the file/ftp adapter? And how to I do it?

Thanks a lot,

Marcos.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

If it is a realtime synchronous process , best practice and the only suggestable approach is use BPM.

If it is not real time, you can maintan it in 2 different flows of asynchronous flows of single interface.

Thanks,

venu

Answers (7)

Answers (7)

0 Kudos

I used the scenario at /people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi as a guide. The situation is very similar to mine.

0 Kudos

I used the scenario at /people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi as a guide. The situation is very similar to mine.

When I run the RFC, BPM it started and file is sent to the FTP server. Maybe I have made mistakes when I configure the "File Sender Channel" referred in the post above. The first (RFC sending request) and third (RFC receiving response) steps ends with System Error.

May anyone show me an example of a sender communication channel for this case? Other doubt: will sender channel always be active, running from time to time? Another doubt: once I know the filename before sending it, does it helps me or not?

I maybe also have correlation problems. The file contains heterogeneous record types. How should I correlate them? May I use the first line of the file once it has file specific information?

0 Kudos

When the whole process is asynchronous, eveerything is okay, but when I convert to synchronous, it doesn't work.

I understood that the flow is: RFC -> BPM, BPM -> FTP (Receiver), BPM -> FTP (Sender) and at last BPM -> RFC. It means I would have receiver determination for the first 3 steps. Am I right?

I also understood that, in the last configured step, BPM will receive the response (file) coming from File Adapter, so I will have to specify a Sender Agreement in the FTP side. How should I create it once I know the file name since the beginning of the process?

Thanks a lot,

Marcos.

bhavesh_kantilal
Active Contributor
0 Kudos

Hi,

No you will need only 2 Receivr Determinations.

1. One From the RFC to the BPM

2 Another from the BPM to the File.

The BPM design will have to use a Synch - Asynch Bridge. What you will need to do is,

1.In the receive step in the BPM you will need to select option for the Receive Step ,ie. Mode as Open Synch - Asynch Bridge.

2. When you send the response back to the RFC from the BPM, the mode for the send step should be , Close Synch Asynch Bridge.

Regards

Bhavesh

Former Member
0 Kudos

HI,

see the below links

/people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi - Use of Synch - Asynch bridge in ccBPM

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken] [original link is broken] - Use of Synch - Asynch bridge in ccBPM

Regards

Chilla

Former Member
0 Kudos

Happy Birthday

prateek
Active Contributor
0 Kudos

Hi Marcos,

The use of BPM is a must since u need to persist the status of ur file and intimate the sender accordingly. So no new interface is required

No, u dont have to make another RFC call from the R/3.

Only Application Acknowledgments could tell us that the message was processed by the receiver application. Now since this information is not available directly for File Adapter, u have to go for system acknowledgement which may notify u whether message was transferred from the XI adapter. So in ur case u have to make an assumption tht

"if message passed through receiver file adapter, then it is successfully saved"

However, this could create some problem in live scenarios.

This workaround could be practically unfit but here it goes,

Since u know the filename before triggering XI, pass it in payload and create the file with the same name. Now using BPM, Rec1 - Send1 - Rec2 - Send2, in the Rec2 step use FTP sender. Check whether file is found here or not and accordingly give response to RFC.

Regards,

Prateek

bhavesh_kantilal
Active Contributor
0 Kudos

Hi,

Use a BPM and get the Transport Acknowledgement for the file in the BPM.

If a successful acknowledgement send the success response to the RFC else send the unsucessful response.

For File ack's use this blog as a starting point,

/people/michal.krawczyk2/blog/2006/06/22/xi-playing-with-the-file-adapters-acknowledgments

Regards

Bhavesh

Former Member
0 Kudos

Hi,

The transport acknowledge is only send the ack that the msg is reached to receiver from XI, i mean this was transported from XI only.

But here the requirement is the return code , some thing related to Application message i hope.

See the Acknowledgements

from the file adapter FAQ note: 821267

<i>Q: Does the File Adapter support acknowledgements?

A: You need to distinguish system acknowledgements (indicating that a message has been received by the target system) and application acknowledgements (indicating that the message has been successfully processed by the application on the receiver side).

The receiver of an XI message will only send an acknowledgement back to the sender if the sender has requested one. However, the File Adapter has no functionality that relies on the receipt of an acknowledgement, so it never requests one.

On the other hand, if a File Adapter Receiver receives a request to send an acknowledgement, it will do so for a system acknowledgement request. Application acknowledgements are not supported at all as the File Receiver has no way to determine if the written file has been correctly processed by the back-end application, which is what a positive application acknowledgement would imply.</i>

regards

Chilla..

prateek
Active Contributor
0 Kudos

Hi Marcos,

The file adapter does not support the synchronous scenario.

When u send data from RFC to file, a text file is created at FTP. Now u may configure a scenario wherein this new file created will be act as input file in ur scenario for further usage. For this u need to use BPM

Without BPM, in XI u can only get the acknowledgements.

The receiver adapter supports system acknowledgments but not application acknowledgments.

Regards,

Prateek

0 Kudos

Hello, Prateek.

Since the File Adapter call cannot by synchronous, it has been a little difficult for me to "see" the solution.

The point is, I have an internal table I need to save as a text file in the partner´s server. Before triggering the XI, I already know the file name. And until here, everything is okay.

I need to know whether the file was successfully saved to delete the database entries that generated the file. It cannot be sent again.

If you could please help me once more, my questions over your response are:

- I would use BPM and it would solve my problem without triggering XI once more, right? I mean I would have to make another RFC call from the R/3, am I right?

- Now, I will show you my biggest problem: since File Adapter does not return application acknowledgments, which step should I add to my BPM to achieve what I need? I understood BPM will simulate this synchronous call, won't it?

Thanks a lot,

Marcos.

Former Member
0 Kudos

Hi,

See the below link it will solve all.

XI: Playing with the file adapter's acknowledgments

/people/michal.krawczyk2/blog/2006/06/22/xi-playing-with-the-file-adapters-acknowledgments

Regards

Chilla

<i>reward points if it is useful..</i>