Introduction

In my previous blog post ‘Suppression Rules: Methods, Tips and Tricks‘ I explained the usage of the suppression BAdI to create rules for suppression of contacts from campaign execution. If you did not read that post I recommend to read it before continuing with this post. One of the topics I briefly touched in that first post was a concept on how to separate suppression parameters from the pure BAdI logic.

Usually you don’t want to give your business users access to edit such BAdI logic to tune certain parameters. It would be confusing and a source for errors. Therefore I recommend to setup a custom business object (CBO) for those parameters:

1. Specify the use case to derive the structure of the CBO
2. Create a CBO which includes the desired parameters as fields. It is easy to generate a UI for this where you can then add new entries as a line with multiple columns. Then add the generated UI to a business catalog to give your business users the possibility to maintain those parameters.
3. Develop a generic code inside your suppression BAdI which reads line by line of your CBO and executes the suppression logic accordingly.

In the following sections I will explain the procedure in more detail.

Specification (Example scenario)

During the course of this post I will use a scenario which is very commonly used. I assume that you want to restrict the execution of a campaign action (For example send email) if there had been a certain number of interactions (For example any outbound email) in a certain period. As a side condition I also want to consider the marketing area of the currently executed campaign.

This leads me to the following parameters which a business user might want to maintain:

• Marketing area of the executed campaign
• Campaign action in the executed campaign
• Interaction type of past interactions which need to be checked
• Period of time in which to check those interactions
• Count of allowed interactions in the checked period

Creation of CBO for Suppression Parameters

You start with the ‘Custom Business Objects’ app in group ‘Extensibility:

Then you give your new CBO an ID and a descriptive name:

Next, you need to specify certain features of your CBO. A necessary feature is ‘UI Generation’ because you’ll need a UI to maintain your suppression parameters. Additionally I recommend ‘System Administrative Data’ which automatically adds the fields to capture creation and change data (date/time and user):

The next step is adding the fields you need for your scenario. The first field should be an ID marked as key field. This field should be a text field to allow for some descriptive information. For my scenario I added the fields which I mentioned above. For the fields ‘Campaign Action’ and ‘Interaction Type’ I used a normal text field here, but I would recommend to use code lists (To be created in the app ‘Custom Reusable Elements’) in your productive system instead to avoid user error. I added the field ‘SuppressionCount’ as a number with no decimals. For the field ‘SuppressionDays’ I chose a number with decimals to allow also periods smaller than a day for my scenario (also useful during testing). Also notice the administrative fields that had been added automatically.

After you have done these steps you need to publish your CBO. After waiting for some time you will find two links in the tab ‘General Information’ for the generated UI and the maintenance of the catalogs:

For test purposes you can just use the link for the generated UI here but for your business users you’ll need to add the UI to at least one of your business catalogs. To do this you just click on the second link ‘Maintain Catalogs’. In my example I have chosen to use the catalog ‘Marketing – Segmentation and Campaign Configuration’:

After publication of that catalog assignment your business users will find the new app in the Fiori launchpad:

Using this new app you can now enter your suppression parameters like so:

Please note that the administrative data is captured automatically.

With this you can now continue to define the suppression logic in the BAdI.

Implementation of Suppression BAdI

In this section I will do a step-by-step explanation of the coding needed to read the CBO data and use that data in the suppression logic. Please note that the coding shown here does not come with any warranty. Use at your own risk and test it thoroughly!

First you need to do the initial declarations as described in the example coding:

DATA(factory)   = cl_cuan_sr_badi_api_factory=>get_instance( ).

DATA(read)      = factory->create_reader( ).
DATA(suppress)  = factory->create_suppressor( ).
DATA(allow)     = factory->create_allowance( ).
DATA(calculate) = factory->create_calculator( ).
DATA(calendar)  = factory->create_calendar( ).

suppression_rules_result = suppression_rules_input.

Next you also need to retrieve the campaign data:

DATA(campaign) = read->campaign( campaign_id ).

Now it is time to read the CBO parameters:

SELECT * FROM YY1_SR_PAR_1
      WHERE CampaignAction        EQ @action_id
        AND CampaignMarketingArea EQ @campaign-marketingarea
   INTO TABLE @DATA(parameters).

With the WHERE statements you only read those lines in the CBO data which are relevant for your currently executed campaign. You only want those lines for the current campaign action and the marketing area of your current campaign. All those lines are stored in the local table ‘parameters’.

Now you need to loop over each line of the parameter table and execute the suppression:

LOOP AT parameters ASSIGNING FIELD-SYMBOL(<parameter>).

   suppress->with_recent_interactions(
      EXPORTING
         interaction_type = <parameter>-interactiontype
         period           = 24 * 60 * 60 * <parameter>-SuppressionDays
         count            = CONV #( <parameter>-SuppressionCount )
      CHANGING
         results          = suppression_rules_result
   ).

ENDLOOP.

First I assign the parameters of each line to the field symbol ‘<parameter>’. Then I the suppression method ‘with_recent_interactions’ that had been already explained in my last post. For the interaction type I use the one derived from the CBO (‘<parameter>-interactiontype’). For the period I did not use one of the convenience methods (For example calculate->period_days) because those methods need a value without decimals. Since I wanted more flexibility here I do the calculation of seconds with a formula. For the count value a conversion is needed due to a format conflict.

Finally I give you the complete code of this scenario:

DATA(factory) = cl_cuan_sr_badi_api_factory=>get_instance( ).

DATA(read) = factory->create_reader( ).
DATA(suppress) = factory->create_suppressor( ).
DATA(allow) = factory->create_allowance( ).
DATA(calculate) = factory->create_calculator( ).
DATA(calendar) = factory->create_calendar( ).

suppression_rules_result = suppression_rules_input.

DATA(campaign) = read->campaign( campaign_id ).

SELECT * FROM YY1_SR_PAR_1
	WHERE CampaignAction EQ @action_id
	  AND CampaignMarketingArea EQ @campaign-marketingarea
	INTO TABLE @DATA(parameters).

LOOP AT parameters ASSIGNING FIELD-SYMBOL(<parameter>).

	suppress->with_recent_interactions(
	  EXPORTING
		interaction_type = <parameter>-interactiontype
		period           = 24 * 60 * 60 * <parameter>-SuppressionDays
		count            = CONV #( <parameter>-SuppressionCount )
	  CHANGING
		results          = suppression_rules_result
	).

ENDLOOP.

ENDIF.

Conclusion

After reading this post you should be able to implement suppression logic using parameters from a custom business object. Of course you can also use multiple CBOs for different scenarios and use them in a single BAdI implementation.