The DDIC or Data dictionary plays an huge tremendous fantastic great role in what SAP does. The ABAP Dictionary centrally describes and manages globally defined data definitions used in the system. It describes tables, table keys, but also the table fields down to possible values. Search help and lock object, number ranges, the list is pretty endless. These articles will look like they are not very related to each other, yet they all describe the great DDIC.
The information that is showing on your screen is also held somewhere. Sometimes as a result from a calculation but mostly in very accessible transparent tables, which can be viewed or selected on from an ABAP report. These articles are about how to find the tables behind the fields.
The most popular way into the table search would usually be a screen field... Simply ask the end-user to point out which field is required on the screen, and take it from there: press F1 for help and get technical details via the "Tools" button.
You must have noticed that screen fields don't always lead to their physical tables directly. But there is a relation ! The developer at SAP does generally the same as you when creating an application.
The SQL trace is about tracing database activity, which can also be useful finding the origin of your data...
A runtime analysis may be easy, but an SQL trace should never be forgotten about. Tracing SQL steps is done for any transaction, report or even different transactions or reports. It records any actions in the database, in any (all) sessions (your sessions). It can also be used to "trace" only part of a transaction, by timing when to switch it on and off again. The great thing about the SQL trace is that is can be switched on when you expect a program to select data, and switched off again immediately afterwards, leaving you with a short trace on the tables you were searching for.
Use the performance tool to track down which transparent tables are selected on. A very straight forward way to find out which tables a SAP application is using is by running a runtime analysis. Part of the results of a runtime analysis is the tables hit-list. The transparent table (or pool table) you're looking for must be in this list ! Transaction
SE30) Runtime analysis is also highlighted on the articles on Performance.
Using runtime analysis aims at a full usage cycle, where the SQL trace can be switched on and off at any time. Since the listing of tables is a side product of Runtime analysis, you may need to look it up first. Just remember it is there, it is accurate and there is no way a program can select information without making the table part of the runtime analysis results.
Setting up some development tools that allow easy interrogation of system (data) resources...
The overviews from the "Tables and such"will prove to be useful but often incomplete. A report or application that has to be build and integrate with SAP often has to use the same tables and selections as done in SAP. Copying the SAP programming sources of selections might be a logical way of approach: but hard to do because of complexity. I have chosen a different approach: via the data dictionary to try and find out how data is stored. Thereby I avoid the often complicated SAP sources. A couple of guidelines:
Some data is not held on actual fields. E.g.:
Long texts are a bit tricky to find. Because a text field has no restriction in length, it is a bit of a challenge for database fields to hold a long text. They are held on a text-pool rather than a transparent table. There is a separate article on long texts on AbapcadabrA. Check (transparent) table
STXH for text headers.
In many cases the system holds possible values for a certain field, which can be set on the domain of the field. Linked to a check table or linked to Domain values Have a look at domain
EBSTYP as an example, this is the domain behind
EKKO-BSTYP, a single character field which holds the type of purchasing document. SAP only supports a predefined set of values for this field, making the way to store short descriptions with the possible field values very suitable for domain values. Go to transaction
SE11 and fill in
EBSTYP for the field Domain. On the tab Value range the possible values are listed, or (potentially) a check table is displayed.
A longtext or text is a bit of a special field when projected against a database. Normally, fields have a predefined type and length, text fields however have no length...
which is more than a bit awkward for a database. Hence SAP uses a text pool for all texts in the system, whether they apply to the documentation of a program, or as item text on a Purchase Order. This issue is about the setup of text fields, how to find them, manipulate them and understand the setup.
Looking for a text on a requisition ? Need the longtext of a material ? Standard SAP documents store their longtexts in the same tables..
If you want to fetch the longtext of a purchase order (header) you will find that the text-pool principle is used in standard applications as well. Now starting from the end user request, how do you find that long text !? To find it you will need the ID, Language, Object and Name (all 2b found in structure
THEAD. These values are available to you in table
STXH "SAPscript text file header".
What you should do and not do when implementing long texts
- Do Make use of the texts concept - even for your own developments.
- Don't Use text fields to store a field value you may need. Field values belong elsewhere.
- Do Use the concept of including texts. When texts are used inefficiently, a given text will be stored on the system many many times.
OTR texts or Online Text Repository texts are longtexts which are held in a centrally available storage location, accessible from SAP but also for e.g. BSP (Business Server Pages - the web) applications. OTS is about editing, maintenance and usage of these texts. Texts are cross-client workbench objects.
SAP's wide support for long texts is not reserved for SAP programs only. If you are planning to store long texts with your tables, you should do this exactly the same way SAP does... By using the ID, Language, Object and Name, you can identify your own texts and incorporate them in SAP's textpool. The ID can probably be reused from one of SAP's ID's. Use
LTXT for example. The Object should be created (as new), just to ensure you are not mixing up any other texts (and thus other applications).
An overview of functions that can be used to read, change, rename, create and delete texts...
Texts can be stored in a textpool (or textpools) in SAP. Several transactions can use the same way of storage when texts are involved. A series of function building blocks can be found in the function group
An overview of function modules in text manupilation:
Standard texts are not put on a transport by default, probably because these texts can be changed on any system. So should you enter them in every system ? It's up to you - but I can tell you my preference: use transports ! Just to get the initial version of your texts across all systems anyway. How to transport: the same way it was done in the middle-ages: run an unfancy little report called
RSTXTRAN and select your text (or texts). Follow it through and your transport will be created.
This article describes how to retrieve program documentation as text.
Program documentation can be maintained for each ABAP via the transaction
SM38, "program development". This text can be reproduced on the screen via a function building block:
Example: Retrieve documentation text for a program
Program documentation can be maintained for each ABAP via the transaction SM38, "program development". This text can be reproduced on the screen via a function building block:
Article predades the millenium bug... Barcode numbers can also be text-theme, here's how to allow SapScript to print barcoding. Printing a barcode in SapScript can be done via the layout set by basically doing the following: barcode printing is activated by selecting a barcode font, characters in the barcode font simply display vertical lines that build up the barcode. Finding out what font you can use for your printer will have to be done in SAP's way: output print controls. SAP supplies these print controls for a variety of printertypes, so try to find these first. An easy way to test your printer with specific print controls is creating a standard text and change / print it. For KYOCERA device types and HPLJ4 device types (HP laserjet 4 series) SAP supplies a standard text. The text
SAPSCRIPT-BARCODETEST can be used to either test or use as example for your own tests. Change and print the standard text from R/3 => Tools => Word processing => Standard text. The text ID is "ST", the language "D" or "E". If printing via standard text works, you can adapt your layout set for barcode printing.
The SAP HR module is the only module that still utilizes logical databases. For good reason: it has added value - mainly because of the timely fashion (information has a validity period) data is maintained in the system. Every bit of HR information (held in infotypes) has a start and an end date.
When you are using an organisational plan (transaction
PPOME), the hierarchy is locked into the relations table
HRP1001. This is not a very simple but straightforward setup where the relations in both directions are described. Here's how to access this information from your Abap.
What's a harvester ? It's a report that runs reports and gathers their output. This article describes a harvester report that runs a standard SAP report for a series of Legel persons. The ALV output is scooped up and the output of the combined report runs is reported or stored in a file. Complete turn-key example available !
For some of the infotypes, the system expects additional infotypes to be made available. Thus e.g. for infotype 0002 the additional infotype 3346 is expected to be available for English employees. If for some reason it is not, update modules (like RFC module
IDENTITY_MODIFY) may start to complain. Use report
RPUPAV00 to check and/or solve these missing infotypes errors. The report will check also the very country specific additional infotypes and report them as well as add them. Handy !
Article predades the millenium bug... Any bit of coding that is done repetitively can be set up in a macro, with
DEFINE .. END-OF-DEFINITION within any Abap coding source. This article is about another type of macro, which is much less well known. The Macro module or RMAC macro can be set up centrally on the system, so it can be called from anywhere.
Where test data is concerned, having a few dice can be a very handy feature. Throw them to determine which choice a simulated end user would have done. Or use them to decide whether the next record of test data you are creating is red, green or blue. Random numbers - as test system tooling.
Classification data (transaction
CL00 for the classification menu) is really data about data, which can be applied/used for many separate areas. It's available in many standard SAP elements such as the material master. So how to get to this information, when you need it in your report ?