Skip to Content
Well we are off and developing now. The first problem we obviously encountered is the fact that our WebAS is a separate system from R/3. Writing our applications isn’t going to as easy as just coding some SQL. But as you will see, they aren’t going to be that much more complicated either.

RFCs
Having been around the SAP Universe for a few years, the idea of calling a SAP function module remotely (or RFC) wasn’t a new topic at all. I would imagine that most ABAPers know about the magic radio button labeled Remote-enabled module on the Function Builder Attributes tab. This wonderful option is about all it takes to expose your function to any tool capable of communicating with SAP. The only other thing to keep in mind is to mark all your parameters as Pass by Value. Even at that you don’t have to remember. The editor will yell at you if you forget. Also keep in mind that what SAP calls a BAPI is really just an RFC. BAPIs are linked to a business object and usually have additional documentation, but from a technical standpoint they are just plain RFCs.

Example Call
RFCs are incredibly easy to call from ABAP. All you have to do is add the Destination parameter to the call. For anyone who might never have seen an RFC in use here you go:

call function 'Z_E_RFC_FIELD_DESCRIPTINS' destination 'DEV' exporting rollname = 'CVFLAG' language = sy-langu importing ddtext = currv_desc.

Wow this is all so incredibly easy. What in the world am I going to write about? Wait – don’t worry. It doesn’t take long to run into the first problem.

First Problem
It is easy to call an RFC from within an R/3 system. You will have all the data elements and structures necessary to define the importing and exporting parameters. Oops – I knew we were missing something! Our standalone WebAS didn’t have most of these same data elements and structures since it was the technology stack only. And it certainly didn’t have any customer created elements unless we copied them over to the WebAS. Of course we could always create all the missing elements by hand, but as developers we have a long tradition of work avoidance to live up to. It would be great if SAP had a tool that would read the exporting/importing parameters on an RFC and generate the necessary data statements for us.

BAPI Browser
Well we were in luck. There is just such a tool. It is called the BAPI Browser.
image
This great little tool can be accessed from within SE80. If you are editing a BSP application and are in a Page or View, you can launch the BAPI Browser from the menu via Goto -> Bapi Browser or Ctrl+Shift+F1. You can then browse though a list of BAPIs for an RFC destination (hence the name) or do a Direct Entry search for any RFC enabled function. As you can see from my screen shot you get all the data declarations you need in addition to a sample call of the function module. The main draw back is that if the function interface changes, you have to rerun the BAPI Browser and change the declarations manually. In my next weblog I will discuss using XML to get around this little problem. Also if anyone from SAP is reading this, I have a suggestion for the BAPI Browser: I would like to be able to launch it from anywhere in SE80, not just BSP coding. Quite often I am coding inside a Model or Application class and that is where I need to call my BAPI. However I have to switch back to a BSP View or Page to activate the tool.

Elements Delivered
I should note that SAP actually delivered a lot of the most important data elements with one of the early support packages. Even though this is a technology system only, you can now find such elements as MATNR (Material Number) and WERKS_D (plant) just to name a few. This makes your work easier but there are still plenty of elements missing in order to need the BAPI Browser.

System Exceptions
Now that we are off and calling our RFCs everything is fine, right. Well until the calling system isn’t available, or the RFC destination is setup wrong, or the user isn’t authorized for the activity, or any other of a number of things that might go wrong. Normally these activities will create a nice short dump. However from a BSP page, the short dump doesn’t really make for the best user experience. Wouldn’t it be nice to be able to catch all of these System-type exceptions? Well you can. Just look at the following example.

data: msg_text(80) type c. call function 'Z_E_RFC_QUERY_UG_AUTH_CHECK' destination rfcdest exceptions communication_failure = 1 message msg_text system_failure = 2 message msg_text not_authorized = 3.

As you can see here I have added two special exceptions that aren’t implicitly declared by the function itself. COMMUNICATION_FAILURE and SYSTEM_FAILURE are two exceptions that are automatically available to any function that is being called remotely. All of the types of problems I mentioned before will be trapped by these exceptions. The details of the error will be placed into a variable that you declare. In my example this is msg_test. I find that it is better to stop processing but display the details from this message back to the user rather than show the generate message.

Dynamic Selection of Destinations
I have just one final learning that I wanted to share before I close out this weblog. Overtime we found that it was becoming a maintenance nightmare to maintain RFC Destinations. You either end up creating a RFC destination for each application in each system or you end up hard coding destinations. Neither option ends up being very flexible. We decided to create a table where we could hold the name of the function module and the associated RFC destination. This way we could easily have different destinations maintained in each system in our landscape. The following is what our usual RFC call actually looks like:

