I need to define one dynamic selection field as required.
I created a transaction code with a starting variant.
For this variant in the attributes screen assignment, there is no "required field" option on dynamic selections, only "protect field".
Any idea how to implement this?
On variant attributes screen assignment there is not required field
option on dynamic selections
There is Required attribute in screen variant and it is perfectly usable for making regular field mandatory, and in dynamic selections too.
If you lack it, check your release or maybe your installation is corrupted. I don't believe it is tcode-dependent.
If you are talking about the Dynamic Selections, then you can only protect the fields. Example with demo program DEMO_LIST_OUTPUT (which is based on the F1S Logical Database):
You can only protect those fields against input, and all other attributes are deactivated (they are not implemented as you can see in subroutine MODIFY_SCREEN of program SAPLSSEL).
The only possible workaround to simulate a mandatory field is to implement ABAP code after the user has entered selections (or not). For instance, in the program DEMO_LIST_OUTPUT, you may add this ABAP code which checks that the screen field "Connection Number" contains a value when the user executes the program:
TABLES sscrfields.
AT SELECTION-SCREEN.
DATA dynsel TYPE rsds_trange.
CALL FUNCTION 'RS_REFRESH_FROM_DYNAMICAL_SEL'
EXPORTING
curr_report = sy-repid
mode_write_or_move = 'W'
IMPORTING
p_trange = dynsel
EXCEPTIONS
not_found = 1
wrong_type = 2.
DATA(connid) = VALUE spfli-connid(
dynsel[ tablename = 'SPFLI'
]-frange_t[ fieldname = 'CONNID'
]-selopt_t[ 1 ]-low OPTIONAL ).
IF sscrfields-ucomm = 'ONLI' AND connid IS INITIAL.
MESSAGE 'Flight Connection number is required' TYPE 'E'.
ENDIF.
NB: Tested with ABAP 7.52. Dynamic Selections can be implemented implicitly via Logical Databases (which are obsolete since ABAP 7.02 or 7.31) or explicitly by calling the function modules FREE_SELECTIONS_INIT and FREE_SELECTIONS_DIALOG.
Related
I am trying to assign the value of this stucture path to a fieldsymbol, but this path does not work because it has a table in it's path.
But with in the debugger this value of this path is shown correctly.
Is there a way to dynamically assign a component of a table line to a fieldsymbol, by passing one path?
If not then I will just read the table line and then use the path to get the wanted value.
ls_struct (Struct)
- SUPPLYCHAINTRADETRANSACTION (Struct)
- INCL_SUPP_CHAIN_ITEM (Table)
- ASSOCIATEDDOCUMENTLINEDOCUMENT (Element)
i_component_path = |IG_DDIC-SUPPLYCHAINTRADETRANSACTION-INCL_SUPP_CHAIN_ITEM[1]-ASSOCIATEDDOCUMENTLINEDOCUMENT|.
ASSIGN (i_component_path) TO FIELD-SYMBOL(<lg_value>).
IF <lg_value> IS NOT ASSIGNED.
return.
ENDIF.
<lg_value> won't be assigned
Solution by Sandra Rossi
The debugger has its own syntax and own logic, it doesn't apply the ASSIGN algorithm at all. With ABAP source code, you have to use ASSIGN twice, the first one to reach the internal table, then you select the first line, and the second one to reach the component of the line.
The debugger works completely differently, the debugger code works only in debug mode, you can't call the code from the debugger (i.e. if you call it, the kernel code used by the debugger will fail). No, there's no "abappath". There are the XSL transformation objects (xpath), but it's slow for what you ask.
Thank you very much
This seems to be a rather unexpected limitation of the ASSIGN statement. Probably worth a ticket to SAP's ABAP language group to clarify whether it's even a bug.
While this works:
ASSIGN data-some_table[ 1 ]-some_field TO FIELD-SYMBOL(<lv_source>).
the same expressed as a string doesn't:
ASSIGN (`data-some_table[ 1 ]-some_field`) TO FIELD-SYMBOL(<lv_source>).
Alternative 1 for (name) of the ABAP keyword documentation for the ASSIGN statement says that "[t]he name in name is structured in the same way as if specified directly".
However, this declaration is immediately followed by "the content of name must be the name of a data object which may contain offsets and lengths, structure component selectors, and component selectors for assigning structured data objects and attributes in classes or objects", a list that does not include the table expressions we would need here.
I'm working on a Function Module to assist with dealing with included text with logic embedded. While looking into the way SAP handles SAPScript files and parses the logic I found a structure that is declared as so:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command LIKE BOOLEAN,
template LIKE BOOLEAN,
mask LIKE BOOLEAN,
END OF events.
This obviously works, as I can trace through it while it is running a print program. So I thought I would try a similar structure in my own code but even when I copied the code 1 for 1 like above I get an error during activation. The error is
"BOOLEAN" must be a flat structure. Internal tables, references,
strings and structures are forbidden as components.
Can someone explain to me why this structure is valid in one program and not mine?
To explain the actual effect: LIKE usually refers to a data object (an actual variable) on the right-hand side, not a data type. As you rightly discovered, once you provide a data object named BOOLEAN, that is used to construct the type. If a data object of that name is not present and you're not within a class or an interface, an obsolete variant of the LIKE statement will be triggered that also takes data types into account, but only allows for certain elements on the right-hand side - namely only flat structured objects or their components. LIKE DATATYPE-BOOLEAN should have worked. As usual, the error message is somewhat less than helpful.
It seems during my initial investigation I missed a declaration for the BOOLEAN type. In the STXC function group SAP decided to declare their own variable for boolean in a different include file like this:
data: boolean(1) type c.
I had originally assumed that they were doing this with the dictionary defined type which has a similar name and is a 1 character long string. What I also found is that if I were to change my structure declaration like this:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command TYPE BOOLEAN,
template TYPE BOOLEAN,
mask TYPE BOOLEAN,
END OF events.
My code would be valid because it would then be using the dictionary defined value. So either I have to add a declaration for my own definition of boolean so that I can use the LIKE keyword or I have to use the TYPE keyword to use the dictionary definition.
I need to call a function that has a table type as import parameter in a program. I thought about doing this with a selection screen but I can't use deep structures as parameters. When I 'TEST' that function module it shows me a thing where I can add multiple entries and submit everything in the end. Can I get something similar during the execution of a program?
edit: I have to offer a program that calls the function module create_skill_profile.
1
2
3
You can call the function module RS_COMPLEX_OBJECT_EDIT in your report for editing a complex structure. This is the same function module that is used for editing test data in the function module single test.
So, in your report, you could ask for the name of the desired type (if that has to be a dynamic one), and then, in start-of-selection, you can create a data object of this type and pass it to RS_COMPLEX_OBJECT_EDIT to let the user fill it.
A serious limitation of RS_COMPLEX_OBJECT_EDIT is that it can't handle sorted or hashed tables as input. So all the components of your complex structure, if they are of table kind, they have to be standard tables.
What I understand: You want to call a function module that requires a table as import parameter. The table's rows are filled from user input. The number of rows is dynamic.
Approaches:
1) use selection screen with predefined input fields and show/hide them dynamically via PAI (AT SELECTION-SCREEN (on xxx). LOOP AT SCREEN.) then build your table and call your function module on START-OF-SELECTION.
2) show editable ALV grid with table structure. Implement an application toolbar button or use SAVE button to let the user call your function module when he finished inserting his input.
I would defenitely prefer 2), although custom input validation is a bit tricky. But if the required user input is the same as ddic defined table structure the input validation happens automatically.
I need some help with pentaho report designer.
I've used some parameters to filter my data, but, it seems that I'm obliged to filter on these parameters to show data on my charts.
So, this is what I want, I need to make my parameters optional. It means that I want to show global views even if I don't select a parameter.
Any thoughts?
Untick the mandatory checkbox in the parameter settings dialog.
You must create a hidden parameter; Let's call it "Flag" that tests whether the parameter are set, by using this post-processing formula.
=OR(ISNA([date_from]); ISNA([date_to]))
and then in your query reference that new parameter:
Select .....
where ${Flag} = TRUE OR (date between ${date_from} and ${date_to})
I want to expose the functionality of an SAP program (transaction) as a BAPI.
I need to call a report and supply range filters such that the GUI is bypassed.
Does anyone have a working example of the SUBMIT ... WITH ... ABAP construct, or other suggestions on how to accomplish what I need to do?
Here is a working example:
SUBMIT SAPF140
TO SAP-SPOOL "optional"
SPOOL PARAMETERS print_parameters "optional"
WITHOUT SPOOL DYNPRO "optional (hides the spool pop-up)"
VIA JOB jobname NUMBER l_number "optional"
AND RETURN "optional - returns to the calling prog"
WITH EVENT = REVENT
WITH BUKRS IN RBUKRS
WITH BELNR IN lRBELNR
WITH GJAHR IN RGJAHR
WITH USNAM = SY-UNAME
WITH DATUM = SAVE_DATUM
WITH UZEIT = SAVE_UZEIT
WITH DELDAYS = RDELDAYS
WITH KAUTO = 'X'
WITH RPDEST = SAVE_PDEST
WITH TITLE = TITLE.
All the "WITH" statements relates to selection fields on the called program where I use = it is a PARAMETER statement (single field), where I use IN it is a SELECT_OPTIONS statement (range)
Here is a simple example of how to fill a range:
REFRESH lrbelnr.
lrbelnr-sign = 'I'.
lrbelnr-option = 'EQ'.
lrbelnr-low = HBKORM-belnr.
CLEAR lrbelnr-high.
append lrbelnr.
If you want to suppress this functionality as a BAPI you have to wrap the functionality in a Remote Function Call (RFC) module. Just implement a RFC function module. Depending how the report is implemented, it may use ABAP objects, which can also be called from your RFC implementation. Given that case you have a quite good solution. Whenever the report is adjusted, also your BAPI will reflect the changes. In case it's a standard programm from SAP which cannot be wrapped, think about copying it into your namespace and adjusting it. Nevertheless this might give some hassle, when SAP performs an update via Support Package Stack and you won't realize it. The output of the two methods is different. Apart from that, if you want to call it from outside, there is nothing else possible than implementing a RFC module.
A submit report can not return the values outside. Reports are always only for GUI functionalities and not for exchanging data. In case your report uses select options, you somehow have to implement this feature "by hand" in your RFC, as this statements can not be used inside RFC modules. I would generally try to rework the report, modularize it and put the selection information in a central class or maybe another function module wich can be called from the report and your BAPI function module. The filters you are talking about can not be implemented in RFCs automatically. You have to implement those ranges manually. The warning which comes up cannot be suppressed, if you do a RFC call from a remote system and the popup with the warning comes up you'll end with a shortdump. Therefore, you have to rework the report and to re-implement it for your needs.
If you are just looking for bypassing it via job scheduling, create a variant and schedule the report with that variant but I suppose that's not the solution you're looking for.
You can use inbuilt BAPI also just write "Range" and press F4.
You can wrap your report in an BATCH INPUT session and execute it inside a function. The only drawback is that you need to rewrite the BATCH INPUT every time you change the report.