Using HRDSYS Logical information Objects in a Custom Table Maintenance Dialog
Applies to: SAP ECC 6.0, SAP NW 7.0
This document explains how to use HRDSYS Logical Information Objects to link and store documentation text associated with an entry of a custom database table through its maintenance dialog, the same way it is been done by standard tables like V_T511K
Introduction
Sometimes, there is a requirement to store long descriptions or even text with format along with a database table record. This can be achieved in different ways, but when we are dealing with a Customizing table and all the records and all the associated documentation need to be transported to the Integration or Production environments, HRDSYS functionality gives us a very powerful tool to do it and with a high degree of transparency.
Audience
ABAP Technical Consultants
Purpose
The purpose of this document is to provide an option to attach a long text description to be shown as part of a table record while maintaining/displaying the Table/View through the SM30 transaction the very same way SAP does in several standard Tables/Views like the Payroll parameters View V_T511K
Dependencies / Pre-requisites / Assumption
Basic understanding of ABAP Programming and ABAP Dictionary is necessary to understand the process and the concepts used in this article.
Technical Process
Customizing Steps
First of all we need to create a Custom Document Class (in our case its name will be ZTEST). We can do that through the HR Documentation Maintenance (PDSY). Then we go to Extras à Document Class, and here we can create a new Document Class which it will be used to associate all the text description we’re going to store/retrieve.
Note: In the field Object table, we have to introduce the name of our custom table. In this scenario, it would be ZTEST_HRDSYS. Note that this table must be already created and activated. We can also define a template, by clicking on the template button in the toolbar, so every time we need to create a new text for a record this default template will show up.
Development Steps
For demonstration purposes, we are going to use a Customizing Database Table with the following fields:
The next step will be to generate the Maintenance Dialog through Utilities à Table Maintenance Generator (this will be done as usual) and access it via SM30, so we can edit the default dynpro and add the button we are going to use to edit/show the HRDSYS documentation. (These steps will be omitted) The final appearance of the dynpro will be this (The position of the Info button in the screen is not relevant):
Note: When editing this dynpro, we will assign the function code %%%% to the new Info Button
After all these steps, we’ll begin to write some ABAP code to link our table with the custom documentation object we’ve just created before. The first step will be to create a new Input Module in the default dialog screen. (It will be created at the very bottom of the After Input Process) We also have to create another PBO Module, so the button remains pushable when we are in display mode.
In the new input module we are going to use the standard FM HRDSYS_VIEW_DOCU_EDIT_2. This Function Module will manage the display/edit options of our HRDSYS objects. Note that all the parameters we need are global and available in our Maintenance dialog Function Group, so there’s no need to declare any variables at all. We just have to specify our custom documentation object, in this case ‘ZTEST’ under the parameter ‘OTYPE’, and the two key fields of our database table, in our case INFTY and SUBTY, under the ofield1 and ofield2 parameters. Also note that as we haven’t checked the country dependency option while creating our documentation class, there’s no need to use the MOLGA parameter.
Note: As you could have seen, there’s a limitation on the number of key fields we can use to associate a documentation object to. We can only use two key fields to generate different text objects, which in most cases is more than sufficient.
After having done all this, we are now able to create different documentation objects for each row, but we have something still missing: we need to be able to transport all this long text along with a customizing request.
To do this, we need to use the following SAP standard FMs:
- HRDSYS_VIEW_INITIALIZE
- HRDSYS_VIEW_TRANSPORT_2
- HRDSYS_VIEW_COPY_MARK_2
- HRDSYS_VIEW_DELETE_WARNING
- HRDSYS_VIEW_DELETE_WARNING_2
- HRDSYS_VIEW_SAVE_02
- HRDSYS_VIEW_SAVE_01_2
We’re going to embed all this FM’s in subroutines that will be called dynamically by the standard dialog maintenance control program the very same way it is been done in all standard maintenance views. To do that we have to specify which routines will be executed for the corresponding events. This can be done maintaining the standard view V_TVIMF.
Then the final step would be to create all those subroutines in a new include, so they will be called dynamically by the control program when it’s needed.
* base table related FORM-routines………….
INCLUDE lsvimftx .
***INCLUDE L0P11F01 .
FORM f_hrdsys_save_01. “WLIAHRK031345
CALL FUNCTION ‘HRDSYS_VIEW_SAVE_01_2’
EXPORTING
ofield1 = ‘INFTY’ofield2 = ‘SUBTY’
action = <action>
vim_total_struc = <vim_total_struc>
TABLES
total = total
* x_namtab = x_namtab
hrdsys_actions = hrdsys_actions
EXCEPTIONS
fieldname_error = 0
OTHERS = 0.
ENDFORM. ” f_hrdsys_save_01
*
FORM f_hrdsys_save_02. “WLIAHRK031345
CALL FUNCTION ‘HRDSYS_VIEW_SAVE_02’
EXPORTING
otype = ‘ZTEST’
corr_nbr = <status>–corr_nbr
TABLES
hrdsys_actions = hrdsys_actions.
ENDFORM. ” f_hrdsys_save_02
FORM f_hrdsys_save_02_skoc. “WLIPH9K003905
CALL FUNCTION ‘HRDSYS_VIEW_SAVE_02’
EXPORTING
otype = ‘ZTEST’
corr_nbr = <status>–corr_nbr
TABLES
hrdsys_actions = hrdsys_actions.
ENDFORM.
FORM f_hrdsys_delete_warning.
CALL FUNCTION ‘HRDSYS_VIEW_DELETE_WARNING_2’
EXPORTING
ofield1 = ‘INFTY’
ofield2 = ‘SUBTY’
vim_total_struc = <vim_total_struc>
vim_extract_struc = <vim_extract_struc>
vim_xextract_key = <vim_xextract_key>
TABLES
extract = extract
total = total
CHANGING
xmark = <xmark>.
CALL FUNCTION ‘HRDSYS_VIEW_DELETE_WARNING’
TABLES
extract = extract
CHANGING
xmark = <xmark>.
ENDFORM. ” f_hrdsys_delete_warning
FORM f_hrdsys_copy_mark.
FIELD-SYMBOLS: <viewline>.
ASSIGN (x_header–maintview) TO <viewline>. ” WLIK033680
CALL FUNCTION ‘HRDSYS_VIEW_COPY_MARK_2’
EXPORTING
status_action = status–action
viewline = <viewline>
vim_extract_struc = <vim_extract_struc>
ofield1 = ‘INFTY’
ofield2 = ‘SUBTY’
TABLES
hrdsys_actions = hrdsys_actions
EXCEPTIONS
fieldname_error = 0
OTHERS = 0.
ENDFORM. ” f_hrdsys_copy_mark
FORM f_hrdsys_transport.
CALL FUNCTION ‘HRDSYS_VIEW_TRANSPORT_2’
EXPORTING
otype = ‘ZTEST’
ofield1 = ‘INFTY’
ofield2 = ‘SUBTY’
xmark = <xmark>
corr_action = corr_action
status_action = status–action
e071k = e071k
vim_extract_struc = <vim_extract_struc>
TABLES
corr_keytab = corr_keytab
EXCEPTIONS
fieldname_error = 0
OTHERS = 0.
ENDFORM. ” f_hrdsys_transport
FORM f_hrdsys_transport_skoc. ” WLIPH9K003905
CALL FUNCTION ‘HRDSYS_VIEW_TRANSPORT_2’
EXPORTING
otype = ‘ZTEST’
ofield1 = ‘INFTY’
ofield2 = ‘SUBTY’
xmark = <xmark>
corr_action = corr_action
status_action = status–action
e071k = e071k
vim_extract_struc = <vim_extract_struc>
TABLES
corr_keytab = corr_keytab
EXCEPTIONS
fieldname_error = 0
OTHERS = 0ENDFORM. ” f_hrdsys_transport_skoc
FORM f_hrdsys_initialize.
CALL FUNCTION ‘HRDSYS_VIEW_INITIALIZE’
TABLES
hrdsys_actions = hrdsys_actions
transport_docu = hrdsys_transport_objects
corr_keytab = corr_keytab.
ENDFORM. ” f_hrdsys_initialize
We have to declare this tree variables in the TOP include.
After all this, we can test our maintenance dialog, create as many entries as we need and of course the associated document objects. After saving everything, we can check the customizing change request and see, that along with the table entries there are some HRDSYS Logical Object entries that have been created.
The final step would be to transport this change request to the Integration Environment and see that all the entries and custom text objects have been transported successfully.
nice work
Wow, looks really fat!