Skip to Content

How to… debug BAPI/RFC-calls in Web Dynpro

You use BAPI-calls or RFC-calls in your Web Dynpro project but you get no data viewed?
Here are some things you can do, identifying the problem.
Basically, there are three steps you should do:

  1. check your import parameters
  2. check in ABAP-trace files, if data is transmitted at all
  3. check your context mapping in the Web Dynpro views

Check import Parameters

First, I recommend to test the call in transaction SE37 and fill the necessary importparameters / tables. You can set RFC traget sys to NONE to simulate an RFC-call.
If your input data is verified, you can execute the remote call form your external application (like Web Dynpro) and check the dev_rd trace described in the next chapter.

ABAP trace files

Since, you’re connecting through a gateway to the ABAP-system, the data (input & output) can be traced.
Use transaction SMGW to increase the trace level of the gateway trace to at least 3 (SMGW, Menu Goto / Gateway / Trace / Increase level).
Check in ST11 the dev_rd trace file, if the level was set successfully to 3. There should be a line like:

You should be able to see (you have to search for it, because the amount of data is relative huge):

The name of the RFC / BAPI you’ve called & the input data. This is an example of the BAPI_GET_USER_DETAIL with importparameter set to HAUCK:

x103919a0 000560 07413130 315a4731 01190130 00284241 .HAUCK…..0.(BA
x103919b0 000576 50495f55 5345525f 4745545f 44455441 PI_USER_GET_DETA
x103919c0 000592 494c3d3d 3d3d3d3d 3d3d3d3d 46542020 IL==========FT
x103919d0 000608 20202020 20200130 01140003 39393701 .0….100.
x103919e0 000624 14011500 01440115 00090007 41313031 …..D……HAUC
x103919f0 000640 5a473100 09050100 01010501 05020000 K……………
x10391a00 000656 0502000b 00043632 3020000b 01020014 ……620 ……

That indicates, the call (incl. the input data) was successfully sent to SAP.

Some lines below, there should also be the output data visible, in this example (just the snippet of ADDRESS-structure):

700000060955760 000592 da08a705 14051200 00051202 01000741 ……………A
700000060955770 000608 44445245 53530201 020307b9 30303030 DDRESS……0000
700000060955780 000624 30323233 33333030 30303032 32313132 0223330000022112
700000060955790 000640 48657272 20202020 20202020 20202020 Herr
7000000609557a0 000656 20202020 20202020 20202020 20204163 Ac
7000000609557b0 000672 68696d20 20202020 20202020 20202020 him
7000000609557c0 000688 20202020 20202020 20202020 20202020
7000000609557d0 000704 20202020 20204861 75636b20 20202020 Hauck

So we can be sure, the call was successfull and the desired data was transmitted. Make sure to decrease the trace level again, because it’s growing very fast.

Check context mapping

Your context-nodes in the views should be mapped to the Output-nodes of the controller-context. These Output nodes should be invalidated in the controller after the remote call to inform the views that there’s new data.

You must be Logged on to comment or reply to a post.
  • What about the node serializer that Valery had built? You can also see the trace from the client machine for example your desktop from where you might test your webdynpro applications using these environment variables

    • hi pran,
      the node serializer? gave me valuable hints. but it doesn’t deal with this weblog? or do i get something wrong? or do you think we should use it for debugging the context? if someone wants to read our discussion:

      converting context-tree to xml?

      i didn’t know these environment variables. they sound vey comfortable. i’l ltry them.

      thanks, achim

      • Sorry Achim for not being very descriptive. I was just mentioning that if the model nodes can be serialized to an XML file they provide an alternate method of viewing data that is being sent to SAP

  • Hello,

    We have a Web Dynpro RFC application, which runs on EP and connects to a SAP bapi in a CRM server, does not receive data as expected.  The Web Dynpro is using a CPIC user, which has authorization to execute the BAPI in the CRM server.

    Areas Inspected:

    The BAPI in CRM does return data when doing testing via SE37.  Same parameter was used in both Web Dynpro application and SE37 by the way.

    The request/response of the RFC call did appear with data in the error log in the ST11 transaction after bumping up the trace level via the SMGW transaction in the CRM server.

    Also, we were able to see request/response of the RFC call with data between the EP and CRM servers at a TCP/IP level (packets) upon execution of the application via EP.

    In addition, the context of the UI controls in the Web Dynpro application seems to be mapping correctly to the context of the controller (input-to-input and output-to-output), which maps to the context of the adaptive RFC model.

    JCO connection via the Web Dynpro Content Administrator in the EP side seems to be working (enabled and with successful connection).


    Does anyone have any suggestion of how to resolve this issue?  Any other areas I may have not checked?  Thanks in advance.