Technical Articles
Suppression: Separating Business Parameters from BAdI Coding using a Custom Business Object
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:
- Specify the use case to derive the structure of the CBO
- 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.
- 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.
Hi Arne,
This is awesome…easy now...Just change the parameter rather than code! Excellent!!!
Thanks,
Harshad Patel
Hi Arne,
I have a customer that need to blacklist more that 100,000 customers to be blacklisted, do think we can use this approach?
Now we have a limit of 100, 000 records in the Blacklist Tile, so I’m consider if I can upload all the customers into a CBO and implement this Badi to verify if the customer is in the CBO and removed from the campaign execution.
Thanks
Karla Armendariz
Hi Karla,
I suggest that you first try the standard blacklist app for this. There you are also able to import a CSV file 🙂
Best Regards,
Arne
Hi Arne,
True, we can upload a .csv in the Exclusion list / Blacklisting app. However, a single line is then created for each specific contact. When we then want to remove the exclusion, it takes a lot of manual efforts to do so.
Is there something that I missed with the .csv upload or is that expected?
Thank you!
Kevin
Hi Kevin,
I am replacing Arne on this topic. As mentioned in our online documentation Campaign Execution Exclusion List - SAP Help Portal , you can also maintain email domains: "With the Campaign Execution Exclusion List app you can maintain full specified email addresses, email domains, and mobile phone numbers that shall be excluded within campaign actions Send Email or Send Text Message." However, we don't currently offer the possibility to exclude email addresses with a pattern, for example.
Best Regards
Isabelle
Very Nice block Arne
what we have to change on suppresion custom code and custom CBO if in common scenario
we have a IF campaign-marketingarea EQ 'X' and we need suppress all contact to that have an interaction_type = 'MKT_PERM_OPTOUT' and marketingarea of the interaction was EQ 'X'
OR
we have a IF campaign-marketingarea EQ 'Z' and we need suppress all contact to that have an interaction_type = 'MKT_PERM_OPTOUT' and marketingarea of the interaction was EQ 'Z'
Best regards
Hi Enrique,
sorry, but what you are asking for is specific consulting for your use case and I cannot give you that.
Best regards,
Arne
Just came across this interesting and useful blog. I am however unable to see the 'UI generation' and 'Data access management' checkboxes when I am creating the CBO. We are on S4HANA 2021. Are those options no longer available?
Thanks,
Sri
Hi,
If you are using an on-premise deployment, this is not available. Those options are only available for the Cloud deployment. See S/4 HANA On-Premise In-App Key User Extensibility – Custom Business Objects | SAP Blogs
Best Regards
Isabelle
Thanks Isabelle!