[TRAN] Add new object type TRAN #713

WDFYvonne · 2025-07-24T08:48:53Z

No description provided.

WDFYvonne · 2025-07-24T09:58:19Z

Hi colleagues,
I do not see any abaplint errors for TRAN, there are new errors for old object SUSH. Do I need to correct these new errors for SUSH?

file-formats/tran/tran/README.md

WDFYvonne · 2025-07-28T08:03:31Z

Hi Colleagues,
could you please help me to resolve the issue with the generate JSON Schema?
Regards,
Yvonne

Markus1812

Hi Yvonne, thanks for contributing to our abap-file-formats repository. TRAN is a huge file format, so please understand if we need multiple iterations of reviews here. Below, I've added some first comments. Please have a look and let me know what you think :)

Markus1812 · 2025-07-29T11:07:28Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    BEGIN OF co_transaction_type,
+      "! <p class="shorttext">Dialog Transaction</p>
+      "! The runtime calls a dynpro of a function group, module pool or report.
+      "! The dynpro specified as initial screen must not be a selection screen.
+      "! The program logic defines which screens are displayed after the initial screen.
+      dia TYPE ty_transaction_type VALUE 'D',
+      "! <p class="shorttext">OO Transaction</p>
+      "! At runtime, the system calls a class method. The transaction links to either the ABAP Object
+      "! Services Transaction Service (for persistent objects) or to a public method of a class.
+      "! For instance methods, the system auto-creates a class instance.
+      oo  TYPE ty_transaction_type VALUE 'O',
+      "! <p class="shorttext">Parameter Transaction</p>
+      "! Parameter transactions specialize dialog or report transactions by presetting initial screen values.
+      "! You can also skip the initial screen to prevent users from changing these predefined values.
+      par TYPE ty_transaction_type VALUE 'P',
+      "! <p class="shorttext">Report Transaction</p>
+      "! The runtime calls a dynpro of a report.
+      "! The dynpro specified as initial screen must be a selection screen.
+      "! The execution of a report usually has three stages: data entry, data processing, and data output.
+      rep TYPE ty_transaction_type VALUE 'R',
+      "! <p class="shorttext">Variant Transaction</p>
+      "! Variant transactions customize dialog or report transactions by adapting menus and screens at runtime.
+      "! They let you preset field values, set field attributes, or hide screens to streamline user interaction.
+      var TYPE ty_transaction_type VALUE 'V',
+    END OF co_transaction_type.


Can you please rename the constants to a more meaningful value? E.g., dia => dialog_transaction. In the JSON Schema, they are then automatically translated to camel case (=> dialogTransaction). Very nice descriptions btw.

For TRAN we have defined our constants in the interface if_tran_wbi_object_data, also in AFF we should use the same constants

We also renamed the types, and because this AFF is irrelevant otherwise, using REPORT_TRANSACTION, etc., would be OK from my side.

Markus1812 · 2025-07-29T11:45:27Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+  "! $values {@link zif_aff_tran_v1.data:co_ua_inheritance_mode}
+  "! $default {@link zif_aff_tran_v1.data:co_ua_inheritance_mode.inactive}
+  TYPES ty_ua_inheritance_mode TYPE c LENGTH 1.
+  CONSTANTS:
+    "! <p class="shorttext">UI Attributes Inheritance Mode</p>
+    "! UI attributes inheritance mode
+    BEGIN OF co_ua_inheritance_mode,
+      "! <p class="shorttext">Active</p>
+      "! Active
+      active   TYPE ty_ua_inheritance_mode VALUE 'A',
+      "! <p class="shorttext">Inactive</p>
+      "! Inactive
+      inactive TYPE ty_ua_inheritance_mode VALUE 'I',
+    END OF co_ua_inheritance_mode.


Do you really need an enum type for this one or would an abap_bool be enough? Booleans are native types in JSON and should be preferred. If you plan to add more options to the enum in the future, please let me know.
Same question for ty_ui_classification , ty_ua_pervasive_mode , ty_ua_support_mode , ty_lock_status , ty_skip_initial_screen_mode , and ty_variant_maintenance_mode.

I agree with Markus. If you are not planning on extending this enums with more values, then a boolean is more intuitive.

We use the "..._MODE" typing exactly where we need to be open for extensions in the future. And I object that boolean values should be preferred. With 20 years of experience in designing transport objects, Boolean are what should be avoided in data models in first place. See https://wiki.one.int.sap/wiki/x/L1QCjw

Markus1812 · 2025-07-29T11:47:08Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    END OF co_update_mode.
+
+  TYPES:
+    BEGIN OF ty_dia,


These names are not visible for consumers, but it would be great if you could give them a more meaningful name. I suppose this has something to do with dialog_transaction, so why not name it ty_dialog_transaction?

