Issue with tRFC call for data transfer

[former_member195421]

Hi All,

We are using a custom program to do the data migration to a target system , in source system we have a report which fetches the data to be migrated to target in a select end select statement and application logic is written inside this select  and end select to derive the output values to be transferred to target .After finalizing the output data inside select end select , we have a tRFC call implemented to do the data transfer . This RFC function module in target in turn call another update function module  to insert the migrated data .

Please see the template of source report .

Select  using package size.

    application logic .

    Call Function module in back ground task destination .  ---------------> this FM in target system calls update FM ( to insert the data in target tables)

End select .

Commit work .

So in case there is a large volume of data select end select will run multiple times and tRFC registration will happen on the same function module multiple times and once commit work is reached these will get executed in the target system .

Problem with Customer :

Customer executed the program with package size 10 for a total record of 25000 and in target system he got only 800 records .

what happened to the remaining records , no dump found in source and target system .

Since it uses package size 10 select  end select could have run 2500 times and tRFC registration on the same function module has happened 2500 times , will the problem happened because of unavailability of work process in target system ? any body experienced such issues before ? Any body knows how exactly this 2500 registration of same FM tRFC calls getting executed , will in a single work process ?

Please help to provide a solution / correction to the program .

Regards,

Ratheesh BS

[former_member195421]

Hi All,

We are using a custom program to do the data migration to a target system , in source system we have a report which fetches the data to be migrated to target in a select end select statement and application logic is written inside this select  and end select to derive the output values to be transferred to target .After finalizing the output data inside select end select , we have a tRFC call implemented to do the data transfer . This RFC function module in target in turn call another update function module  to insert the migrated data .

Please see the template of source report .

Select  using package size.

    application logic .

    Call Function module in back ground task destination .  ---------------> this FM in target system calls update FM ( to insert the data in target tables)

End select .

Commit work .

So in case there is a large volume of data select end select will run multiple times and tRFC registration will happen on the same function module multiple times and once commit work is reached these will get executed in the target system .

Problem with Customer :

Customer executed the program with package size 10 for a total record of 25000 and in target system he got only 800 records .

what happened to the remaining records , no dump found in source and target system .

Since it uses package size 10 select  end select could have run 2500 times and tRFC registration on the same function module has happened 2500 times , will the problem happened because of unavailability of work process in target system ? any body experienced such issues before ? Any body knows how exactly this 2500 registration of same FM tRFC calls getting executed , will in a single work process ?

Please help to provide a solution / correction to the program .

Regards,

Ratheesh BS

[Former Member]

Hi,

please look for errors in table ARFCSSTATE in source system.

Regards,

Klaus

[former_member195421]

Hi Klaus,

There is no records available in ARFCSSTATE table with my target destination and function module name.

Could you please see the source program template given in the original post and see if issue can happen because of non availability of work process in target system.

Regards,

Ratheesh BS

[Former Member]

Hi,

if there is no free connection, then you should have entries in table ARFCSDATA. A program named RSARFCSE should run every 15 minutes and try to send all those data packages up to 30 times.

Maybe meanwhile your missing data have received the target system or otherwise you may have a broke connection.

Regards,

Klaus

[nabheetscn]

Do you see any entry in SM58?

Nabheet

[former_member195421]

Hi Nabheet ,

There is no entry in SM58.

Regards,

Ratheesh

[nabheetscn]

And what about ARFC* tables?

[Former Member]

Hi,

I've checked on of our programs running on production system. There we have one SELECT into an internal table.

We have a DO loop to get the next n entries from the internal table into an internal package table.

And after each remote function call using the internal package table we have a COMMIT WORK.

In your program you can have only one COMMIT WORK, because you are in a SELECT ENDSELECT loop.

I would suggest to change your program logic to avoid sending rfc calls in SELECT ENDSELECT LOOP without COMMIT WORK..

Regards,

Klaus

[former_member195421]

Hi Klaus,

I am also considering to change the program logic from sending large number of rfc registrations into the queue .

Do you think adding as SEPARATE UNIT addition to the tRFC call will  give some advantage , I know that it will register the RFc calls in separate TIDs and will execute as separate contexts . I am not sure about

1. If an error in any of this TIDs will do a complete ROLLBACK of all TIDs

2. In case of separate TIDs ,  will execution happen in a single work process in target system or it look for different work process?

Regards,

Ratheesh BS

[Former Member]

Hi,

I think the main difference using AS SEPARATE UNIT is, that every fm call will get his own data context, which means that all data within the function group of the called fm will have their own area in memory. So you have intitialized data for every fm call, but you need more memory space.

Without that the function group will keep the data of the earlier calls, if you don't clear it manually.

Answering your questions:

1. No, definitely not. ROLLBACK and COMMIT in the target system depend on your code in the RFC fm, not on the code in the calling program.

2. I'm not sure here, but I think it might be different work process. But that's no difference to the program logic with data package. Every COMMIT might use another work process. But it will also depend on the program logic in your RFC fm.

Regards,

Klaus

[SuhaSaha]

I think you should add a trace in your custom code so that you know what is happening during runtime. For this you have to use the FMs -

• ID_OF_BACKGROUNDTASK
• STATUS_OF_BACKGROUNDTASK

And since you are making multiple calls to the same destination i think you should consider having a look at the addition - AS SEPARATE UNIT.

BR,

Suhas