Skip to Content

RFC Fails in Background job via event BP_event_raise in badi .?

Jan 28, 2017 at 04:09 PM


avatar image
Former Member

short-dump.pngshort-dump1.pngHi All,

I have a requirement to send GRN posting data after databse commit in ecc, to non ecc system, for which i have written a code in Badi MB_document_badi of method MB_DOCUMENT_UPDATE by calling event FM: BP_EVENT_RAISE passing event which was created in SM62 and this FM calls the background job which holds our RFC with destination... So here the problem is some time's RFC is success and some times it fails , i am getting sy-subrc = 1 as system failure. Attached the Short dump as well. at PI side they were not able to see any messages from ECC.

Kindly help me to fix the issue .

Thanks in advance.



short-dump.png (62.5 kB)
short-dump1.png (30.6 kB)
10 |10000 characters needed characters left characters exceeded

As you didn't attach the short dump as a .txt zipped file, we can't see the contents of lv_msg1/lv_msg2 variables (probably they contain the text of the failure (system_failure = X message lv_msg1/lv_msg2))

* Please Login or Register to Answer, Follow or Comment.

2 Answers

avatar image
Former Member Jan 29, 2017 at 09:40 AM

Hi Sandra,

Please find the attached Short dump .txt file.

My situation here is strange that RFC executes some times and fails some times in background, when i. debug the background job using JDBG , RFC is getting response from other system. below is my RFC code.

filling the all internal table and passing to RFC as shown below.

this RFC is wriiten in one custom program , that program is assigned to event in BG job, this job is called via BP_event_raise , again this event is called in materila master MGA00001 exit via same FM bp_event_raise.

it_mat_date = lt_mat_data
it_mat_sales = lt_sales
it_mat_plant = lt_plant
it_mat_taxcl = lt_taxcl
it_status = it_status
it_plant_sloc = lt_plant_sloc
it_mat_desc = it_mat_desc
it_mat_uom = it_mat_uom
it_mat_upid1 = it_mat_upid1
it_mat_upid2 = it_mat_upid2
it_mat_upid3 = lt_upidskuloc
system_failure = 1
communication_failure = 2
* To recieve Status from Pharmanet And Update in Sap Custom table
IF sy-subrc EQ 0.

........saving status from RFC i.e it_status in custom table.


Please help me to fix the issue.

Thanks & Regards,


dump.txt (118.0 kB)
Show 2 Share
10 |10000 characters needed characters left characters exceeded


Too bad, I thought you could have more information in the additional message of system_failure, but your code doesn't retrieve it, and so it's not in the short dump too.

That said, the fact that it's a "system failure" rather than a "communication failure", means that the "program is reached" but fails.

The 128 first characters of the main message are "Bean ... not found on host ..., ProgId =...: Object not found in lookup of ..." Using this text, I searched the SAP notes, and could only find the note 1840707 - Bean IDOC_INBOUND_ASYNCHRONOUS not found on host of PI 7.3, whose cause may be "if there are extra listeners registered to the gateway ..." (maybe you can investigate more at PI side, based on information of the SAP note, and also have a look at the NWA Log Viewer).

Former Member
Sandra Rossi

Thanks for reply..:)

our basis team and PI checked the Program ID , they are using different one for each communication channel.

Even i checked the above SAP note , but here our RFC is synchronous and not related to any idoc. RFC is just picking the data and sending to third party.

I still don't know what's the RFC fails and success Randomly.

Thanks for help.



Raghu Govindarajan Jan 30, 2017 at 07:10 PM

Looks like in the other system you are missing a function module... or a mis-spelling?

|    CPI-C error text: "Bean ZACC_M_I_MATERIAL_CREATEEXT not found on host iplpid,                 |

The very next line is

ProgId =RFC_MAT: Object not found in lookup of ZACC_M_I_MATERIAL_CREA"

which leads me to think that there maybe a limit on the size of the RFC name, up to 22 characters?

Show 2 Share
10 |10000 characters needed characters left characters exceeded

If you count the number of characters of the message, it's 128 characters, so I think it's just globally truncated.


Yep, 128 seems more logical than 22. Try explaining that to someone who is not used to thinking in Base-2 :)