Skip to Content

Without bread-crumbs, Hansel and Gretel meet the WWW (Wicked Witch of Web-Services)

Those of you not familiar with the tale of Hansel and Gretel can find a quick summary here:


As mentioned in this summary, Hansel and Gretel meet the wicked witch because they couldn’t find the bread-crumbs they had left to find their way out of the woods … the birds had eaten the bread-crumbs.


If SAP developers don’t want to meet the WWW (Wicked Witch of Web-Services), they also need their bread-crumbs … in particular, indices which permit them to write methods in back-end proxy classes that retrieve data as quickly possible … certainly not by full-table scans.  These indices are like bread-crumbs because they allow developers to start at one database table and from there, efficiently hop from table to table to rapdily build the data they need.


So, as I mentioned in a Tech Ed SDN Day preseantation a few years back, even if the “WWW” wasn’t out there waiting to bake them up and eat them … i.e. even if SAP had never committed to SOA …,  SAP developers would still benefit from traditional function group modules or ABAP OO methods that allowed them to follow index bread-crumbs to do certain kinds of efficient data-retrievals. 


And, as I also mentioned in the same presentation, by getting traditional SAP developers to think in terms of such function modules or OO methods, one is really preparing these developers to think in terms of back-end services that support the needs of SOA. 


Here is an interesting example of this concept which has arisen in the context of some custom work I’m doing at my current client.


The user wants a long-term planning report that reports labor and material costs for a set of matnrs (all or some) that belong to a particular planning scenario (plscn) or requirements plan (pbdnr) in the PLAF table.


So, let’s see if SAP has provided the bread-crumbs (indicees) for Hansel and Gretel to build this report.


Well, in my ECC 6 version of the PLAF table, there’s no SAP-delivered index on plscn and no SAP-delivered index on pbdnr.  Hmm … does SAP actually WANT Hansel and Gretel to meet the “WWW” by invoking full table scans from the selection screen of the desired report (the one where a planning scenario or requirements plan is entered?)


OK, so Hansel and Gretel ask their local DBA (database baker) to drop the necessary bread-crumbs by indexing plscn and pbdnr in PLAF, thereby avoiding one ecounter with the “WWW”.


But are they out of the woods yet?


Unfortunately not.


Because in order to pick up labor hours from rows in PLPO, Hansel and Gretel must take the plnum’s that they found in PLAF for their given plscn or pbdnr and go to KBED to pick up the plnnrs for the routings in PLPO.


And upon frantically searching for the right bread-crumbs in KBED, Hansel and Gretel find that there’s no SAP-delivered index on plnum in KBED. 


Whoops!  Hansel and Gretel will soon be safely tucked away in the stomach of the WWW unless, of course, they again ask their local database baker to drop the necessary bread-crumb for them … a plnum index on KBED.


What’s the moral of our fairy-tale, you may ask?


Well, there are at least three, actually.


The first moral has to do with the question of whether SAP didn’t bother to index plscn (and pbdnr) in PLAF and plnum in KBED simply because SAP’s own developers and their privileged “premium partner” friends know that there’s a much better way to get PLPO data for a given plscn or pbdnr … Hansel and Gretel are just too young and stupid to know it.  And if that’s the case, the moral goes back to a point I made in the same SDN presentation – there should be a “rapid-retrieval” library where Hansel and Gretel can find what they need without having to ask the baker for new bread-crumbs (or pay expensive consulting dollars to find out …)


The second moral has to do with the original point I made at the beginning of this post … by thinking about seemingly traditional problems like the one I just outlined, pre-6.0 developers are already starting to think like they have to think in order to become developers of efficient back-end services in an SOA environment.


The third moral is … well, I won’t go there myself … but I am curious to see if anyone else might care to suggest what it is in a reply to this post  …

