Filling parameter with value from Zeconfig_var table - abap

I have the following selection parameter:
PARAMETERS: p_ver(2) AS LISTBOX VISIBLE LENGTH 5.
I would like to populate it with the results from a ZECONFIG_VAR table.
At what point would I do this. Selection Screen Output, Start of Selection, or other. I am trying to allow users the ability to decide what version of the web service they would like to call. The config table will have different url's for the different versions.
I have looked at this Answer and the tutorial provided does not make sense to me.

I would do it at the event INITIALIZATION
However, it may be even easier to just create a search-help, and assign it to p_ver using the following:
parameters: p_ver(2) visible lenghth 5 MATCHCODE OBJECT zshelpname.

Esti is right that you probably want to fill an internal table from the DB table during INITIALIZATION.
But to the populate the listbox parameter, you need to put the call to VRM_SET_VALUES in AT SELECTION-SCREEN OUTPUT.

Related

Different parameter count in FORM and PERFORM

I am trying to add a formal parameter in the FORM and PERFORM in an existing code, as I will be need it the extra parameter in a new function that I have to call. The idea is that when executing the new code it keeps showing the error: Different parameter count in FORM and PERFORM (routine: CM_SHOW_CRC, number of formal parameters: 2, number of actual parameters: 3).
The code that I have for the form part is as follows:
FORM cm_show_crc
USING
civ_matnr TYPE matnr
civ_charg TYPE charg_d
civ_werks TYPE werks_d. "The parameter that I added
And the perform code is:
PERFORM cm_show_crc
USING
pis_sdow_alv-matnr
pis_sdow_alv-charg
pis_sdow_alv-werks. "The parameter that I added
The table pis_sdow_alv is type of a structure that also includes the variable WERK(Component type WERKS_D)
Before adding the new parameter WERK the code was working fine.
May anyone know what the problem in this part of the code may be?
There was also another similar question in: Different number of parameters in FORM and PERFORM, however I am not using the syntax CHANGING in my code, as it was also not used prior.
Please do tell me if you need additional information.
Thank you all in advance!
This problem can occur when FORM and PERFORM are in different includes and you only activate one but not the other.
When you activate an include, then it is checked against the active version of all other repository objects it depends on. Not the saved version. This can lead to an annoying catch-22 situation. You can not activate A because it does not match the previous version of B, and you can not activate B because it does not match the previous version of A.
The solution to this conundrum is to activate both objects together. When you activate something in SE80 and you have multiple inactive objects, you get a window where you can select multiple objects to activate together:
In Eclipse, you get a similar list by clicking on the "activate multiple" button:

Getting the values of an /AIF/ERR variant

I did try using the RS_VARIANT_CONTENTS and RS_VARIANT_VALUES_TECH_DATA, it did show the values of the variant except the values of the name space, interface and interface version in which I also need to retrieve. I also searched the VARI* and TVARC tables but I didn't found it there.
I think it has something to do with the program name and screen number. Do you have any ideas or other way that I can retrieve all those values, whether using FM or select?
Thank you.
Some of the parameters in the transaction /AIF/ERR, the ones you are talking about, vary dynamically based on the value chosen in the Application screen field. They are handled by another AIF program, and they are not saved in the program variant, but in the table /AIF/T_ERR_VARS.
You may call the function module /AIF/ERR_VAR_LOAD to load the missing parameters.
Its usage is shown in the subroutine GET_VAR of the program /AIF/ERROR_HANDLING_TRANS (which is the program behind the transaction /AIF/ERR).

How to create a custom Allure step function for sensible data

I am currently working on a Testing Automation team, using Python and Allure to make reports of all the test cases that we run. Sometimes we deal with sensible data (e.g: passwords) that I can't show on the reports. If I use a function with a step decorator, something like this:
Which takes an element (a text box) and enters the value in it. In the step function I display the value that I want to enter, I could easily change that but the problem resides in the actual report. No matter what I enter on the step title, the report always shows the info that was passed as arguments to the function:
Thus, the "value" argument will always be displayed and that is something that I cannot have on certain projects. Is there anyway to make a custom step function that solves my problem?. I could either use with not showing the value at all or to change it to something like '*****'.
Just a thought.
#allure.step("Entering a value in element {3}")
def setSecureBoxValue(driver, element, value, box_name):
I solved my problem with the use of Fernet cryptography library.
I created a new function for the sensible data that encrypts the strings and then, inside this new function I call the one I shared on the screenshot (with a slight modification to decrypt the data). This results in the following report:

BIRT report variable is always null when passed going to service

i wanted to pass a dataset row values to report variable just like in this example
Everything works great as expected. I can even print the text in a label using vars["Foo"] as stated in the example. But when I used that vars["Foo"] to datasource property binding like "http://localhost:8081/someService?fooIdList=" + vars["Foo"], fooIdList is always null.
why is that? Is there a way I can pass it going to a service? thanks
This is a tough answer because there are many issues involved.
Firstly, there is a kind of egg-and-chicken problem: datasources are built by the birt engine before datasets are processed. Therefore we can't make use of the result of a dataset in property bindings of a datasource.
Declaring a dataset in a report does not mean it will be triggered: in the example you provided, if we don't drag the column "Foo" into the report then "FooDataset" would never run and the report variable would not be initialized.
This is very important to understand the execution order: if we want to populate a report variable from a dataset D1, and make use of it in a Dataset D2, then D1 must be triggered by the report before D2: for example we drag a data element from D1 at the beginning of the report, and set the visibility to false.
You should probably declare your datasource as "Scripted" and make use of a scripted dataset to access the service. You can get a nice example of a scripted dataset here
I hope it helps.

Dynamically declaring parameters from table

Is it possible to dynamically create parameters from table entries?
For example like this:
SELECTION-SCREEN BEGIN OF BLOCK example WITH TITLE text-01
LOOP AT example_internal_table INTO example_workarea
IF example_workarea-field = criteria.
PARAMETERS: (example_workareafield) AS CHECKBOX.
ENDIF.
ENDLOOP.
SELECTION-SCREEN END OF BLOCK example.
The code snippet above throws the error that example-workarea-field is not a constant. Does this mean it isn't possible to dynamically declare parameters or am I just doing it wrong? Thanks
Correct. PARAMETERS statements compile into selection screens at compile time, not at runtime. Therefore you cannot do what you want in the way you have proposed.
However, it is possible to have some form of dynamic screens.
Look at the answers to this question: For the I/O fields in a normal ABAP screen, can i get them to behave like a SELECT-OPTIONS?
This gives you two starting points: The use of subscreens, which you can call dynamically, or the use of FREE_SELECTIONS_INIT as examples.
Depending on how crazy you are about this, you can also investigate:
http://help.sap.com/abapdocu_702/en/abenabap_language_dynamic.htm
You could load the DYNPRO and dynamically change the screen, activate and then run a report that calls the changed screen.
This is of course a different approach from using PARAMETERS and should only be used for pet projects, not real production code as these statements are for internal use. I believe this is the approach that SE16 uses when it generates a selection screen for a table.