File2RFC: Input record one by one

[Former Member]

Hi Experts,

I m doing file to RFC scenario, Requirement is to insert one record (from file) one by one into table in R3 system.

My input file like below :-

<?xml version="1.0" encoding="UTF-8" ?>

- <ns0:MT_SENDER_BARCODE xmlns:ns0="http://barcode">

- <DATA>

<DOC_NUM>908989898</DOC_NUM>

<POSITION_NUM>10</POSITION_NUM>

</DATA>

- <DATA>

<DOC_NUM>12396698</DOC_NUM>

<POSITION_NUM>100</POSITION_NUM>

</DATA>

- <DATA>

<DOC_NUM>3445698</DOC_NUM>

<POSITION_NUM>1000</POSITION_NUM>

</DATA>

</ns0:MT_SENDER_BARCODE>

As per ABAPer FM and ZTable it is inserting only one Record into table in R3

It is not taking all records.

Please suggest some idea. Thanks

[Former Member · Accepted solution]

Maybe a 1:n msg mapping would do the trick, it would create multiple RFC requests containing 1 single record to process ? The best solution would be having a similar custom RFC function that would accept an input table so it can handle multiple records at the same time (and I think it could also improve perf/efficiency of the whole scenario) ..

Rgds

Chris

[Former Member · Accepted solution]

Hi,

I don't think a 1:N mapping will do the trick, since RFC's are synchronous. So you need an 1:N mapping in a BPM, then loop and do the individual RFC calls.

I agree on having an RFC that accept a table, that should increase performance a lot. But even at that, it could be necessary to use a BPM to send in batches of 500 records or so, to avoid timeouts caused by a late RFC response. The queues will time out after 3 minutes and your BPM will stop.

Even better is to use asynchronous proxies in ABAP that will call the RFC. This will avoid any timeouts, and you can avoid using BPM if you don't need the RFC response. If you do need the RFC response, you can use another asynchronous proxy to send them back to PI.

I always use the same RFC response message type, which is an extension of the BAPIRET2 structure, completed with a transaction number (the unique key for your record), so you can trace back the repsone to the input record. This confirms to and improves the BAPI standard.

I think should blog about this.. ^^

kr,

Peter Glas

[Former Member · Accepted solution]

I agree with you Peter ... In my answer, I assumed that RFC calls were async. and nr of records to pass were quite "limited" ! If you have 1000s of records to pass (in sync. mode to make things worse), I thing having an ABAP proxy wrapper (that would then post records internally using RFC calls, and maybe an additional part that would take care of responses if needed) could improve the whole situation ...

Chris

[Former Member]

Solved issue.

[Former Member]

Hi Anshul,

care to award points for helpful answers ?

kr,

Peter Glas

[Former Member]

Apologize for mistake.

It is done Thanks

[Former Member]

Thanks Anshul ^^

[Former Member]

Yes,

Right approach is to use Proxy . ... It is Simple and ... with High Performance.

2 Asynchronous scenarios will be created

1. File - XI - Proxy ( Call RFC Here in Loop)

In same Loop Get response from RFC for each file Record 1 by 1 ... and Store the Result into some Internal Table .

Now That Internal table will be passed to Outbound Proxy (Scenario number 2)

2. Outbound Proxy - XI - File.

As we know, Outbound Proxy Needs some report/Module to Execute ..So Inbound Proxy of Scenario 1 will act as Executing source for Scenario 2 ...Hence response will be sent.

___________________________________________________________________________

In message Monitoring You will be get 2 Messages.

One for Request to RFC ..Other For Response of RFC

_____________________________________________________________________________

Performance ..

1. Both Asynchronous Scenario ..so Good in Performance.

2. Proxy Work on ABAP Stack .. So no involvement of Java Stack .....

___________________________________________

Hope This Clears ...

Regards

Prabhat Sharma.

[Former Member]

Hi,

Thanks all for your inputs. I tried one logic which worked out...

In my file to RFC, In Sender side, I looped the node "DATA" with Internal Table (ITEM) at recevier end.

So If I send N records, internal tables reads and from there it goes to ZTable.

Cheers,

Anshul