Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member209703
Active Contributor

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                   = 0

ENDFORM.                               " 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.

2 Comments