You must be Logged on to comment or reply to a post.
  • I should add that there is a plnnr column in PLAF
    – but it’s empty after standard transactions are used to set up a scenario and its underlying detail.

    This indicates one of three things:

    1) someone at SAP is thinking about being able to drive directly from PLAF to PLPO;

    2) someone at SAP once thought about this but thought better of it;

    3) you can get plnnrs in PLAF via a config setting that this client doesn’t happen to have set.

    But regardless of which one of these alternatives is the case, the point is that SAP could do a lot more to move the 4.6c/4.7 base to ECC 6 and SOA by looking to see how it can clarify and improve the back-end to support this migration.

    Because judging from the lack of delivered bread-crumbs from PLAF to KBED and KBED to PLPO, and from the apparent confusion over whether plnnr should link PLAF and PLPO directly, it doesn’t appear that SAP has spent all that much time thinking about how to improve back-end support for efficient data retrievals in the SOA environment.

    As I used to dicuss with Mark, this would be a perfect place for SDN to make a serious contribution (since so many different SDN users know where so many of the bread-crumbs are), but in my opinion, the collected wisdom of SDN’ers would have to be put in somethng more “offical” than an SCN Wiki.

  • to continue the story.. well, no.. it seems that in the same forest some less known characters were wondering around, in another story, looking for something a little different.

    Laying out the bread-crumbs takes someone a lot of work. And SAP’s not doing it for us. Having the right indexes is great, but keeping them up-to-date costs performance at every update.

    I don’t really see a problem that this kind of fine-grained service is not delivered standard by SAP. If they did, the ECC could become a lot more expensive. When you buy a standard package like SAP, you don’t buy a competitive advantage in IT. That’s what you should get from the high-priced consultants like ourselves, no?

    • Hi Peter –

      Not sure of who Jacob, Peter, and Giselle are, but I can tell you it made me think of the French classic “Jules et Jim” right away …

      Anyway, I am glad to see we are in profound socio-political, economic, and technical disagreement on this matter – maybe that disagreement will lead to some interesting discussion to which others will want to add (Thorsten ?????)

      Our socio-political disagreement is over the question of whether SAP should feel obliged to deliver the bread-crumbs.  The reason I say that SAP should feel obliged is because SAP is a software vendor, and inasmuch as the product of a software vendor is automation, any software vendor should be obliged to show clients that it know how to automate its product, i.e. that it knows how to “automate automation”.  Otherwise, why should a customer of the vendor trust the software vendor to help automate the customer’s product?  So in my opinion, SAP should delivery a library of “bread-crumbs”, even if it doesn’t make an actual service out of each trail of bread-crumbs in the library.

      Our economic disagreement is whether its “OK” for the knowledge gap to be filled by the “high-priced” consultants whom you mention.  Here again, my opinion is that such consultants should compete with one another on much more meaningful grounds than which trails of bread-crumbs they happen to know.  For SAP technical consultants to compete on which trails of bread-crumbs they know is a little like mechanical or civil engineers competing on what integrals they happen to remember without looking them up.  Just like these engineers can consult dozens of different libraries to look up integrals, SAP technical consultants should have look-up libraries for bread-crumbs, so they can spend their time doing more important work for their customers.  Let the consultants compete on their value-added services, not on what “integrals” they happen to know.

      Finally, our technical diagreement is three-fold.  In the first place, I agree with you that a customer must be careful about over-indexing highly volatile data, e.g. EKxx data, xSEG data, etc.  But how many planning scenarios/requirements plans is a customer really going to have, and how often are these going to be updated, and how often would a customer NOT be satisfied with a background create/update run of a scenario or plan?

      In the second place, I disagree that encapsulating the PLAF/KBED/PLPO bread-crumbs would result in too “fine-grained” a service.  In my opion, such an encapsulation would be at a level of granularity sorely needed in the SAP world – another example would getting into native bseg on profit center or cost center using the “AW” bread-crumbs that SAP makes available.

      Finally, in the third place, it is long past time for SAP to in ABAP SQL what many databases do aleady – allow specification of certain indices for “deferred update”.  The technology/techniques to do this has been around since at least the early 80’s, so there’s really no excuse for SAP not to include this feature in ABAP SQL except that SAP is too busy trying to keep up with the desire of the IT “lumpenproletariat” for new bells and whistles every year …

      Anyway, thanks again for taking the time to respond.

      Best regards