Peeking inside a variant
Tuesday, October 24, 2006
Recently I had to work on a program, which should run, among other ABAP programs, in a background job. The challenge was that this program was supposed to figure out which dates were used by the program that is a preceding step in the same job. Since the programs run using the same variant name (content might be changed by the users but the name stays the same), the task here really is to figure out what’s inside the variant.
It wasn’t quite difficult to find a function module that reads the variant - RS_VARIANT_CONTENTS (I found it on the always useful list on the ERPGenie website) but here are some more details on how this FM works.
In the program in question the users can either save the dates “as is” in the variant or use the selection variable, in which case the dates would change for every run. Two internal tables can be received from the FM: L_SELOP and VALUTAB. L_SELOP contains the selections that were saved as variant and VALUTAB contains the values. If the selection variable has been used, VALUTAB contains the actual date values, calculated with that variable, which is very neat.
Here is the test code that I used. The program name is RVV50R10C (delivery due list) and my variant was named TEST. You can, of course, use this FM with any program and variant.
DATA: t_valutab LIKE rsparams OCCURS 0 WITH HEADER LINE,In the TEST variant I’ve chosen the range of dates from [today – 10 days] till today using a selection variable. Here is the content of the t_selop table for the date field that I’m interested in (the table contains all the possible selection fields):
t_selop LIKE vanz OCCURS 0 WITH HEADER LINE.
CALL FUNCTION 'RS_VARIANT_CONTENTS'
EXPORTING
report = 'RVV50R10C'
variant = 'TEST'
TABLES
l_selop = t_selop
valutab = t_valutab
EXCEPTIONS
variant_non_existent = 1
variant_obsolete = 2
OTHERS = 3.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
The technical field name (T_SELOP-NAME field) can be found either in the program body (look for SELECTION-OPTIONS or PARAMETER) or (the easy way), start the program and then hit [F1] on the field. In the pop-up window, click on [Technical info] – the field name will be in the 'Screen field':
T_SELOP doesn’t say what exactly was in the selection variable (bummer!), but at least we know that a variable was used: see field VNAME. If there is no selection variable, the field VNAME is empty.
T_valutab is very similar to a regular range table. Here is the content of the t_valutab for the date field:
I ran the program on 10/19, so you can see that it nicely calculated the date 10 days back (LOW field). Of course we could run into a problem if the program 1 starts before midnight but program 2 after midnight. Even though in our case it will not happen due to the business restrictions, there is a possible solution: use an FM to look up the job start time and, if it’s not equal to sy-datum, adjust the dates in t_valutab. Maybe I’ll explore this concept in one of the future posts. Have fun!
posted by Your Friendly ABAPer @ 21:38, Direct link to this post
4 Comments:
- At 7/6/08 00:16, said...
-
Do you have any idea where or how are the variants stored.
I also made a program with that FM, but at first I was looking like crazy inside at how is the information fetched. - At 9/6/08 21:52, said...
-
Hi Ramiro! Thank you for the comment. The variants are stored in the table VARID. I found that SQL Trace (ST05 transaction) is very useful if you want to find out what tables are being updated by a program.
- At 14/6/08 01:22, said...
-
Yes, I've seen varid gets the variants, but is only the name, I have never found out where the contents are stored :S
I'll check the transaction on Monday, might clear the doubt, thanks - At 16/6/08 09:33, said...
-
The actual contents is stored in VARI table (there are also VARICON, VARIT and bunch of other tables - look for VARI*). But I don't think this information is very helpful, because the data is stored as some kind of a cluster in RAW format. E.g. if you look at the table in SE16, you won't be able to make much sense of it. This is similar to how the long texts are stored in SAP (STXL table). That's why the function modules are provided to read the data.