[AIFA] Add new object type #703
Conversation
| BEGIN OF ty_fields_restore, | ||
| "! <p class="shorttext">Field Name</p> | ||
| "! Field name | ||
| field_name TYPE c LENGTH 255, |
There was a problem hiding this comment.
| field_name TYPE c LENGTH 255, | |
| name TYPE c LENGTH 255, |
| BEGIN OF ty_fields_restore, | ||
| "! <p class="shorttext">Field Name</p> | ||
| "! Field name | ||
| field_name TYPE c LENGTH 255, |
There was a problem hiding this comment.
Is this length correct? 255
There was a problem hiding this comment.
IN the future it will be field path. In case we have a deep structure with many substructures the path will be longer than char 40.
| "! <p class="shorttext">AIF Action</p> | ||
| "! AIF action | ||
| "! $required | ||
| aif_action TYPE c LENGTH 20, |
There was a problem hiding this comment.
Is the aif_action the name of the object instance itself?
| "! <p class="shorttext">Check</p> | ||
| "! Check | ||
| "! $required | ||
| check_obj_name TYPE zif_aff_types_v1=>ty_object_name_30, |
There was a problem hiding this comment.
| check_obj_name TYPE zif_aff_types_v1=>ty_object_name_30, | |
| check TYPE zif_aff_types_v1=>ty_object_name_30, |
It is implicit that refers to the name of the check object
| "! <p class="shorttext">Field Name</p> | ||
| "! Field name |
There was a problem hiding this comment.
| "! <p class="shorttext">Field Name</p> | |
| "! Field name | |
| "! <p class="shorttext">Fields</p> | |
| "! Fields |
| "! <p class="shorttext">Check Data</p> | ||
| "! Check data |
There was a problem hiding this comment.
| "! <p class="shorttext">Check Data</p> | |
| "! Check data | |
| "! <p class="shorttext">Checks</p> | |
| "! Checks |
| field_restore TYPE ty_fields_to_restore, | ||
| "! <p class="shorttext">Checks</p> | ||
| "! Checks | ||
| check_data TYPE ty_checks, |
There was a problem hiding this comment.
| check_data TYPE ty_checks, | |
| checks TYPE ty_checks, |
| general_information TYPE ty_general_information, | ||
| "! <p class="shorttext">Fields To Restore</p> | ||
| "! Fields to restore | ||
| field_restore TYPE ty_fields_to_restore, |
There was a problem hiding this comment.
| field_restore TYPE ty_fields_to_restore, | |
| fields_to_restore TYPE ty_fields_to_restore, |
| general_information TYPE ty_general_information, | ||
| "! <p class="shorttext">Fields To Restore</p> | ||
| "! Fields to restore | ||
| field_restore TYPE ty_fields_to_restore, |
There was a problem hiding this comment.
What are these fields to restore? How do they fit into the workflow of the AIF Action?
There was a problem hiding this comment.
Sometimes, later action classes depend on information calculated by earlier action classes. If a later action class fails and the system restarts, an earlier action class might not run again, causing the needed information to be lost. To prevent errors in the restarted process, a "field to restore" can be used. This field saves the important information, so if an action class needs to be re-run after an error, it can retrieve the saved information and continue correctly.
| "! <p class="shorttext">Number</p> | ||
| "! Number | ||
| "! $required | ||
| number TYPE n LENGTH 3, |
There was a problem hiding this comment.
The table is of type standard, which means that the order of the items in the table define a sequence, which can be used to derive this 'number'. Basically, the first item in the list would be the first check to be performed. In this sense, the 'number' field here be useless. This also makes it more intuitive to use in our Editors. What do you think?
There was a problem hiding this comment.
Hi, I discussed with colleagues, and we agreed that we can remove the number field from the UI.
There was a problem hiding this comment.
Can't another field be the key? For example, the check name. Are you expecting multiple entries with the same check name?
From my point of view, I cannot see the advantage in you keeping this numeric_id, as with the table type standard, there is already an implied id in each data entry.
There was a problem hiding this comment.
Hi, actually we do expect multiple entries with the same check name. We can do same check for few fields. And Field may be longer than 128, because its field path actually. So, 'field path' can't be the key as well. We need number as a key.
|
Hi, we had a long discussion with a team about changes with Action file format and here is the summary: We need number id because it's a key field for our table and its shouldn't be calculated automatically. Earlier it was a key and an order number of a check, we decided to spilt t up and now number field isn't about an order of a check and just a key field. we have a new field for the order, and it will be defined by the order of a check in the table on the UI we will add order changeable to the table for that to happen. Also, there was some discussion about 'number' as a name for this key field on the UI and we think it's not showing what is this field is about. We propose name 'numeric_id', but we are also opened for the discussion. |
No description provided.