I changed the ty_dia to ty_dialog_transaction (the same for all others types for transaction type)

Markus1812 · 2025-07-29T11:51:27Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">Editing of standard transaction variant</p>
+      "! If this indicator is set, activating a transaction variant as standard transaction variant
+      "! is enabled in the transaction variant maintenance.
+      "! This changes how the transaction looks at runtime, when it is started directly via its transaction code.
+      stv_maintenance_mode TYPE ty_variant_maintenance_mode,


The name of the type and the title should always be similar (or at least as similar as possible). In the server-driven editor, you only see the title, but the user can also see the JSON. In the JSON, stv_maintenance_mode is transformed to camel case and would look like stvMaintenanceMode. I know it can be hard with 30 characters, but do you have a more meaningful name?

DTEL: STRAN_STV_MAINTENANCE_MODE is no indicator. The current text is a leftover and needs to be adapted. First, the DTEL documentation needs to be created. The local type should then be "TY_STV_MAINTENANCE_MODE."

Markus1812 · 2025-07-29T11:52:22Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">Report</p>
+      "! Report name for the report transaction
+      report_name         TYPE c LENGTH 40,
+      "! <p class="shorttext">Screen</p>
+      "! Transaction start selection screen for the report transaction
+      report_dynnr        TYPE i,
+      "! <p class="shorttext">Variant</p>
+      "! Variant name for the report transaction
+      report_variant_name TYPE c LENGTH 14,


Variable naming and title are not matching. Can you rename the variables like the title?

Titles correspond to labels in the DTEL, and in labels referring to entity identifiers, the "Name/Number/ID" suffix is omitted on the screen in the regular UI guidelines. A field "value_table_name" would, of course, have the label "Value Table" and not "Value Table Name." Likewise, here, I enter reports, screens and report variants

Markus1812 · 2025-07-29T11:53:34Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">OO Transaction Model</p>
+      "! If this indicator is set, the OO transaction follows the object-oriented transaction model.
+      "! See the interface IF_OS_TRANSACTION_MANAGER for more information.
+      oo_transaction_model_indi TYPE abap_bool,


Suggested change

oo_transaction_model_indi TYPE abap_bool,

oo_transaction_model TYPE abap_bool,

Markus1812 · 2025-07-29T11:54:01Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">Parent Transaction</p>
+      "! The parent transaction code of the parameter transaction defines the transaction that provides
+      "! the program and the dynpro number that are started when the transaction is called.
+      "! The parent transaction can be a dialog or a report transaction.
+      "! $required
+      par_parent_transaction_code TYPE c LENGTH 20,


Suggested change

"! Parent Transaction

"! The parent transaction code of the parameter transaction defines the transaction that provides

"! the program and the dynpro number that are started when the transaction is called.

"! The parent transaction can be a dialog or a report transaction.

"! $required

par_parent_transaction_code TYPE c LENGTH 20,

"! Parent Transaction

"! The parent transaction code of the parameter transaction defines the transaction that provides

"! the program and the dynpro number that are started when the transaction is called.

"! The parent transaction can be a dialog or a report transaction.

"! $required

parent_transaction TYPE c LENGTH 20,

Markus1812 · 2025-07-29T11:54:13Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! It enables inheritance of settings like UI attributes or authorizations,
+      "! ensuring consistency and reducing duplication in configuration.
+      "! $required
+      var_parent_transaction_code TYPE c LENGTH 20,


Suggested change

var_parent_transaction_code TYPE c LENGTH 20,

parent_transaction_code TYPE c LENGTH 20,

Markus1812 · 2025-07-29T11:54:35Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">Cross Client</p>
+      "! If the indicator is set, the transaction variant is cross-client. If the switch is not set,
+      "! the transaction variant is client-specific.
+      transaction_variant_ci_indi TYPE abap_bool,


Suggested change

transaction_variant_ci_indi TYPE abap_bool,

is_cross_client TYPE abap_bool,

This is inconsistent with the other proposal. If the rule is to omit the Indicator suffix, the this would be " transaction_variant_cI". Note: Also the sort text is not correct as the -" is missing.

Markus1812 · 2025-07-29T14:45:13Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    BEGIN OF ty_par_pv,
+      "! <p class="shorttext">Parameter Name</p>
+      "! Name of the parameter for the parameter transaction
+      "! $required
+      parameter_name  TYPE c LENGTH 132,
+      "! <p class="shorttext">Parameter Value</p>
+      "! Value for the parameter of the parameter transaction
+      parameter_value TYPE c LENGTH 50,
+    END OF ty_par_pv.
+  TYPES ty_par_pv_t TYPE STANDARD TABLE OF ty_par_pv WITH DEFAULT KEY.


Suggested change

BEGIN OF ty_par_pv,

