Conversation
|
@larshp Since DOMA has been merged, now. Shall we proceed with this in the same way as with DOMA? If so, I can try to update this proposal, too. But give me some time. |
|
yes, we can go ahead with this one |
There was a problem hiding this comment.
Pull request overview
Adds an initial ABAP File Format (AFF) definition for DDIC Data Elements (DTEL) and introduces a shared DDIC-types interface to reuse common type definitions across DDIC object formats.
Changes:
- Introduce
zif_aff_ddic_types_v1to centralize reusable DDIC primitive types (data type enum, length, decimals). - Add the DTEL AFF type interface, JSON schema (
dtel-v1.json), README, and an example DTEL file. - Refactor DOMA to reuse the new shared DDIC types instead of duplicating them.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| file-formats/zif_aff_ddic_types_v1.intf.json | Metadata for the new shared DDIC types interface. |
| file-formats/zif_aff_ddic_types_v1.intf.abap | Centralizes DDIC type enum + length/decimals constraints for reuse. |
| file-formats/dtel/type/zif_aff_dtel_v1.intf.json | Metadata for the DTEL AFF type interface. |
| file-formats/dtel/type/zif_aff_dtel_v1.intf.abap | Defines DTEL structure (domain/type refs, labels, search help, etc.). |
| file-formats/dtel/examples/zdtel_v1.dtel.json | Example DTEL JSON instance. |
| file-formats/dtel/dtel-v1.json | Generated JSON schema for DTEL files. |
| file-formats/dtel/README.md | DTEL format documentation entry point. |
| file-formats/doma/type/zif_aff_doma_v1.intf.abap | Switches DOMA to reference centralized DDIC types. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| @@ -0,0 +1,175 @@ | |||
| "! <p class="shorttext synchronized" lang="en">Common DDIC types reusable in AFF</p> | |||
| "! Types which can be reused for ABAP Dictionary object types (DOMA, DTEL, etc.) | |||
| INTERFACE zif_aff_ddic_types_v1 PUBLIC. | |||
There was a problem hiding this comment.
[internal] there should be a IF_AFF_DDIC_TYPES_V1 in the SAP BASIS shipment
There was a problem hiding this comment.
I have created ZIF_AFF_DDIC_TYPES_V1 for now. I was wondering whether we should move them to a dedicated folder. But this can be done later, too.
| "! <p class="shorttext">Domain Name</p> | ||
| "! Reference domain name | ||
| domain_name TYPE zif_aff_types_v1=>ty_object_name_30, | ||
|
|
||
| "! <p class="shorttext">Predefined Type</p> | ||
| "! Predefined ABAP type | ||
| predefined_type TYPE ty_predefined_type, | ||
|
|
||
| "! <p class="shorttext">Reference Type</p> | ||
| "! Reference to an ABAP type | ||
| reference_type TYPE zif_aff_types_v1=>ty_object_name_30, | ||
|
|
||
| "! <p class="shorttext">Reference Predefined Type</p> | ||
| "! Reference to a predefined ABAP type | ||
| reference_predefined_type TYPE zif_aff_types_v1=>ty_object_name_30, |
There was a problem hiding this comment.
There was a problem hiding this comment.
yea, well, cannot really express "oneOf" in ABAP types
I'd say its up to presentation and/or additional checks
There was a problem hiding this comment.
but I guess we can also do a new annotation, which is just relevant for the JSON schema
we can always implement that later? and not wait until its done?
There was a problem hiding this comment.
I would love to have s.th. like oneOf. Unfortunately, this would have some implications we cannot address so fast.
ABAP Doc Checks
|
|
@schneidermic0 any thoughts? |
|
The team is working on a proposal for data elements currently. They wanted to reach out here soon anyhow. Can we wait for some time? |
So my efforts is expected ti be discarded? |
Hi Lars, We have been working on a solution to automate the AFF generation, which works specially well on objects that already exist in ADT, mainly due to the XSD structure for ADT editors. The AFF Generation AI Tool has access to this AFF repo, to past comments from our reviews, to our ADT codebase and to our ABAP systems. To keep it transparent, I am posting here the fully generated AFF, without any manual input from us. We already reviewed the structure with the colleagues responsible for the DTEL editor and we are very pleased with it, it would need a final review from the object type experts and a review regarding title, naming and descriptions (these come down to personal taste). One thing I noticed is that it contains the length variables (medium_length, short_length), which is missing in your AFF and I also prefer the solution of ty_type_definition vs your ty_data_type_information. To not let any of your work go to waste and since this is your PR, you can tell us if we should adapt yours to include some of the improvements from this generated AFF, or if we should directly iterate from this one :) Note: Use the raw text from my comment to see the ABAP type INTERFACE zif_aff_dtel_v1 PUBLIC. 'predefinedAbapType', Reference to Predefined ABAP Type "! Data element is a reference to a predefined ABAP type ref_to_predefined_abap_type TYPE ty_type_kind VALUE 'refToPredefinedAbapType', "! Reference to Dictionary Type "! Data element is a reference to a Dictionary type ref_to_dictionary_type TYPE ty_type_kind VALUE 'refToDictionaryType', "! Reference to Class/Interface Type "! Data element is a reference to a class or interface type ref_to_clif_type TYPE ty_type_kind VALUE 'refToClifType', END OF co_type_kind. 'notUsedInScreens', Explained by Short Text "! Short text is sufficient as documentation explained_by_short_text TYPE ty_documentation_status VALUE 'explainedByShortText', "! Postponed "! Documentation is postponed postponed TYPE ty_documentation_status VALUE 'postponed', END OF co_documentation_status. ENDINTERFACE. |
|
@GuilhermeSaraiva96 format the above message, or open a separate PR so we can see it? does this also mean you'll be opening PRs for other object types? like TTYP ? |

#556
moving some of the types to new re-useable interface