Skip to Content

Our team has implemented the social media channel ( for example twitter and facebook) into CRM 7.0 EHP3 ( detail see here)

For product standard requirements, it is necessary to provide our customer the choice to delete the facebook posts and tweets stored in CRM database table according to their dedicated consent requirement. In this blog I will show you how to implement the destruction object for social post destruction. You can follow it to create your own destruction object.

Note

ILM Retention Management is a licensed product, which is really due to the fact that the predecessor to full ILM capability was data archiving which was always included as part of the core suite.

Step1 Create a new entry in tcode DOBJ

/wp-content/uploads/2014/01/clipboard1_363453.png

Double click the created entry, maintain the component for it. In my case I use “Customer Relationship Management” for it.

Also specify the data destruction execution report name.

/wp-content/uploads/2014/01/clipboard2_363454.png

Step2 Do customizing in tcode IRM_CUST

Choose OT_FOR_BS

/wp-content/uploads/2014/01/clipboard3_363473.png

Create a new entry for your destruction object:

/wp-content/uploads/2014/01/clipboard4_363474.png

Double click “Allowed Start Time”, specify which field is considered by ILM framework to judge whether a post could be destructed.

Here I choose the ILM constant CREATION_DATE. It is just a constant but NOT the field of your database table. Later on we will map this constant to the real field of the database table.

/wp-content/uploads/2014/01/clipboard5_363475.png

In “Allowed Policy Category”, choose RTP as policy category.

/wp-content/uploads/2014/01/clipboard6_363476.png

Double click on Object Category-Specific customizing, specify your BOR object name below:

/wp-content/uploads/2014/01/clipboard7_363477.png

Mapping the IRM constant CREATION_DATE to the field of your database table:

/wp-content/uploads/2014/01/clipboard8_363478.png

In my database table I have CREATION_DATE_TIME to store the timestamp of post creation, and UUID for post unique identifier.

/wp-content/uploads/2014/01/clipboard9_363479.png

Specify the key field name of your database table.

/wp-content/uploads/2014/01/clipboard10_363480.png

Till now we have finished all the customizing. The new step is to implement destruction report CRM_SOCIAL_ILM_DES.

Step3 implement destruction report CRM_SOCIAL_ILM_DES

The selection screen of report could be found below. It allows you to specify whether the destruction report is only written into application log, or also output to list besides application log, or only list. The Run comment can enable you to maintain an explanation text of each run so that you can easily find the run information later in application log according to the comment.

/wp-content/uploads/2014/01/clipboard11_363481.png

Most of the jobs have been done via the utility class cl_crm_soc_destruct_ilm_tool. The source code could be find from attachment.

REPORT CRM_SOCIAL_ILM_DES.
INCLUDE crm_social_des_sel.
INCLUDE crm_social_des_f01.

INITIALIZATION.

PERFORM processing_options_text_set.
START-OF-SELECTION.
CALL METHOD cl_crm_soc_destruct_ilm_tool=>run
 EXPORTING
   iv_comment           = p_coment
   iv_test_mode         = p_test
   iv_detail_log_option = space
   iv_output_option     = p_prot_o.

 

The key point is in method PROCESS_POST_WITH_FOLLOWUP. In this method as developer you do not need to check whether a post could be destructed. Instead, you tell the ILM framework which field of database table is used as destruction evaluation and ILM framework will tell you the result whether a post is destructible.

DATA: lv_field_value   TYPE if_lrm_bs_types=>ty_s_tabname_fieldname_values,

lx_rule_exec     TYPE REF TO cx_lrm_rule_exec,

lv_destructible  TYPE lrm_destructible,

dref_uuid        TYPE REF TO crmd_soc_post-uuid,

dref_create_date TYPE REF TO crmd_soc_post-creation_date_time,

dref_type        TYPE REF TO crmd_soc_post-type,

dref_tab         TYPE if_lrm_types=>ty_t_field_value.

CLEAR: lv_field_value, dref_tab, lv_destructible, mt_check_field_values.

lv_field_value-v_table_name = 'CRMD_SOC_POST'.

lv_field_value-v_field_name = 'UUID'.

GET REFERENCE OF iv_key-uuid INTO dref_uuid.

APPEND dref_uuid TO dref_tab.

lv_field_value-t_field_value = dref_tab.

INSERT lv_field_value INTO TABLE mt_check_field_values.

CLEAR dref_tab.

lv_field_value-v_table_name = 'CRMD_SOC_POST'.

lv_field_value-v_field_name = 'CREATION_DATE_TIME'.

GET REFERENCE OF iv_key-creation_date_time INTO dref_create_date.

APPEND dref_create_date TO dref_tab.

lv_field_value-t_field_value = dref_tab.

INSERT lv_field_value INTO TABLE mt_check_field_values.

TRY.

mr_irm->get_retention_rule_f_values(

EXPORTING

ith_field_values       =     mt_check_field_values " field names and values of an instance

IMPORTING

ev_destructible        =     lv_destructible " information about destrucibility

).

CATCH cx_lrm_rule_exec INTO lx_rule_exec.

mr_ilm_destruction_db_run->error( ).

" DO YOUR ERROR HANDLING HERE

RETURN

ENDTRY.

In next blog, I will show you how to test the new destruction object via tcode ILM_DESTRUCTION.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply