Details of RFC IN BACKGROUND TASK
The post described about tRFC(Asynchronous RFC – IN BACKGROUND TASK) details. Consider we have two system and one system does some business process , then calls another system to pass the data via RFC connection in an asynchronous way and commits the business process.
As the RFC is called asynchronously, this RFC FM is not executed at the time of call, but what the COMMIT WORK occurs. So with COMMIT WORK the LUW completes and then the tRFC execution starts( which can be monitored in the Tx- SMQS) but the RFC connection failed due to some reason.
That means the business process is complete in the first system and the RFC connection failed to pass data to the target system. With tRFC the call is written in the table – ARFCSSTATE and the call data is stored in table- ARFCSDATA .
By default the system again tries to execute the RFC FM again with a frequency of 15mins and continue this for 30times until the call is successful.
If default(30 times) call attempt with a gap of 15mins is not sufficient, then in the RFC destination(Tx- SM59), it is possible to set tRFC options which allows to set what is the number of attempts and the gap time in minutes between 2 consecutive calls.
The post describes the process in details with screen shots: for the demo, the tRFC call is made in 2 different clients of the same system, but the same holds good in 2 different SAP systems.
Client-010 – Source, Client-070 – Target
Here we have a RFC FM with a small piece of code.
SCARR table entries in two clients.
RFC Destination created in client-010 to connect client-070
protocol as – tRFC
A small report that calls RFC FM (Asynchronously-tRFC). Execute the program.
Program output. Highlighted record reached in client-070
For demo- changed the instance number of the target system, so that RFC connection to fail.
Connection test is failed now.
Execute the program now ( Carrid = UA )
Commit work happened in the program . RFC FM executed but failed due to connection error. Record not reached in target client.
Now a background job created ( Tx- SM37 ) with a name start with – ARFC* , and the job is schedule to run 15 mins after.
The FM call data is written to the table – ARFCSDATA
The failed tRFC call is written in the table- ARFCSSTATE, one of the counter is 30, signifies that it has to try 30times atleast to make one successful call. If the call is successful in one of the 30 trials then, the entry deleted from the table.
As the RFC dest having error, after 15mins, the scheduled job executed but sue to that the RFC connection error, one more time a new job scheduled to run after 15mins.
Time diff = 15 mins
Now the table entry counter says that – remaining trial – 29 times.
Before the background job runs at the scheduled time, lets make the RFC dest work properly.
Now the scheduled job executed again and RFC FM executed without any connection problem. ( no more jobs ). Record reached in target client.
Up to this, we saw, how system tries to make automatically execute tRFC 30 times with a gap of 15mins in each trial which is the default settings for tRFC to ensure the RFC connection happened.
Lets try the option to set details in RFC destination.
Lets delete record from target client, so that we can test the demo scenario by sending the same record from source client.
Now no entry in ARFCSSTATE table for the RFC DESTINATION- TO_CLNT070
Go to Tx- SM59 and edit the destination. From menu choose Edit- tRFC options.
Below screen appears.
Provide details like- number of attempts – 100 and 10mins gap in 2 consecutive calls. Save.
Make sure that the connection, must not work so that we can test our demo scenario.
Execute the program again – with CARRID = AA
Record not reached in target.
Now the table – says it has to make a trial for 100 times which was set the RFC destination.
A job is scheduled to be executed 10 mins later.
After 10 mins, 1 trial to execute is finished with error. Now it has to make 99 trials.
Another job is scheduled.
Before the job runs at scheduled time, lets correct the RFC destination.
The tRFC calls can be seen from the system with Tx- SMQS. Choose the RFC destination name and select TRFC Monitor.
The below details can be seen.
After 10 mins, job executed again and this time no more scheduled job again , as the RFC call is successful.
Record created in target system
SAPCODES 