One of the most common tasks, where the technical and functional lines blur, is detailing
from where a specific value or even a whole record comes. This task often occurs while
writing a specification. Often the functional analyst will expect a technical analyst can
easily decipher where the information is stored based on a label name, while a technical
analyst is unwilling to start any development without very detailed information about
where he needs to pull the information from the database. The truth is this information
can be done by either analyst, as long as a firm starting point is recognized.
When starting an analysis of where the data resides, the starting point is always going
to be the same – the business process where the value is visible. For instance, if you
want the sales order line item rejection reason to be passed in an interface, write down
the process path for a user to see this value. If you want a value on a current report to
be copied on to another report, show screenshots up to that value. The simple idea is, if
the value is visible in the system where a normal user might access it, there should be
code attached which tells us how to retrieve it similarly for another program.
However, it should be noted that this is the step that only a functional can do. If this is
not documented on a spec, do not expect that any developer can move forward with
your development. Consider this for two reasons – first, the developer does not know
the process. While some technical analysts do have some experience with business
process, it is in no way a guarantee, especially as the company takes on new consultants.
Do not assume that any developer shares the knowledge you might take for granted.
Secondly, some terms have become very generic within SAP, to the point describing the
name does not indicate where it should be pulled from. For instance, order can mean
several things, from a VA02 sales order, to an IW32 Service order. Be specific.
To start your analysis, once you have found the location where this field value can be
seen, one of the simplest, but effective things you can try is to use F1 on the field to
retrieve technical information.
Doing this can grant access to several pieces of information useful to a technical analyst: once the performance assistance screen pops up, to get the technical information, click the icon on the toolbar that looks like a hammer and a wrench.
The technical information screen consists of 4 sections, with the “Field Data” section
being the most important to your task. This area contains field names, table names,
and data elements (types). In some cases, your search can end here. If the label for
the table field is “Transparent Table”, this represents a direct connection to the table – For
instance, a sales order number to table VBAK, field VBELN. This is the best-case
scenario, but it is still a good idea to document where to see the field, as a developer
may need to determine what key fields are used to pull back the table values by using
debug or trace.
However, in other cases, the label is “Struct” or Structure. This value does not
represent an actual database table where the data is stored, but instead is a temporary
table used to store data for the duration of the transaction, and then discarded. It is
commonly used when stitching together information from multiple database tables. In
these cases, it is better to give a developer the information to see this field than it is to
give them a copy of the information stored in this screen. However, both pieces of
information together can be a useful tool to find the actual database table.
Taking it further
So, you documented where a user can see the field value, but you got a field structure
instead of a transparent table, and you would like to track down further where this
information is (possibly because you might want to do an SE16 table dump in the
future). Alternatively, you find the direct values, but you need to know where the text
labels for those values are? Here are a couple other thoughts on table searching that
might help you with this.
First, start with what you know. When looking for a new field, if you find it on a screen
with a field you had previous looked up, chances are the two fields are in the same table.
Also, the field name you find in the technical information tends to be the exact
same in the database table as it was in the structure. By looking up the table using
transaction SE11 (ABAP Dictionary), and searching for the field, often you can confirm
whether the two fields exist on the same record. If you don’t find the field in the same
table, often the field is in a similarly named table. For instance, sales order partner info
is not stored in table VBAP along with the material, but it is found in table VBPA.
Another approach using SE11 is to use the data element from the structure’s technical
information, to review all database tables that have a field of that type. This can work if
the field is unique enough. All you need to do is place the value you see in data element
in the SE11 selection field (data type), and click the where-used button . A new popup
screen will show, allowing multiple choices of searching; choose only the “Table
fields” checkbox. If the results of the search are small enough, you might be able to
determine the right table by review name and use of the table.
Final options include either running an SQL trace or debugging the program. Usually
these are technical analyst methods, and can be requested as part of the co-operation
between teams, but with a little training and understanding, these can be more tools to
add to your arsenal. SQL traces can be used to tell you every table you used while
running through a process, as well as the criteria used to access them, but they
sometimes overload the tracer with too much info and give the user too many leads to
investigate, without confirming the source of the value. Debugging is much more
precise, but can be much more complex to understand and, in the case of standard SAP
programming, very time consuming.
The one thing the functional analyst has that the technical analyst does not, is a clear vision of what the user expects to see. The better that vision is communicated, the easier the collaboration becomes between the teams, and less time is wasted on failed tests and mistaken assumptions.