I am working on an interface for communicating with SAP RFC functions. I have some questions regarding parameter hierarchy and uniqueness of parameter and table naming to which I can't seem to find an answer anywhere online.
Are the deep hierarchical structures allowed when communicating via RFC? Here are some examples of input parameters:
Example A (Structure within Structure):
Field F1
Field F2
Structure S1
Field S1.F1
Structure S1.S1
Field S1.S1.F1
Field S1.S1.F2
Field S1.F2
Field S1.F3
Example B (Table within Structure):
Field F1
Field F2
Structure S1
Field S1.F1
Table S1.T1
Structure S1.T1.S1 (Row 1)
Field S1.T1.S1.F1
Field S1.T1.S1.F2
Structure S1.T1.S2 (Row 2)
Field S1.T1.S2.F1
Field S1.T1.S2.F2
Field S1.F2
Field S1.F3
Example C (Table within Table):
Field F1
Field F2
Table T1
Structure T1.S1 (Row 1)
Field T1.S1.F1
Table T1.S1.T1
Structure T1.S1.T1.S1 (Row 1)
Field T1.S1.T1.S1.F1
Field T1.S1.T1.S1.F2
Structure T1.S1.T1.S2 (Row 2)
Field T1.S1.T1.S2.F1
Field T1.S1.T1.S2.F2
Structure T1.S2 (Row 2)
Field T1.S2.F1
Table T1.S2.T1
Structure T1.S2.T1.S1 (Row 1)
Field T1.S2.T1.S1.F1
Field T1.S2.T1.S1.F2
Structure T1.S2.T1.S2 (Row 2)
Field T1.S2.T1.S2.F1
Field T1.S2.T1.S2.F2
Are the names of fields, structures and tables per hierarchical level unique? Or are the tables handled separately and could for example have the same name as a field or a structure?
RFC, including parameter types, is described in the documentation of each RFC Interface (documentation in each programming language RFC SDK, or ABAP documentation). You may use RFC both as client and server.
If you use RFC SDK (any programming language except ABAP) to create an RFC server (to expose RFC functions), I guess the types of the parameters support the same types as in ABAP (but I can't be sure so please refer to the documentation of each SDK in case of exceptions).
In ABAP, you can know the types of parameters supported in RFC by combining these two articles:
Properties of Interface Parameters
RFC - Restrictions
If you don't have the time to combine them, here's a summary of parameter types for RFC-enabled function modules:
A parameter can be of any type, elementary (what you call "fields"), structure, table.
Structures can have components of any of the 3 types above.
Tables which are not TABLES parameters can have lines of any of the 3 types above.
Tables which are TABLES parameters must have lines of type flat, which means that the line cannot contain fields of type STRING or XSTRING, nor tables.
The names of fields, structures and tables are unique per hierarchical level, whatever their parameter category, IMPORTING, EXPORTING, CHANGING or TABLES, e.g.
a component of a structure at level 1 may have the same name as a parameter at level 1.
a field and a structure at level 1 cannot have the same name
One exception to the previous rule is that two parameters can have the same name at level 1 if they are of type IMPORTING and EXPORTING (they are considered the same as one CHANGING parameter of that name - see SAP note 357348 - Import and export parameters of the same name).
The rows of one table all have the same type, so your diagrams mentioning S1 and S2 are incorrect, you could just mention S1. Note that a table parameter can have lines also of type elementary and table.
Here is an example of valid parameters of an RFC-enabled function module:
Field F1
Structure S1
Field S1.F1
Structure S1.S1
Field S1.S1.F1
Table T1
Structure T1.S1
Field T1.S1.F1
Table T2
Field T2.F1
Table T3
Table T3.T1
Field T3.T1.F1
Table T1
Table T1.T1
Field T1.T1.F1
Table T2
Structure T2.S1
Field T2.S1.F1
Table T3
Field T3.F1
Reference:
ABAP Documentation
Function Module Interface
Properties of Interface Parameters
FUNCTION, table_parameters (this concerns TABLES parameters with TYPE)
FUNCTION, LIKE, STRUCTURE (this concerns TABLES parameters with LIKE or STRUCTURE)
RFC - Restrictions
Pass-by value must be selected for the IMPORTING, EXPORTING, and CHANGING parameters of a remote-enabled function module. This cannot be specified explicitly for TABLES parameters, but are used implicitly for RFC.
*The formal parameter of a remote-enabled function module must be typed using data types from ABAP Dictionary or using predefined ABAP types. Data types from type groups cannot be specified.
No reference variables can be passed in RFCs. The formal parameters of a remote-enabled function module cannot, therefore, be typed using a reference type.
Others
357348 - Import and export parameters of the same name
Related
I'm researching the data types of the field of SAP's data table.
I realized that the fields that only store numbers are sometimes varchar or char data types. e.g., KUNNR(Customer Number) and BUKRS(Company Code) are character data types.
What is the objective or benefit of defining the data type of the fields to varchar/char instead of int when determining the field's data type that only contains numbers by its name's definition?
edit: SAP has "numc" data type and for numeric text and "INT1/2/4/8" data type for interger but use char/varchar for Customer Number or Company Code instead. Please help me if you have the idea why they use char data type for the above cases. I'm now trying to create data schema by referencing SAP's data schema.
Pages that referencing details of SAP's table/fields:
http://www.saptables.net/
https://sapstack.com/
Companies in global supply chain exchanges their transaction data through Electronic Data Interchange(EDI). The data is often variable-length XML or something similar. SAP mainly uses varchar to efficiently use the data for their application. The XML message data for transaction vary from business to business; sometimes number sometimes charcter but required to handle and save to it the database.
I've had a constraint imposed on me that my C structure names can't be published via DDS and that I instead have to use a different set of names and then somehow associate the two. It begs the question why not just change my C structure to match the actual DDS names but it is impractical since the names have to be configurable at run time.
Discarding the run-time constraint, I am wondering if there is an IDL keyword that I can use to create an alias between my structures and the desired DDS published names. There is an "alias" keyword but it is for data types.
I did a lot of google searching and had a hard time finding a definition for IDL keywords. The OMG document doesn't provide any insight to indicate this is possible (perhaps it's not).
In DDS, data types are registered with the middleware via a 'register_type()' operation. This operation includes a parameter to specify the 'name' to associate with the registered type. This name is not required to match the name of the IDL type. [If this name is not specified, then the middleware will use the IDL type name.]
I'm creating a function for querying a SQLite database that should be generic in the sense of reading from multiple pre-defined tables. As part of the function's paremeters, it is necessary to tel which column of the table should be read, an info that is supposed to be passed by an enumerator value. So the call would be something like this:
callMyFunction(enumTableA,enumColumnB);
Since enumColumnB is an enumerator value, the argument is an integer and I would like to identify the column by that integer value without having to use a switch-case for that. Something like this:
SELECT column(enumColumnB) from ...
So instead of passing the name of the column or reading all columns with * and then selecting the desired one when reading, it would use the number of the column as passed by the enumerator value to identify what should be read.
Is it possible to do this for SQLite? I couldn't find any tutorial mentioning such possibility, so I'm almost concluding there is no such possibility (and I'll have to pass the name of the column as argument or use a switch-case at the end), but I'ld like to be sure I don't have this option available.
SQLite has no mechanism for indirect columns.
(SQLite is designed as an embedded database, i.e., to be used together with a 'real' programming language.)
You have to replace the column name in whatever programming language you're using.
I just started learning ABAP and I came acroos some different ways of declaring internal tables but I don't understand the difference between these ways. Which one is the best way?
Sample 1
types: begin of ty_tab,
field1,
field 2,
end of ty_tab.
data x_tab type ty_tab.
data itab like standard table of x_Tab.
Sample 2
types: begin of ty_tab,
field1,
field2,
end of ty_tab.
types x_tab type standard table of ty_tab.
data itab type x_tab.
Sample 3
data t_sflight type sflight.
Sample 1 first declares a type ty_tab with some fields. ty_tab is not a table type, it is a locally defined flat structure type. The data declaration following the type definition defines a local variable with name x_Tab and type ty_tab. The third data declaration then uses the "like" keyword to create a table that has lines "like" the structure x_Tab.
Sample 2 begins again with the definition of a type. But instead of first declaring a structure the data definition defines a standard table of type ty_tab.
Sample 3, as hennes mentioned in his comment, doesn't actually define a table. It defines a local structure based on a structure or table defined in the SAP Data Dictionary, in this case the transparent table "sflight". If you wanted to create an internal standard table based on DDIC table sflight, you would have to change the statement to:
data t_sflight type standard table of sflight.
All three variants are valid. Variant 1 and 2 create the identical (identical as in 'same fields, same properties') internal table with different means. There is no best way, each variant can be used where it fits. If you need a table that looks like one that already exists in the DDIC, use #3. #1 and #2 seem redundant at a glance, but sometimes you may receive a structure as a parameter and now want a internal table with that structure, so you can use the "like" keyword in #1.
Have a look at the SAP Help pages for more information.
I wanna have a table parameter in a RFC function module of type CGPL_TEXT1, which uses the domain type TEXT40, which is a char 40.
I tried to create it:
IT_PARTS_DESCRIPTION LIKE CGPL_TEXT1
But I keep getting this error
tables using like may only reference flat structures
I am also not able to use TYPE. If I do so, I get this error:
Flat types may only be referenced using LIKE for table parameters
Don't go there. For RFC-enabled function modules, always use a structure as a line type for your table. The RFC protocol itself also supports unstructured tables, but many adapters don't. So you should
declare a data dictionary structure Z_MY_PARTS_DATA with a single field DESCRIPTION TYPE CGPL_TEXT2
declare a data dictionary table type Z_MY_PARTS_TABLE using this structure
use that table type in your function module.
Look inside the dictionary for a table type which has only one column representing Your Text.
If You cannot find it, just go the proper way and define a z structure and a z tabletype based on that structure. This is the proper way and I also prefer to use this ( even sometimes, when I would not really need it, i do this ).... because the structures sand table types can be documented.