Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Read contents of SAP structures

Former Member
0 Kudos

Hi,

I am trying to provide the database of a SAPScript form. I already know all the DB_tables, but there is more - "fortunately", most of what I don't have - that is, all that is not a transparent table - are structures. Those structures are known in the ABAP_Dictionary, I can view them via se11, I just cannot access them yet.

I have started by declaring an internal table where to put my structure - PEKKO is the one I picked as a first example to experiment with. I know I can INCLUDE a structure into an internal table, but that didn't seem to work, there must be something our system does not support.

I found a rather old thread here explaining just that: http://scn.sap.com/thread/387026 - it is from 2007, so when it was possible to do that back then, I'm confident our system supports everything necessary to do that - it's about that old...

Well, it is not working yet: I have the syntax exactly like that example, just giving a specific field in the last paragraph of the code - and I have omitted that 'OCCURS 0' as ABAP was complaining about that, also. Now ABAP complains that the field PEKKO - ABAP is obviously interpreting that as a field - is not known although I have declared it as a structure.

Well, here is my code as it is now. Maybe someone can give me a hint here. Thanks in advance!

DATA:

      zfh_dd03l LIKE dd03l,

      fh_dd03l  LIKE STANDARD TABLE OF zfh_dd03l.

field-symbols <lfs_field>.

SELECT *

        FROM dd03l

        into table fh_dd03l

     where tabname = 'PEKKO'.

READ TABLE fh_dd03l INDEX 1

     into   zfh_dd03l.

     ASSIGN COMPONENT (zfh_dd03l-EMLIF) OF STRUCTURE PEKKO

     TO <lfs_field>.

    

     BREAK-POINT.

Best regards,

Sapperdapper

12 REPLIES 12

raymond_giuseppi
Active Contributor
0 Kudos

Your syntax

ASSIGN COMPONENT (zfh_dd03l-EMLIF) OF STRUCTURE PEKKO TO <lfs_field>.

is wrong, if there was a data structure with name PEKKO in your report (TABLES: PEKKO or DATA PEKKO TYPE PEKKO) a correct tructure would be ASSIGN COMPONENT 'EMLIF' OF STRUCTURE PEKKO TO <fs>.

But here you have a record of type structure zfh_dd03l (dd03l.) which contains definition of field

Your statement has no chance to be correct.

Also structure are only defintion of container for data, not container, they don't carry any data per se as database file records. The program must define a field (data) with those structure, changing or not the name, and fill the data using Abap statements from select to calculation.

For your example, look at form lesen_beleg_lp in include LEINMF0M

Regards,

Raymond

former_member193464
Contributor
0 Kudos

you can not use DDIC structure in assign component without defining them in your own program...and the syntax to assign component is like this:

ASSIGN COMPONENT 'EMILF' OF STRUCTURE PEKKO TO <lfs_field>.

kesavadas_thekkillath
Active Contributor
0 Kudos

Adding to Raymond's comment, the below code will correct it.

data:wf_ref type ref to data,

         lv_tabname type tabname.

lv_tabname = 'PEKKO'.

create data wf_ref type (lv_tabname).

assign wf_ref->* to <fs_wa>.

READ TABLE fh_dd03l INDEX 1

     into   zfh_dd03l.

ASSIGN COMPONENT (zfh_dd03l-EMLIF) OF STRUCTURE <fs_wa> TO <lfs_field>.

0 Kudos

Hi,

thanks for helping! I will try.

@ Raymond

You are right, that's what I have been thinking all along - structures cannot contain data per se, they must be filled - the "easiest" way would thus be if I could dynamically query how and using which DB_tables a given structure is filled and then directly access those. But up to now, I haven't yet found out how to see where a structure takes its data from, not even manually. I can view the structures in se11 all right, but neither a double-click on the fields nor the tab "Input help" gets me anywhere as often, there is no input help for fields - well, none is mentioned.

