Those of you not familiar with the tale of Hansel and Gretel can find a quick summary here:
http://en.wikipedia.org/wiki/Hansel_and_Gretel
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 ...