select single rfcdest from zes_rfc_dest into rfcdest where name = 'Z_E_RFC_DOC_SEARCH'. call function 'Z_E_RFC_DOC_SEARCH' destination rfcdest exceptions communication_failure = 1 message msg_text system_failure = 2 message msg_text not_authorized = 3.

Closing
I hope that everyone enjoyed this first look at RFCs. As I have already hinted, my next weblog will still look at RFC and how we can use XML with them.

To report this post you need to login first.

33 Comments

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

  1. Alexander Häußler
    this is an excellent series of weblogs. I am rally interessted in this XML and RFC part. This sounds like something very useful.
    Also the idea of the rfc_dest table is very good.

    I hope it doesn’t take you long to write the next part.

    ALEX

    (0) 
    1. Thomas Jung
      The next part of the RFC weblog that deals with XML has been posted.  I hope that I didn’t leave you waiting too long.  Thanks
      /people/thomas.jung3/blog/2004/06/24/bsp-150-a-developer146s-journal-part-v-xml-for-rfcs
      (0) 
  2. Alexander Häußler
    this is an excellent series of weblogs. I am rally interessted in this XML and RFC part. This sounds like something very useful.
    Also the idea of the rfc_dest table is very good.

    I hope it doesn’t take you long to write the next part.

    ALEX

    (0) 
    1. Thomas Jung
      The next part of the RFC weblog that deals with XML has been posted.  I hope that I didn’t leave you waiting too long.  Thanks
      /people/thomas.jung3/blog/2004/06/24/bsp-150-a-developer146s-journal-part-v-xml-for-rfcs
      (0) 
  3. Alexander Häußler
    this is an excellent series of weblogs. I am rally interessted in this XML and RFC part. This sounds like something very useful.
    Also the idea of the rfc_dest table is very good.

    I hope it doesn’t take you long to write the next part.

    ALEX

    (0) 
    1. Thomas Jung
      The next part of the RFC weblog that deals with XML has been posted.  I hope that I didn’t leave you waiting too long.  Thanks
      /people/thomas.jung3/blog/2004/06/24/bsp-150-a-developer146s-journal-part-v-xml-for-rfcs
      (0) 
  4. Craig Cmehil
    Where were you when I was trying to figure this out before.

    I think I’ll need to abandon my weblog since you’ve pretty much said in this what I was writing in my next one 😉

    Maybe you’ll also anywer our still lurking issues…how to do a remote call to a system where a FM doesn’t exist but still get the data???

    (0) 
      1. Craig Cmehil
        I will probably still continue the thread, perhaps not as quickly though – besides it gives me an excuse to visit SDN more 😉

        (0) 
    1. Thomas Jung
      I agree that you should still share your experiences.  It is just as interesting to see if we encountered some of the same opportunies.

      Actually I do have a suggestion for your No FM – still get data problem.  It involves distributing one RFC. This RFC imports two parameters – an XML byte string and a table full of ABAP code.  It returns one parameter – an XML byte string.  Inside the function you use GENERATE SUBROUTINE POOL.  All of this would have its advantages and disadvantages.  If there is interest, perhaps I could write a weblog to go into more details.  This comment area isn’t the easiest way to explain something this complex. 

      (0) 
      1. Craig Cmehil
        That would some interesting to see, in the next web log I write in my little series I will be covering how we tried to dynamically generate ABAP code in the remote system and the problems we had writing a FM and distributing it to every system.

        So if you find the time I’d like to see your XML methods.

        (0) 
  5. Craig Cmehil
    Where were you when I was trying to figure this out before.

    I think I’ll need to abandon my weblog since you’ve pretty much said in this what I was writing in my next one 😉

    Maybe you’ll also anywer our still lurking issues…how to do a remote call to a system where a FM doesn’t exist but still get the data???

    (0) 
      1. Craig Cmehil
        I will probably still continue the thread, perhaps not as quickly though – besides it gives me an excuse to visit SDN more 😉

        (0) 
    1. Thomas Jung
      I agree that you should still share your experiences.  It is just as interesting to see if we encountered some of the same opportunies.

      Actually I do have a suggestion for your No FM – still get data problem.  It involves distributing one RFC. This RFC imports two parameters – an XML byte string and a table full of ABAP code.  It returns one parameter – an XML byte string.  Inside the function you use GENERATE SUBROUTINE POOL.  All of this would have its advantages and disadvantages.  If there is interest, perhaps I could write a weblog to go into more details.  This comment area isn’t the easiest way to explain something this complex. 

      (0) 
      1. Craig Cmehil
        That would some interesting to see, in the next web log I write in my little series I will be covering how we tried to dynamically generate ABAP code in the remote system and the problems we had writing a FM and distributing it to every system.

        So if you find the time I’d like to see your XML methods.

        (0) 
  6. Craig Cmehil
    Where were you when I was trying to figure this out before.

    I think I’ll need to abandon my weblog since you’ve pretty much said in this what I was writing in my next one 😉

    Maybe you’ll also anywer our still lurking issues…how to do a remote call to a system where a FM doesn’t exist but still get the data???

    (0) 
      1. Craig Cmehil
        I will probably still continue the thread, perhaps not as quickly though – besides it gives me an excuse to visit SDN more 😉

        (0) 
    1. Thomas Jung
      I agree that you should still share your experiences.  It is just as interesting to see if we encountered some of the same opportunies.

      Actually I do have a suggestion for your No FM – still get data problem.  It involves distributing one RFC. This RFC imports two parameters – an XML byte string and a table full of ABAP code.  It returns one parameter – an XML byte string.  Inside the function you use GENERATE SUBROUTINE POOL.  All of this would have its advantages and disadvantages.  If there is interest, perhaps I could write a weblog to go into more details.  This comment area isn’t the easiest way to explain something this complex. 

      (0) 
      1. Craig Cmehil
        That would some interesting to see, in the next web log I write in my little series I will be covering how we tried to dynamically generate ABAP code in the remote system and the problems we had writing a FM and distributing it to every system.

        So if you find the time I’d like to see your XML methods.

        (0) 
  7. Boris Bermejo
    Hi Thomas!

    Thanks for the weblog, you know how to make a call to a external bapi from a webdynpro (WDA) implemented in a WAS without the necessary structures.

    Thanks.

    (0) 
    1. Thomas Jung Post author
      Well you can use everything shown here.  You can still call the BAPI browser from any BSP application and then just cut and paste the generated code into your WDA method.
      (0) 
      1. Alejandro Bindi
        I’ve been debugging a little and found a way to use the BAPI browser without having to call it from BSP editing: just call the function module BAPI_DIALOG from SE37! That’s it.
        You can also use the report WDY_BAPI_BROWSER which does just that, previously checking authorizations.

        Regards

        (0) 
      2. Alejandro Bindi
        Warning: my previous comment is still valid, but I found out that “Direct Entry” functionality dumps when the function was called this way. The browsing of BAPIs for each system work fine though.
        (0) 
  8. Boris Bermejo
    Hi Thomas!

    Thanks for the weblog, you know how to make a call to a external bapi from a webdynpro (WDA) implemented in a WAS without the necessary structures.

    Thanks.

    (0) 
    1. Thomas Jung Post author
      Well you can use everything shown here.  You can still call the BAPI browser from any BSP application and then just cut and paste the generated code into your WDA method.
      (0) 
      1. Alejandro Bindi
        I’ve been debugging a little and found a way to use the BAPI browser without having to call it from BSP editing: just call the function module BAPI_DIALOG from SE37! That’s it.
        You can also use the report WDY_BAPI_BROWSER which does just that, previously checking authorizations.

        Regards

        (0) 
      2. Alejandro Bindi
        Warning: my previous comment is still valid, but I found out that “Direct Entry” functionality dumps when the function was called this way. The browsing of BAPIs for each system work fine though.
        (0) 
  9. Boris Bermejo
    Hi Thomas!

    Thanks for the weblog, you know how to make a call to a external bapi from a webdynpro (WDA) implemented in a WAS without the necessary structures.

    Thanks.

    (0) 
    1. Thomas Jung Post author
      Well you can use everything shown here.  You can still call the BAPI browser from any BSP application and then just cut and paste the generated code into your WDA method.
      (0) 
      1. Alejandro Bindi
        I’ve been debugging a little and found a way to use the BAPI browser without having to call it from BSP editing: just call the function module BAPI_DIALOG from SE37! That’s it.
        You can also use the report WDY_BAPI_BROWSER which does just that, previously checking authorizations.

        Regards

        (0) 
      2. Alejandro Bindi
        Warning: my previous comment is still valid, but I found out that “Direct Entry” functionality dumps when the function was called this way. The browsing of BAPIs for each system work fine though.
        (0) 

Leave a Reply