The "environment analysis" also does not lead anywhere - for instance, for the structure PEKKO it lists but two check_tables - but neither in T001W nor in TPRG will you find, for instance, the vendor_nr that goes into the field EMLIF.

Best regards,

Sapperdapper

0 Kudos

Hi,

it seems to be working - at least there is no more syntax error and I can run the code.

It's just not delivering any data - without, however, displaying that icon that indicates whenever ABAP does not know a field_name. So I assume that the structure does not initially contain anything - just as I thought, actually, it is filled at some point. I assume that is done in the very first part of the associated PrintProgram so that when the layout for that form is accessed and the structure names are touched upon, these structures do contain data.

Thanks a lot!

Best regards,

Sapperdapper

0 Kudos

Hi,

I am thinking: My task involves, among others, both the PrintPrograms associated with SAPScript_forms and the issue of structures.

I have noticed that in some (probably and hopefully in most) PrintPrograms, there is very near the beginning a >TABLES:< statement listing all elements used - there are several more in different parts of the program, but it's always this keyword. The >TABLES< keyword, however, can declare both DB_tables and structures - the latter being filled at some point from the DB_tables.

The critical question is thus, are the structures independent of the DB_tables declared just there - additional info - or are the structures declared in the PP filled from the DB_tables in the PP?

In the latter case - I assume that is the case, I will try to establish that by browsing a few PPs - I don't need the structures since I can get all the data using only the DB_tables. That, of course, would have various advantages since DB_tables are also much easier to link - I can (find out how and) do that dynamically .

Best regards,

Sapperdapper

0 Kudos

The main objective of this TABLES statement is the exchange of data between dynpro and program (defining an interface work areas) , and is not much connected to the database

The statement TABLES is required for exchanging data between screen fields that were defined in a program screen when transferring from the ABAP Dictionary and the ABAP program. For the screen event PBO, the content of the table work area is transferred to identically named screen fields; for PAI, the system adopts the data from identically named screen fields.

Many SAP programs use some structures to contain main data during interactive transactions.

Regards,

Raymond

0 Kudos

Hi Raymond,

thanks! I don't know why, but, just as often as not, the F1_help which you have, I guess, quoted here does not work on my system.

I think I read in a manual that the keyword TABLES was somehow important for defining the entirety of tables that could be used when designing a document. I have also read what the TABLES statement does - and seen it in a tutorial - but I did not conclude that it might not be what I need to look at... I will read it again, but from what you say, I guess it's not that critical. Those structures defined in the TABLES part can be both DB_tables and SAP_structures, but if, as you say, those structures are just "containers" for the transferring of data between dynpro - the form, I imagine - and the PrintProgram, I might be able to do without.

You see, what I'm trying to achieve is to not have to actually execute the PrintProgram or copy and edit it to make my own - that would make the whole thing specific instead of generic as, acc. to TNAPR, there are 358 PrintPrograms associated with different forms.

I guess the next necessary step in the whole thing is getting an example with real data in it so I can compare that to what I can already provide using the code I have. Then I can judge whether I will get there without the PrintPrograms or not.

Best regards,

Sapperdapper

0 Kudos

F1 should work everywhere. If not, use transaction ABAPDOCU.

Structure is just a group of variables, nothing more than a placeholder. They can be declared in dictionary or in the program, doesn't matter. Plain put, TABLES just declares a structure with the same name and the same fields as a database table. You can also declare the same thing as a structure using DATA. Potato/potahto. As correctly pointed out above, TABLES is more relevant in the screen processing.

SAPScript is an arcane technology that at this point is just not worth learning in depth, I think. If you see that data is not filed in as expected, quite honestly, it might be just easier to do a user exit in the form (look it up, it's very funky in SAPScript) and be done with it.

And convert it to Smartform or PDF as soon as possible. What kind of document is this SAPScript for? PEKKO - I'm guessing either a goods movement document or purchase order. For both it's possible to do at least a Smartform. SAPScript is just pain in the back.

0 Kudos

Hi Jelena,

about structures: I guessed so much, I just wasn't certain. So, if I understand you correctly, structures usually mirror DB_tables. The thing is, the names are not exactly equal - I guess they cannot be - so I cannot tell exactly, in a program, which DB_table(s) the structure PEKKO, for instance, does mirror (it was just an example, but you're right, it is for a PO). Well, I can tell exactly whether I need the structures or not once I have a specific example.

