Suppressing unwanted SAP GUI screens from BAPI/RFC when calling them from external system in background
But for sometime these BAPIs does not serve the purpose they are made for e.g. BAPI_SALESORDER_CREATEFROMDAT1 in SAP R3 4.5B tries to generate SAP GUI screens only when try to call it from external system through RFC. This call to the screen is unexpected because its not triggered when calling it from se37 transaction of SAP.
The SAP GUI screen was triggered because of some (could be) wrong sequence of program calls which is based upon one memory parameter value.
Solution of BAPI_SALESORDER_CREATEFROMDAT1 problem: Solution for such problem is to stop the screen generation without affecting the business functionality of BAPI….
For BAPI_SALESORDER_CREATEFROMDAT1 we analyzed the BAPI and found that problem was because this BAPI/RFC tries to check if GUI (of system from where BAPI is called) has got ActiveX components or not and generates SAP GUI popups after the process, while calling this BAPI from se37 transaction skip this check because SAP GUI by default has ActiveX controls and it is controlled by memory parameter ‘GUI_HAS_ACTIVEX’ and the check process is skipped because this parameter is already set in environment.
So the solution for this problem was to set the this memory parameter before calling the BAPI from Java which will skip the ActiveX check and hence the SAP GUI popups will be suppressed.
Step1: create a wrapper BAPI for BAPI_SALESORDER_CREATEFROMDAT1.
Step2: Put the following code in wrapper bapi before calling BAPI_SALESORDER_CREATEFROMDAT1 . ….get parameter id ‘GUI_HAS_ACTIVEX’ ‘X’.
Execute the wrapper BAPI from external system (Java/.net etc) this will solve the SAP Dump problem.
Extension of solution: This solution may be extended for such kind of problems. I am listing the steps we followed up to identify this problem and solving it. It may help to identify some of these kinds of problems.
1) Search for SAP Note to be applied for the particular problem in BAPI, if found apply the note on your system..
2) Try putting an exception id in the RFC ‘ERROR_MESSAGE’, this will try to eliminate any message or popup generation from RFC.
3) If the above solution does not work, debug the whole RFC to get the point where screen has been tried to send to the user under background (or follow the SAP Dump to identify the code), if the code is initially in the calling RFC stack you are lucky.
4) Now analyze the code which generated the dump and try to find out a single parameter or the FM or an include program call which generated the dump. Also find out changing the code should not create any problem in business process or further execution of BAPI.
5) Find out the source of the parameter value which is controlling the follow of the problem creating code.
6) try to eliminate the executing of problem creating code by either setting the parameter into the memory or passing the different value from the main BAPI.
7) If step 6 does not solve the problem, copy the BAPIs from (each RFC) into ZBAPI and start eliminating the code by passing the different parameter or commenting the code which calls the code (which creates the dump)..
8) After step 6 if it is not possible to eliminate the code (it could create problem while calling the FM from SAP), then write a small code to divert the RFC call at that point based upon the calling system (Follow SAP note 673402) use the FM RFC_IS_GUI_ON (returns Y when calling from SAP and N while calling from Java/.Net etc)to divert the call sequence of screen generation program..
9) If in the step 8 while diverting the call from screen generation program is taking off your business functionality, you can also put in required information or call to other RFC to fill up the gap of functionality..
10) Test your new BAPI several times for each possible combination of data from R3 as well as through connectors.
We have also used this method of commenting the code from FMs and filling up the functional GAP by setting up some parameters in the program for our web enabling functions of Work Flow in custom designed portal screens. We have executed work items in the background by suppressing the mandatory screens like decision screens by passing the user decision in background.