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.]
Related
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
I'm currently learning ABAP and wanted to know what is the difference between the following ways of defining a field symbol?
Method 1
FIELD-SYMBOLS <fs> TYPE data.
Method 2
FIELD-SYMBOLS <fs> TYPE any.
I understand that both are typed generically and that the data type will be assigned at runtime. What I don't understand is how the two are different (or if they are at all).
Yes TYPE ANY and TYPE DATA are exactly the same. Excerpt from ABAP documentation, Generic ABAP types :
The generic type any can, like all generic types listed here except
data and object, only be specified directly after TYPE and has exactly
the same effect there as the generic type data. After TYPE REF TO,
only data (for fully generic data reference variables) and object (for
fully generic object reference variables) can be specified. Specifying
REF TO any would define a fully generic reference variable covering
data references and object references. This is not currently possible.
We want to project a new database schema for our Society's application.
The program is developed in c# nancy serverside and react-redux-graphql on clientside.
Our Society often must implement repentine changing for treat new business data. So we want to realise a solid core for the fundamental and no subject to decadence data eg: Article (Code, description, Qty, Value, Price, categoryId).
But often we need to add particular category to an article, or special implementation only for a limited period of time. We are thinking to implement a TOXI like solution for treat those situations.
But in TOXI pattern implementation we wan to add a third table for define each tag data type and definition.
Here is a simple explanatory image:
In the Metadata we have two columns with JSON data: DataType and DefinedValue
DataType define How the program (eventually a func in db) must cast the varchar data in articoli_meta.value
DefinedValue is not null define if the type must have a series of predefined value eg: High, Medium, Low etc...
Those two column are varchar and contain JSON with a predefined standard, a defined standard from our programming team (ev. an sql func for validate those two columns)
I Understand that this kind of approach is not a 'pure' relational approach but we must consider that we often pass data to the client in json format so the DefinedValue column can easily queried as string and passed to interface as data for a dropdown list.
Any ideas, experience or design tips are appreciated
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 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.