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.
Related
In my current project in Access VBA, I created a window which works like a console and now I am trying to add a possibility to display any public variable. It should work like:
Show_var [variable_name]
So it should be like in the direct window where i can type:
? pVar.variable_A
I found out that using
Application.VBE.ActiveVBProject.VBComponents(11).CodeModule.CountOfLines
I can display the number of lines within a module or form so I thought perhaps I could somehow find the variables there, cycle through them and when the correct one is found, its value can be shown. OFC I could make a Select Case Statement where all variables are included but that is not the way I want to do it because it is complicated and must be changed every time update my public variable list.
There are so many problems that I think you are out of luck. Let me just list some of them:
There is no way to get a list of all variables - that would mean you would need access to the internal symbol table.
As a consequence, you would have to read the code (CodeModule lets you read the code of a module), and write an own parser to fetch all declarations (hopefully you use Option Explicit)
AFAIK, the is no method that can access the content of a variable via it's name.
Even if there would be any such method: What would you do with different data types, arrays and especially with objects.
If a user runs into problems, often it is a runtime error. If you don't handle that errors with some kind of error handler, the only option if a user cannot enter the debugger is to press "End" - which would destroy the content of all variables.
You have to deal with scope of variables, you can have several variables with the same name and you will likely have lots of variables that are out of scope in the moment you want to dump them.
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.
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.
While modifying an existing program's CASE statement, I had to add a second block where some logic is repeated to set NetWeaver portal settings. This is done by setting values in a local variable, then assigning that variable to a Changing parameter. I copied over the code and did a Pretty Print, expecting to compiler to complain about the unknown variable. To my surprise however, this code actually compiles just fine:
CASE i_actionid.
WHEN 'DOMIGO'.
DATA: ls_portal_actions TYPE powl_follow_up_sty.
CLEAR ls_portal_actions.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
c_portal_actions = ls_portal_actions.
WHEN 'EBELN'.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
C_PORTAL_ACTIONS = ls_portal_actions.
ENDCASE.
As I have seen in every other programming language, the DATA: declaration in the first WHEN statement should be encapsulated and available only inside that switch block. Does SAP ignore this encapsulation to make that value available in the entire CASE statement? Is this documented anywhere?
Note that this code compiles just fine and double-clicking the local variable in the second switch takes me to the data declaration in the first. I have however not been able to test that this code executes properly as our testing environment is down.
In short you cannot do this. You will have the following scopes in an abap program within which to declare variables (from local to global):
Form routine: all variables between FORM and ENDFORM
Method: all variables between METHOD and ENDMETHOD
Class - all variables between CLASS and ENDCLASS but only in the CLASS DEFINITION section
Function module: all variables between FUNCTION and ENDFUNCTION
Program/global - anything not in one of the above is global in the current program including variables in PBO and PAI modules
Having the ability to define variables locally in a for loop or if is really useful but unfortunately not possible in ABAP. The closest you will come to publicly available documentation on this is on help.sap.com: Local Data in the Subroutine
As for the compile process do not assume that ABAP will optimize out any variables you do not use it won't, use the code inspector to find and remove them yourself. Since ABAP works the way it does I personally define all my variables at the start of a modularization unit and not inline with other code and have gone so far as to modify the pretty printer to move any inline definitions to the top of the current scope.
Your assumption that a CASE statement defines its own scope of variables in ABAP is simply wrong (and would be wrong for a number of other programming languages as well). It's a bad idea to litter your code with variable declarations because that makes it awfully hard to read and to maintain, but it is possible. The DATA statements - as well as many other declarative statements - are only evaluated at compile time and are completely ignored at runtime. You can find more information about the scopes in the online documentation.
The inline variable declarations are now possible with the newest version of SAP Netweaver. Here is the link to the documentation DATA - inline declaration. Here are also some guidelines of a good and bad usage of this new feature
Here is a quote from this site:
A declaration expression with the declaration operator DATA declares a variable var used as an operand in the current writer position. The declared variable is visible statically in the program from DATA(var) and is valid in the current context. The declaration is made when the program is compiled, regardless of whether the statement is actually executed.
Personally have not had time to check it out yet, because of lack of access to such system.
How do I call the SAP report (for example RSPARAM) with help JCo?
What RFC may be used to remotely call SA38 transaction with RSPARAM (e.t.c.) as parameter and then return results for later work ?
RFC is for calling function modules, not programs. It's possible to use some generic function module to start a report, but since you'll usually want to process the results of the program and the program does not know that it was meant to deliver its results in a machine-readable way, you probably won't get too far this was. What exactly are you trying to do?
With the nearly infinite possible results of calling a transaction, i don't think there is a RFC to execute such an operation and return a result. What would be the result in case of an ALV display, or if the program then wait for some interactions ?
You can display a transaction in SAP portal using transactions Iviews. You're then using the portal page as a HTMLGui for your transaction.
also, some FM can sometime be used to perform operations instead of a full program (ie HR_INFOTYPE_OPERATION instead of pa30).
regards
Guillaume
Edition : since you want the result of RRSPARAM, you could encapsulate the "important" part (form SHOW_ACTUAL_PAR_VALUES_ALV) in a module function accessible by RFC, and returning a table of CST_RSPFPAR_ALV (ie the same structure that is displayed in the report)
regards
If You don't find a function to call, just create one by yourself. Tag it as callable from outside via RFC and in the coding, perform such things as "submit report xyz with param1 = value1 ... and return ... exporting list to memory". Then you can even return list output from this. Define the interface of the freshly created function module as you need (that means, report name as input, list output as a table of strings, e.g.). Attention, there is of course a big security risk, having an remote function accepting variable reportnames. But I am sure You know :-)