"! Parameter Name

"! Name of the parameter for the parameter transaction

"! $required

parameter_name TYPE c LENGTH 132,

"! Parameter Value

"! Value for the parameter of the parameter transaction

parameter_value TYPE c LENGTH 50,

END OF ty_par_pv.

TYPES ty_par_pv_t TYPE STANDARD TABLE OF ty_par_pv WITH DEFAULT KEY.

BEGIN OF ty_parameter_value,

"! Name

"! Name of the parameter for the parameter transaction

"! $required

name TYPE c LENGTH 132,

"! Value

"! Value for the parameter of the parameter transaction

value TYPE c LENGTH 50,

END OF ty_parameter_value.

TYPES ty_parameter_values TYPE STANDARD TABLE OF ty_parameter_value WITH DEFAULT KEY.

Just a suggestion, but I find that one way better to read. The same also applies to more types here, maybe you can check them too.

WDFYvonne · 2025-07-30T07:08:27Z

Hi Marcus, thank you very much for reviewing our AFF. All the field names and titles are based on our data model. I need to confirm this with Peter Dell, but he's on vacation until tomorrow.

GuilhermeSaraiva96 · 2025-07-30T08:48:26Z

Hi Yvonne, the AFF naming are separate from the data model names. In the aff persist class you can then map both. One of the main advantages of the AFF is providing a readable object, which does not happens if there are acronyms everywhere. Just to keep in mind ;)

GuilhermeSaraiva96 · 2025-07-30T08:51:54Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+
+  "! $values {@link zif_aff_tran_v1.data:co_ua_pervasive_mode}
+  "! $default {@link zif_aff_tran_v1.data:co_ua_pervasive_mode.enabled}
+  TYPES ty_ua_pervasive_mode TYPE c LENGTH 1.


Suggested change

TYPES ty_ua_pervasive_mode TYPE c LENGTH 1.

TYPES ty_ui_attr_pervasive_mode TYPE c LENGTH 1.

Since it is possible, it is more readable than just ua

GuilhermeSaraiva96 · 2025-07-30T08:52:36Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+  "! $values {@link zif_aff_tran_v1.data:co_ua_inheritance_mode}
+  "! $default {@link zif_aff_tran_v1.data:co_ua_inheritance_mode.inactive}
+  TYPES ty_ua_inheritance_mode TYPE c LENGTH 1.
+  CONSTANTS:
+    "! <p class="shorttext">UI Attributes Inheritance Mode</p>
+    "! UI attributes inheritance mode
+    BEGIN OF co_ua_inheritance_mode,
+      "! <p class="shorttext">Active</p>
+      "! Active
+      active   TYPE ty_ua_inheritance_mode VALUE 'A',
+      "! <p class="shorttext">Inactive</p>
+      "! Inactive
+      inactive TYPE ty_ua_inheritance_mode VALUE 'I',
+    END OF co_ua_inheritance_mode.


I agree with Markus. If you are not planning on extending this enums with more values, then a boolean is more intuitive.

GuilhermeSaraiva96 · 2025-07-30T08:55:02Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    END OF ty_ad.
+
+  TYPES:
+    BEGIN OF ty_ua,


Suggested change

BEGIN OF ty_ua,

BEGIN OF ty_ui_attributes,

GuilhermeSaraiva96 · 2025-07-30T08:56:22Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+      "! <p class="shorttext">General Information</p>
+      "! General Information contains details about the transaction, depending on the transaction type.
+      "! $required
+      general_information TYPE ty_impl,


Suggested change

general_information TYPE ty_impl,

general_information TYPE ty_general_information,

Do you think this is better? at least now the name and the type are matching. Maybe:
implementation TYPE ty_implementation

GuilhermeSaraiva96 · 2025-07-30T09:00:47Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    "! Authorization default values define which authorization objects and field values are automatically
+    "! proposed when creating roles for a transaction,
+    "! simplifying role maintenance and ensuring consistent security settings across users and roles.
+    BEGIN OF ty_ad_ao,


ty_auth_defaults_obj_details

GuilhermeSaraiva96 · 2025-07-30T09:02:28Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+  TYPES:
+      "! <p class="shorttext">Authorization Defaults Authorization Field Values</p>
+      "! Authorization defaults authorization field values
+    ty_ad_afv_t  TYPE STANDARD TABLE OF ty_ad_afv  WITH DEFAULT KEY.


Suggested change

ty_ad_afv_t TYPE STANDARD TABLE OF ty_ad_afv WITH DEFAULT KEY.

ty_auth_def_field_values_t TYPE STANDARD TABLE OF ty_auth_defaults_field_values WITH DEFAULT KEY.

