Skip to Content

Bugs, Bugs, Bugs!

I ocassionally get the odd email regarding bugs, and development issues for SAP::Rfc for Perl (saprfc for Python, and SAP::Rfc for Ruby), and two days ago I got one that indicated that the handling of ABAP DEC type fields in a structure (for structured parameters or tables) was broken.

I thought this was strange, as this is a core kind of function that SAP::Rfc has handled for a number of years, but I wanted to look into it, as I have been known to introduce new features that break old ones before, :-).

The Test Case

My helpful tester (who will remain nameless, and does not fall into the category of “I have a friend who ….”), supplied me with a code sample, which I distilled down to:


use SAP::Rfc;

  1. connect to SAP

my $rfc = new SAP::Rfc( … );

  1. lookup interface definition

my $if = $rfc->discover(“RFC_READ_TABLE”);

  1. populate interface for call

  2. – we are reading the Number Range Object definition table

$if->QUERY_TABLE(‘TNRO’);

$if->OPTIONS( [“OBJECT LIKE ‘ARCHIVELNK%'”] );

  1. get auxillary helper structure definition

my $str = $rfc->structure(‘TNRO’);

  1. do the business

$rfc->callrfc($if);

  1. loop through each row and pass into

  2. helper structure to access field values

foreach my $row ($if->DATA()){

  $str->value($row);

 

  1. get the Number Range PERCENTAGE value

  warn “TNRO-PERCENTAGE: “.$str->OBJECT.” “.$str->PERCENTAGE.”\n”;

}

</pre>

</p>

RFC_READ_TABLE

RFC_READ_TABLE (as you may have guessed) is a Remote call enabled Function Module, for reading rows (and optionally, specific columns) from any given table in R/3. You can supply the function a TEXT like table representing the WHERE clause to specify what filtering on the SQL query you want. This Function Module has been available since goodness knows when (I would think at least back to 3.0x – probably earlier).

Running the Test

The above code gave me a result like:


TNRO-PERCENTAGE: ARCHIVELNK 2a.2

What!

– 2a.2 – doesn’t look like a percentage to me!

The actual PERCENTAGE value for the ARCHIVELNK number range object on my system (NW4 Test Drive 6.40 – 2004) is 10.0%, so there is something clearly wrong going on here.

Next stop was to fire up transaction SE37, and to debug the test directly. So start SE37, enter RFC_READ_TABLE, and then hit F8. Enter the parameters as follows:

QUERY_TABLE => TNRO

DELIMITER => “|”

OPTIONS table – enter one row as => OBJECT LIKE ‘ARCHIVELNK%’

And then press ALTSHIFTF7 for debug.

…..

  •   copy all relevant fields into DATA (output) table

      LOOP AT FIELDS_INT.

        IF FIELDS_INT-TYPE = ‘P’.

If all goes according to plan then you should get a situation like this (below).  Notice the field values that I have selected to display.

image

The Bug

What Now?

Well firstly – Phew – there isn’t a bug in SAP::Rfc. Secondly, I think that this should be fixed, as I would hate to see an Iconic tool such as RFC_READ_TABLE languish into history – any takers?

To report this post you need to login first.

8 Comments

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

  1. Craig Cmehil
    I think I’ll have to do everything I can to prevent moving to NetWeaver! RFC_READ_TABLE, although not release for customer use -> Yeah Whatever! They built it we use it! Come on they can’t do something to RFC_READ_TABLE.

    I’ll be the first to sign a petition to keep this little guy around!!!

    (0) 
  2. Mark Finnern
    Hi Piers,
    Thanks for your post. As it is a bug, did you log it as a problem in the Service Marketplace? http://service.sap.com
    Although I wish, not all SAP Developers are reading all SDN Weblogs. [Or at least not yet :-)]
    If I count correctly this is one bug, isn’t Bugs, Bugs, Bugs! as a title a bit strong here?
    Just wondering, Mark.
    P.S. As I wrote in a separate post, Service Marketplace is the place to report bugs.
    (0) 
    1. Craig Cmehil
      Hi Mark,

      I think it was a bit of a cry of alarm because it looks as though RFC_READ_TABLE might have been or maybe is on it’s way out.

      I don’t think Piers was reporting a bug issue in this case.

      Craig

      (0) 
    2. DJ Adams
      Hi Mark

      People learn as much from investigating things that *don’t* work as expected as from reading HOWTOs about things that *do* work. Perhaps more. And blogs are about expressing an interest, a passion for something.

      Combine those two things together, and it’s clear that this post, which I found very interesting (despite already having chatted to Piers about the issue earlier this week), is a classic example of that mix of interest and detail.

      In my years as an SAP hacker, I’ve learned more detail by debugging dodgy code than by attending courses or reading documentation. I for one welcome such posts.

      It’s not about whether it’s a bug or not; it’s not about whether a message was raised in OSS … it’s about learning, and sharing that learning. After all, this place is the SAP *Developer* Network, right?

      dj

      (0) 
  3. Thomas Jung
    Have you had a look at OSS 758278.  Not only does it fix some problems (Unicode related) with RFC_READ_TABLE, but it also adds new functionality.  Not bad for a function that isn’t offically support or maintained by SAP. 
    (0) 
  4. Piers Harding Post author
    Well – thank you all for your responses, although I do feel that the intention of the Blog entry was rather misconstrued.

    Firstly – Although I didn’t know for certain, I was fairly sure that RFC_READ_TABLE was an unsupported “feature” in R/3 – for this reason, and the fact that my contributions to SDN are in my spare time – it would not sit easily with me to report issues found in my spare time (extra curicular activities – call it what you will), through an OSS account that is “owned” by my employer, as you have to pay for that priviledge (how many people own their own personal support contract with SAP?) – no matter how retentive that may seem.

    Secondly – my main reason for the discussion was to reflect on a tool in R/3 that became outrageously successful in a completely unintended  way, and to prick peoples conciousnesses with the thought of what that would mean if it did indeed “languish into history”.  I had no intention of trying to sneak a bug in to the SAP support process, through some kind of back door.  If I personally had a problem with it – then it would be my itch, and I would have certainly scratched it, after all didn’t I take it to the point of putting a finger on the problem?  Rather, I, didn’t want to see a celebrated piece of software in the SAP Hackers armoury, disappear.

    Thirdly – hopefully to make it a bit more beneficial to the reader, I discussed the process of tracking down the problem – this seems to have been lost on some.

    If, after this explanation, the consensus is still that the blog is inappropriate, then I am more than happy for the entry to be withdrawn.

    Piers Harding.

    (0) 
    1. Mark Finnern
      Hi Piers, DJ and Craig,

      Yes I like the description on how you found the problem, others are profiting from it. Valuable content on SDN.

      But please also put yourself in my shoes. The fear is, that SDN will be used to expedite OSS problems. This is something I want to avoid. Also Craig’s comment: “I think, I’ll have to do everything I can to prevent moving to NetWeaver! …” does not help the cause.

      Therefore no I don’t want to take this post off, I agree with DJ that you can learn even more from problems than from successes.

      Hope you see the motivation behind my previous comment, Mark.

      (0) 

Leave a Reply