The Use of RTTI in Update Rules

SAP Developer Network

Summary

Run-Time Type Identification (RTTI) technology, first available in release 4.6C, initiated dynamic runtime metadata recognition capabilities in ABAP. RTTI simplifies configuration, maintenance, migration, and upgrade of update/transfer rules and enables non-programmers to maintain their data models with ease.

By Scott Cairncross

13 May 2004

 

The advent of Run-Time Type Identification (RTTI) technology to ABAP gave SAP developers the capability to determine the type of a structure, table, or data element from data itself. RTTI first became available in release 4.6C, giving the SAP BW developer dynamic runtime metadata recognition capabilities to the ABAP programming language for the first time.

This capability to dynamically determine a type of an object at runtime can be utilized to simplify the configuration, maintenance, migration, and upgrade of update/transfer rules. This simplification can allow a few technical consultants to create an array of update rule 'tools' that non-programmers as well as ABAP savvy consultants can maintain with ease in their own data models.

A common transformation is an InfoProvider lookup in ordern order to join data into the same data target. Retrieving data from an ODS Object or InfoCube while loading another data target is an extremely useful utility to have as an alternative to InfoSets.

The scenario is the following: There exists additional characteristic detail within the second InfoCube shown above that is needed in order to support reporting off of the first InfoCube. For example, purchase order details need to be merged with financial line-items to provide an integrated historical view of summarized logistic and financial information for vendor evaluations. In this example, the source ODS object contains financial document line items. The second InfoCube (or the 'lookup' InfoCube) contains purchase order details such as purchase order type. The common link between the source ODS object and the lookup InfoCube is the purchase order itself.

On the load from source ODS Object into the data target InfoCube the data required from the lookup InfoCube is read into an internal table within the start routine to reduce the number of database reads (as opposed to performing this database selection within each characteristic routine in the update rules). The database selection in the start routine of this example uses purchase order in the 'where' clause.

Within the individual characteristic routines (eg. Purchase order type), reads are performed off of this internal table (i.e. the purchase order details loaded into memory via the start routine).

Without hard-coding the actual fieldnames for purchase order type how does one dynamically determine the fieldname for purchase-order type at runtime? In other words, once the Purchasing InfoCube is read, how might the system automatically map the values for purchase-order type from the retrieved records?

The answer is with RTTI. RTTI can then dynamically map the field value in the InfoCube lookup to the data target field value. For one characteristic, RTTI may seem excessive. However, if there are many other fields beside purchase order type in the lookup and additional data load scenarios that need lookups with other fields then RTTI is a time saver. Only one routine needs to be written that handles all data scenarios. In the code example below, an include program was written that was reused and shared across multiple characteristic routines across multiple update rules.

Below is two snippets of code from this include program for a characteristic routine. The first routine is an update rule characteristic routine that dynamically determines the corresponding characteristic. The second routine transforms the characteristic name into an InfoObject name, which is then subsequently converted into a fieldname (important for mapping to the communication structure).

Code Extract of an InfoObject Routine

data: lr_descr_ref type ref to cl_abap_typedescr,
      l_type(50) type c,
      l_iobjnm type rsiobjnm,
      l_field type fieldname.
				
				
* determine infoobject type
lr_descr_ref = cl_abap_typedescr=>describe_by_data( result ).
l_type = lr_descr_ref->get_relative_name( ).
				
* get the infoObject name of the routine that is currently being executed
call method zcl_utilities=>iobjtyp_to_iobjnm
    exporting
      i_iobjtype    = l_type
    importing
      e_iobjnm      = l_iobjnm
    exceptions
      invalid_input = 1
      others        = 2.
            
call function 'RSD_FIELDNM_GET_FROM_IOBJNM'
    exporting
      i_name         = l_iobjnm
    importing
      e_ddname       = l_field
    exceptions
      name_error     = 1
      prefix_invalid = 2
      others         = 3.
				

Code Extract of the static method called within the InfoObject Routine

method iobjtyp_to_iobjnm .
				
  data: l_fieldname type rs_char30,
          l_vers type numc4,
          l_iobjnm type rs_char30,
          l_junk(5) type c.
				
  clear l_fieldname.
  if i_iobjtype(5) eq '/BI0/'.
    split i_iobjtype at '/BI0/OI' into l_junk l_fieldname.
				
    if sy-subrc ne 0.
      raise invalid_input.
      exit.
    endif.
				
    call function 'RSD_IOBJNM_GET_FROM_FIELDNM'
      exporting
        i_ddname = l_fieldname
      importing
        e_name   = l_iobjnm.
				
    e_iobjnm  = l_iobjnm.
				
  elseif i_iobjtype(5) eq '/BIC/'.
    split i_iobjtype at '/BIC/OI' into l_junk l_fieldname.
				
    if sy-subrc ne 0.
      raise invalid_input.
      exit.
    endif.
				
    e_iobjnm = l_fieldname.
  else.
    raise invalid_input.
  endif.
				
				
endmethod.
				
				

Once the InfoObject name is determined it can be used to determine its corresponding fieldname and the necessary information can then be extracted from within the internal table. A single include, ZUPDR_LOOKUP_IOBJ_GET, can then be placed within any InfoObject routine without any additional configuration, and the routine will figure out what field to pull from the internal table with ODS Object data.

This is a very simple trick, but it has simplified configuration greatly at client sites and eliminates the possibility of a user making a mistake when they are hard coding another infoObject name.

About the Author

Scott Cairncross is a senior SAP SEM and BW consultant with Inforte Corp. Scott works at NASA as a lead SEM/BW ABAP architect on the Budget Formulation project. Previously Scott worked with NASA on their enterprise implementation of SAP BW designing and realizing the transformation logic and custom extractors that interfaced NASA's R/3 system with their data warehouse.

About Inforte

Inforte Corp. is a customer strategy and solutions consultancy that helps clients improve performance by tying together customer and corporate strategy. Inforte combines strong business and operational planning with innovative software solutions to ensure its Global 2000 client-base serves the right customers in the right ways to generate the greatest return.

Code samples are intended for educational use only, not deployment. They are untested and unsupported by SAP. SAP disclaims all liability to any person in respect to any damage that is incurred, whether wholly or partially, from use of the code.

Table of Contents



Related Content:



Content Options

Copyright © 2005 SAP AG, Inc. All Rights Reserved. SAP, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product, service names, trademarks and registered trademarks mentioned are the trademarks of their respective owners.

SAP Developer Network