Skip to Content
Calling the BAPI generally means executing SAP transactions from external world, in which SAP will process the transaction based upon the data passed from external system in background and report the result/errors to the external system in terms of parameter.

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.

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Thomas Jung
    I too have seen the same problem in the SAP Backflush BAPIs.  I wrote an ABAP wrapper function module around the BAPIs.  From the wrapper I call the BAPIs using DESTINATION ‘NONE’.  I then use the special remote exceptions to catch the ABAP dump.

        call function ‘BAPI_REPMANCONF1_CREATE_MTS’
             destination ‘NONE’
             exporting
                  bflushflags   = flush_flags
                  bflushdatagen = flush_data
                  bflushdatamts = mts_data
             importing
                  confirmation  = confirmation
                  return        = return
             exceptions
                  communication_failure = 1 message msg_text
                  system_failure        = 2 message msg_text
                  others                = 3.

    But regardless of whatever workaround you find, I would encourage you to open an OSS problem with SAP when you find something like this.  BAPIs are supposed to be safe to call without dynpro.  I’m sure that SAP will try and address this and post an OSS note that will benefit other customers.

    (0) 
  2. Thomas Jung
    I too have seen the same problem in the SAP Backflush BAPIs.  I wrote an ABAP wrapper function module around the BAPIs.  From the wrapper I call the BAPIs using DESTINATION ‘NONE’.  I then use the special remote exceptions to catch the ABAP dump.

        call function ‘BAPI_REPMANCONF1_CREATE_MTS’
             destination ‘NONE’
             exporting
                  bflushflags   = flush_flags
                  bflushdatagen = flush_data
                  bflushdatamts = mts_data
             importing
                  confirmation  = confirmation
                  return        = return
             exceptions
                  communication_failure = 1 message msg_text
                  system_failure        = 2 message msg_text
                  others                = 3.

    But regardless of whatever workaround you find, I would encourage you to open an OSS problem with SAP when you find something like this.  BAPIs are supposed to be safe to call without dynpro.  I’m sure that SAP will try and address this and post an OSS note that will benefit other customers.

    (0) 
  3. Thomas Jung
    I too have seen the same problem in the SAP Backflush BAPIs.  I wrote an ABAP wrapper function module around the BAPIs.  From the wrapper I call the BAPIs using DESTINATION ‘NONE’.  I then use the special remote exceptions to catch the ABAP dump.

        call function ‘BAPI_REPMANCONF1_CREATE_MTS’
             destination ‘NONE’
             exporting
                  bflushflags   = flush_flags
                  bflushdatagen = flush_data
                  bflushdatamts = mts_data
             importing
                  confirmation  = confirmation
                  return        = return
             exceptions
                  communication_failure = 1 message msg_text
                  system_failure        = 2 message msg_text
                  others                = 3.

    But regardless of whatever workaround you find, I would encourage you to open an OSS problem with SAP when you find something like this.  BAPIs are supposed to be safe to call without dynpro.  I’m sure that SAP will try and address this and post an OSS note that will benefit other customers.

    (0) 
  4. Gregor Wolf
    Hello Ajay,

    we also had this problem. But with our own RFC enabled Function module which does a Batch Input for manufacturing confirmation. The standard transaction pops up with a info message which causes “GUI not reached” when calling from a Web Application.

    Our solution was a JCo Wrapper with “jco.client.use_sapgui=1” running as a Service on a Windows Box with SAP GUI installed. Because I the there is rearly interrest on this Toppic I promise to post also a Weblog.

    Regards
    Gregor

    (0) 
  5. Gregor Wolf
    Hello Ajay,

    we also had this problem. But with our own RFC enabled Function module which does a Batch Input for manufacturing confirmation. The standard transaction pops up with a info message which causes “GUI not reached” when calling from a Web Application.

    Our solution was a JCo Wrapper with “jco.client.use_sapgui=1” running as a Service on a Windows Box with SAP GUI installed. Because I the there is rearly interrest on this Toppic I promise to post also a Weblog.

    Regards
    Gregor

    (0) 
  6. Gregor Wolf
    Hello Ajay,

    we also had this problem. But with our own RFC enabled Function module which does a Batch Input for manufacturing confirmation. The standard transaction pops up with a info message which causes “GUI not reached” when calling from a Web Application.

    Our solution was a JCo Wrapper with “jco.client.use_sapgui=1” running as a Service on a Windows Box with SAP GUI installed. Because I the there is rearly interrest on this Toppic I promise to post also a Weblog.

    Regards
    Gregor

    (0) 

Leave a Reply