-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EDOI] Add new object types EDOI #681
base: main
Are you sure you want to change the base?
Conversation
|
Hi @i506210, Thank you for your contribution. Would you mind to split this pull request (PR) into two PRs? One for EDOI and one for EDOT. I believe the handling for one PR per object type will be easier. Furthermore, you might want to remove the Thanks :) |
Hi @schneidermic0, I have split Pull request into 2 and triggered PR. could you please check Thanks & REgards, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Venkat,
thanks for the update. I've added some questions/comments to your pull request.
Please note, that for the title and description, we use title case and sentence case respectively. I've not marked every occurrence but if you could please adjust that.
"! <p class="shorttext">Interface Version</p> "<- title (title case)
"! Interface version "<- description (sentence case)
"! <p class="shorttext">eDocument Interface</p> | ||
"! eDocument Interface | ||
"! $required | ||
edocument_interface_id TYPE c LENGTH 30, | ||
"! <p class="shorttext">eDocument Interface Description</p> | ||
"! Interface Description. | ||
"! $required | ||
interface_description TYPE c LENGTH 100, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this edocument_interface_id
and interface_description
the name and description of this EDOI object?
To prevent redundant data, the name is saved in the file name, and the description is saved in ty_main->header
(where you currently have selected a header with description length 60, but there is also a version for length 80 or length 100 available).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be I might have added 'header' by referring the sample interface. I don't know the purpose of 'header' section. If its not necessary, i will remove it.
Could you please explain the statement "the name is saved in the file name,", As I didn't find the field 'file name'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be I might have added 'header' by referring the sample interface. I don't know the purpose of 'header' section. If its not necessary, i will remove it.
We expect formatVersion
and header
as mandatory fields. See https://github.com/SAP/abap-file-formats/blob/main/docs/json.md#writing-json-schema-with-abap-types
Therefore, please do not remove it ;)
Could you please explain the statement "the name is saved in the file name,", As I didn't find the field 'file name'.
If you check the file names in AFF, the object name is stored there. There is no need to add it to the file content. This would be redundant data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
corrected, removed object name and description from general information
Hi
Hi Michael, I corrected all the places. Thanks & Regards, |
"! eDocument interface versions | ||
TYPES ty_edoc_int_drc_attributes TYPE SORTED TABLE OF ty_edoc_int_drc_attr WITH UNIQUE KEY process_type. | ||
|
||
CONSTANTS: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you move this block closer to ty_int_direction? This is where this enumeration is used
"! $required | ||
interface_version TYPE c LENGTH 4, | ||
"! <p class="shorttext">Interface Version Description</p> | ||
"! Interface dersion description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"! Interface dersion description | |
"! Interface version description |
"! <p class="shorttext">Interface Version</p> | ||
"! Interface version | ||
"! $required | ||
interface_version TYPE c LENGTH 4, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the possible values for the interface version here? Are they fixed values and should it be an enumeration as well?
TYPES: | ||
"! <p class="shorttext">Attribute Determination for Communication with Cloud Edition</p> | ||
"! Attribute determination for communication with cloud edition | ||
BEGIN OF ty_edoc_int_drc_attr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BEGIN OF ty_edoc_int_drc_attr, | |
BEGIN OF ty_determination_attribute, |
END OF ty_edoc_int_drc_attr. | ||
"! <p class="shorttext">Interface Versions</p> | ||
"! eDocument interface versions | ||
TYPES ty_edoc_int_drc_attributes TYPE SORTED TABLE OF ty_edoc_int_drc_attr WITH UNIQUE KEY process_type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TYPES ty_edoc_int_drc_attributes TYPE SORTED TABLE OF ty_edoc_int_drc_attr WITH UNIQUE KEY process_type. | |
TYPES ty_determination_attribute TYPE SORTED TABLE OF ty_edoc_int_drc_attr WITH UNIQUE KEY process_type. |
I would say that having edoc and interface in the name of the variable is unnecessary as the whole object type is about the edoc interface. What do you think?
When you will be using the AFF, it will be something like this, the easier the name, the better
edoi_model-edoc_spec_additional_table[index]
"! <p class="shorttext">Attribute Determination for Communication with Cloud Edition</p> | ||
"! Attribute determination for communication with cloud edition | ||
"! $required | ||
edoc_spec_additional_table TYPE ty_edoc_int_drc_attributes, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this name correct? doesn't seem to have much in common with the title and type name
{ | ||
"formatVersion": "1", | ||
"header": { | ||
"description": "Create eDocument Types", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the I in EDOI stand for Interface? Then maybe the description could be: AFF for eDocument Interface (EDOI)
No description provided.