Specs writing: finding where a field value is stored

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.

The Essentials

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.

Conclusion 

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.