GuilhermeSaraiva96 · 2025-07-30T09:08:30Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    "! A start authorization object controls who may run a transaction. It is checked at transaction start.
+    "! Fields must have single or empty values. Empty fields trigger a DUMMY check.
+    "! This object is auto-assigned in the authorization defaults transaction.
+    BEGIN OF ty_sao,


Suggested change

BEGIN OF ty_sao,

BEGIN OF ty_start_auth_object,

GuilhermeSaraiva96 · 2025-07-30T09:09:42Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+  TYPES:
+    "! <p class="shorttext">Authorization Value</p>
+    "! Authorization value
+    ty_val   TYPE c LENGTH 40,


Suggested change

ty_val TYPE c LENGTH 40,

ty_auth_value TYPE c LENGTH 40,

GuilhermeSaraiva96 · 2025-07-30T09:10:21Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    ty_val   TYPE c LENGTH 40,
+    "! <p class="shorttext">Authorization Field</p>
+    "! Authorization field
+    ty_field TYPE c LENGTH 10.


Suggested change

ty_field TYPE c LENGTH 10.

ty_auth_field TYPE c LENGTH 10.

Here we have directly used the defining data elements instead of introducing our own data elements.
We should think about that. Having
STRAN_SOA_AUTH_FIELD_NAME
STRAN_SOA_AUTH_FIELD_VALUE
and related ty_... would be the consequence

GuilhermeSaraiva96 · 2025-07-30T09:11:31Z

file-formats/tran/type/zif_aff_tran_v1.intf.abap

+    END OF ty_par.
+
+  TYPES:
+    BEGIN OF ty_var,


Suggested change

BEGIN OF ty_var,

BEGIN OF ty_variant_transaction,

WDFYvonne added 9 commits January 5, 2023 16:13

React to abaplint

07c3c46

Merge branch 'SAP:main' into main

8c0cd56

Merge branch 'SAP:main' into main

eed0397

Merge branch 'SAP:main' into main

5e8a46f

Merge branch 'SAP:main' into main

2a6bfde

Add fildes for TRAN

630dd2f

React to abaplint

d663b3b

React of abaplint 2

fcb415b

React to abaplint

feea4b7

WDFYvonne added 5 commits July 24, 2025 15:29

React of abaplint 2

21a23c2

New types in AFF interface

2b468bd

Delete of SUSH

f374af9

Add example for TRAN

6a84f16

React to EditorConfig

65e5e7c

larshp reviewed Jul 25, 2025

View reviewed changes

file-formats/tran/tran/README.md Outdated Show resolved Hide resolved

WDFYvonne added 3 commits July 25, 2025 15:26

React to JSON examples

d7b5eb9

React to validate JASON Examples

9604e30

React to error

e6162f1

WDFYvonne and others added 9 commits July 28, 2025 10:03

Merge branch 'main' into feature/tran

346cc57

Correct AFF

48237f3

React to Validate examples against schema

61a3cdf

React to Validate examples against schema

539934b

React to check markdown

8449a51

New type in AFF

9f652e7

New Type in AFF

020596d

New Type in AFF

2d6ec4e

Merge branch 'main' into feature/tran

0b2887f

Markus1812 reviewed Jul 29, 2025

View reviewed changes

GuilhermeSaraiva96 requested changes Jul 30, 2025

View reviewed changes

	oo_transaction_model_indi TYPE abap_bool,
	oo_transaction_model TYPE abap_bool,

	var_parent_transaction_code TYPE c LENGTH 20,
	parent_transaction_code TYPE c LENGTH 20,

	transaction_variant_ci_indi TYPE abap_bool,
	is_cross_client TYPE abap_bool,

	TYPES ty_ua_pervasive_mode TYPE c LENGTH 1.
	TYPES ty_ui_attr_pervasive_mode TYPE c LENGTH 1.

	general_information TYPE ty_impl,
	general_information TYPE ty_general_information,

	ty_ad_afv_t TYPE STANDARD TABLE OF ty_ad_afv WITH DEFAULT KEY.
	ty_auth_def_field_values_t TYPE STANDARD TABLE OF ty_auth_defaults_field_values WITH DEFAULT KEY.

[TRAN] Add new object type TRAN #713

Are you sure you want to change the base?

[TRAN] Add new object type TRAN #713

Uh oh!

Conversation

WDFYvonne commented Jul 24, 2025

Uh oh!

WDFYvonne commented Jul 24, 2025

Uh oh!

Uh oh!

WDFYvonne commented Jul 28, 2025

Uh oh!

Markus1812 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peter-dell-sse Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WDFYvonne commented Jul 30, 2025

Uh oh!

GuilhermeSaraiva96 commented Jul 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peter-dell-sse Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

peter-dell-sse Jul 31, 2025 •

edited

Loading

peter-dell-sse Jul 31, 2025 •

edited

Loading