Maybe you can help me there: I don't know much about SAPScript and, as you say, it is not worth learning in depth - I don't have the time to do that right now, either - but right now, it is very relevant for me to get one example from that world - one is enough for the moment, no matter which, it's just a "Proof_of_concept".

That conversion into a SmartForm - someone else proposed that to me as well and it seems a good idea, the GUI for SmartForms seems to be a lot more comfortable. I just need a form to start with - I've looked at quite some listed in that tree-structure you reach using Tcode SE71, but I can't yet figure out how to actually print one of those - with data, not just the block-layout. I've also tried importing one of those into SmartForms, but that asks me for a xml file which I don't have yet.

You see, I already have a method of getting data, but I need a specific sample to judge inhowfar I can get all the necessary data using that method. That is two things - it is a test that I have to pass and the necessary next step in my process.

Thanks a lot!

Best regards,

Sapperdapper

P.S.: Well, not quite regardless which - I'm not sure about that address-example I find in a tutorial, printing addresses en-masse is not something you do often, but it does definitely not have to be much more than that. Any kind of order confirmation, account statement or stuff will probably do.

P.S.: Ok, I'll forget about those forms given in SE71 for now. I'll just search online for some example or tutorial I can follow to build my own with only masterdata - data taken from the DB_tables as it is, no calculations - so I can use the method I have for now.

0 Kudos

Structures are not more related to the DB tables than a single variable definition. In standard SAP though in many cases (e.g. user exits) you'll find that structures are declared with the same (or very similar) fields as DB tables. And when declared with TABLES, structures have the same exact fields as the DB table. I'm guessing it just makes both SAP and customer's life easier and also allows to use MOVE-CORRESPONDING safely. But I also guess with HANA this will have to change since the cost of dragging lots of data around will increase (but it's another story).

Data in the structures is also not directly related to the DB tables. You'd have to search in the code to find out where exactly the data comes from. Again, in standard SAP you're likely to find that, say, XVBAP holds the current sales order item data. But there is really no guarantee.

As you see, structure is just a definition. You need to analyze the code (use Search or where-used) to find where the data comes from.

Your initial question was just about the structures, but, re-reading the whole post, not sure I understand very well what you're trying to do exactly. For every form (SAPScript or Smartform) there are two pieces - the form itself and the print program (or rather 'output processing' program). You need to have the field in the form and this field needs to be filled in with some data. The later can be done either in the program or in the form itself. For SAPScripts here is an old thread on how to call a routine from the form.

0 Kudos

Hi Jelena,

thanks a lot! Your answer already helps me. That is not my primary focus right now, but in the medium run, I'll have to deal with the structures-issue, too.

The overall goal I'm trying to achieve is to provide the data that was used to build a SAPScript_form, without the layout. I have an alternative tool to build forms and now I need the data that was used to build one using SAPScript_forms.

The DB_tables (and fields) used, if any, I can get from the layout and I can access them. I can also get some more things, possibly some layout-related rules governing what pieces of information appear under what circumstances. I can also get from there the names of any structures used.

At that point (with the structures), I'll have to somehow deal with the associated PrintProgram to know how those are filled. I can find that using table TNAPR, provided it is there - with custom-made forms, that is not certain.

I might be able to backtrace that process (of filling in the data) and access the original DB_tables, but I guess redoing the process would be the safer method since there might also be calculations in the structures. I don't yet quite know how to do that, I don't want to end up having to modify/ copy any of an unknown number of PrintPrograms...

Well, that's not my primary concern right now. Once I have reached a point where this becomes relevant again (sometime next week), I will have a look and I'll be back here.

Best regards,

Sapperdapper