I'm looking at the description of CALL - System Function Call in the SAP ABAP Keyword Definition. Such calls have the format CALL 'xxx' ID 'yyy' FIELD 'zzz'. The ABAP Keyword Definition does not mention that sy-subrc is set by calling a system function. But somehow, I suspect that it is.
Can I "trust" the Keyword Definition in such a case? (sy-subrc not mentioned => not set)
What would be a "good" example system function call to test it on an SAP system? (does not break/change anything, exists on all systems)
Note that I'm not an ABAP programmer and I usually handle third-party ABAP programs in Java as text / parse tree. I know that one usually should not call system functions, but the ABAP code I look at might have such calls. Furthermore, I'm not interested in the actual value a specific system call sets sy-subrc to, just in the fact whether system calls set/alter sy-subrc or not.
Well, as you are asking this question you are already aware this is NOT recommended approach to use direct SYSTEM calls. However, if you still want to use them...
By using CALL statement SAP kernel C-modules are called and without knowing the source we can not interpret the returning value confidently, either it's 0 or 1.
Despite there are examples (see line 230 of DYNP_VALUES_READ FM) where sy-subrc value is checked after system calls, nobody except SAP knows which value to check in certain case. Nor we.
Also there were reports (1, 2) about ambiguous meaning of these values during tests.
So the answer is NO, sy-subrc in this context brings no meaningful information.
P.S. Answering your questions:
No, you cannot interpret it that way. If something is not mentioned in ABAP Documentation then this not known for sure or not meaningful at all.
I cannot confirm this is good idea at all (to test system calls), but if you want you can try call SYSTEM function.
It calls arbitrary Unix command. For example, you can move files stored on your ABAP Server like this:
CALL 'SYSTEM'
ID 'COMMAND'
FIELD 'mv /usr/sap/temporary
/usr/sap/definite'.
Now this should be a safe call that works on any system:
DATA: dbserver TYPE char255.
CALL 'C_SAPGPARAM' ID 'NAME' FIELD 'SAPDBHOST'
ID 'VALUE' FIELD dbserver.
As you probably already know there are some exceptions that can occur. As for sy-subrc, when a command sets sy-subrc it is usually explicitly mentioned in the documentation including which values it can hold and their meaning. But don't quote me on that.
Simple (harmless) function modules are RH_GET_DATE_DAYNAME that requires the language and 10 character date (eg. 26.10.2016) as input fields and DATE_TO_DAY that only requires the 10 character date as input. The sy-subrc should be returned as 0 if a valid date is entered.
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.
From the docs that say,
Returns the self-reference to the instance itself:
my $b; # defaults to Any
say $b.serial.^name; # OUTPUT: «Any»
my $breakfast = 'food';
$breakfast.serial.say; # OUTPUT: «food»
I do not have the foggiest what this routine does, please can someone explain?
On Supplys, it is an informational method that is supposed to indicate whether there will never be any concurrent emit on that Supply.
On HyperSeq and RaceSeq, it returns a serialized Seq, so you could consider it the opposite of the hyper and race method.
In general, it appears to return itself, which seems to make sense from the HyperSeq and RaceSeq point of view.
And yes, these should be documented properly, so please create a documentation issue. Thank you!
In the doc example it does nothing. That is, if you remove it you get the same results:
my $b; # defaults to Any
say $b.^name; # OUTPUT: «Any»
my $breakfast = 'food';
$breakfast.say; # OUTPUT: «food»
More generally, I think you'd best ignore the serial method other than to open a doc issue pointing to this SO if you'd like to improve the doc.
The serial method does not appear to be in the official language
A search of the roast repo for "serial" yields zero matches.
Within Rakudo source code the method name serial has been overloaded to have one of three meanings:
A boolean declaring whether a Supply sequence is always serial. Rakudo source examples: 1, 2. This looks to me like an internal method that doesn't need to be documented.
A coercion of parallel sequence (hyper or race) to a serial version of the same sequence. This looks to me like an internal method that doesn't need to be documented.
A "no op" that returns its invocant. I suspect it would be best if it were not documented, at least until such time as its raison d'etre is clear; its official status viz-a-viz the spec (roast) is clear; and/or there's an attempt to systematically document which operations have the is nodal set on them.
None of the above seems to warrant ordinary users' attention or documentation.
The Any class definition of a serial method seems pointless
The Any class serial method returns self, i.e. when called it is a no op.
I don't currently understand why there is an Any class definition.
One possible point for it would be that there are .serial calls made by internal code on instances of an unknown and generally unknowable class and there thus needs to be a default definition of serial in the Any class.
But a search of the rakudo repo for ".serial" suggests that calls are only made to supplies or hyper/race seqs.
That said, I note the is nodal trait on the proto serial declaration in Any that immediately precedes the multi method serial declaration. Perhaps that is the reason it's in Any.
See also Arbitrary drift of methods to Mu and Any.
The documentation you quoted seems pointless
The definition and example seem to reflect someone's sense of humor. I applaud use of humor but in this case I suspect the best improvement would be to just remove the page you linked.
I have a small question in my mind. I researched it on the Internet but no-one is providing the exact answer. My question is:
In data flow coverage criteria, say there is a method which finally returns variable x. When drawing the graph for that method, is that return statement considered to be a use of x?
Yes, a return statement uses the value that it returns. I couldn't find an authoritative reference that says so in plain English either, but here are two arguments:
A return statement passes control from one part of a program to another, just like a method call does. The value being returned is analogous to a function parameter. return therefore is a use just like being a function parameter is a use.
The other kind of use in data flow analysis is when a value leaves the program and has some effect on the outside world, for example by being printed. If we're analyzing a method, rather than an entire program, return causes the value to leave the scope which we're analyzing. So it's a use for the same reason that printing is a use.
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 :-)
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.