Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

RSARFCEX - Scheduling Error

Former Member
0 Likes
2,764

Due communication failure tRFC are failed . To reprocess failed tRFC I am using RSARFCEX and scheduling the program as job with the frequency of every 5 min. It does delete the entry from SM58 and shows like it has been processed . But I i checked with the Broker It is not . But when i execute the same program manually ( SE38) . It works perfectly fine . It seems at a glance . There is some issues When I am scheduling the same . Any input is apprciated .

Thanks

Sameer

Due communication failure tRFC are failed . To reprocess failed tRFC I am using RSARFCEX and scheduling the program as job with the frequency of every 5 min. It does delete the entry from SM58 and shows like it has been processed . But I i checked with the Broker It is not . But when i execute the same program manually ( SE38) . It works perfectly fine . It seems at a glance . There is some issues When I am scheduling the same . Any input is apprciated .

Thanks

Sameer

2 REPLIES 2
Read only

Former Member
0 Likes
1,318

hi,

For the R/3 system to identify incorrect calls, it must receive a proper error status for each Oracle Application Server ProcessConnect inbound call. The protocol for all ALE interactions automatically handles the error status; whereas the protocol for RFC will not unless you explicitly select the transactional RFC (tRFC) protocol. This is the same protocol used by ALE. In ABAP, if the keywords "in background task" are appended to the call statement, then the function module is called asynchronously. This has the side effect of selecting the tRFC protocol. The tRFC protocol automatically reports errors. For example, the call to the function module Z_MY_FUNC_MODULE would look like call function 'Z_MY_FUNC_MODULE' in a background task.

Managing Incorrect Calls

To list incorrect calls, log on to SAPGUI. Using the R/3 system standard menu, select Tools > Administration > Monitor > SM58 Transactional RFC. Enter your search criteria and click Execute. The list of incorrect tRFC calls appears. On this page, you can delete an incorrect call by selecting a row and clicking Delete Entry. You can also reexecute a call by selecting a row and clicking Edit > Execute LUW. The list contains both invalid ALE calls and invalid asynchronous RFC calls.

To reexecute incorrect calls in batch, log on to SAPGUI. Using the R/3 system standard menu, select Tools > ALE > ALE Administration > Services > Communication > Transactional RFC > BDA1 Invoke Calls Again. Enter your selection criteria. It is recommended that you unselect the option Currently being processed. As soon as you click Execute, the calls immediately reexecute. For automatic retry, save your selection criteria as a variant. Select Goto > Variants > Save As Variant and give your variant a name.

Scheduling an Automatic Retry

To retry incorrect calls automatically, you must schedule a background job. This uses the built-in ABAP program, RSARFCEX. Log on to SAPGUI. Within the SAP standard menu select: Tools > CCMS > Jobs > SM36 Definition. The screen to define a background job appears.

Enter a new job name, for example, TRFC_RETRY.

Enter job class C.

Click Start Condition.

Click Immediate.

Select Periodic job.

Click Periodic values and enter the period.

Make sure the period is long enough to allow completion of each iteration.

Click the diskette icon to save the period values.

Click the diskette icon to save the start time.

Click Step.

For the ABAP program name, enter RSARFCEX.

For the Variant, enter the name of the variant you created on the BDA1 screen.

Click the diskette icon to save the step.

Click the diskette to save the background job.

As soon as you save, the ABAP program runs the job.

If a call is retried and fails again, it stays in the queue and it is retried at the next iteration.

Read only

0 Likes
1,318

Thanks Pranab - For taking time and replying me .I have already done everything before coming to this forum for an answer . Issuse lie somewhere in scheduling when i schedule the RSARFCEX . It does delete the failed records from SM58 but never post the same to Broker . Albeit It works fine when you do the same manually .

Regards

Sameer