Let me first start with the following question: Why in God’s name would someone be interested in this kind of information in the first place? Well –let me tell you that whenever you encounter a certain “bug” in your system (especially the type where you have an issue for a specific user –that is using the same SAP CRM business role –has the same authorizations, and you are trying to figure out what is going on – you are struggling to find a solution – you are looking for the needle in the haystack) than at this point the information below “might” be very relevant for you.
Just to cut to the chase – at my current customer we have noticed multiple times that certain functionalities in SAP CRM were not behaving in the same way as they were supposed to – e.g. email behavior in the ERMS context, but also other things. If you notice that out of 50 users 48 do not have an issue with this functionality – and the only different but obvious thing you notice immediately is that this user is not using the same Skin, than I can tell you – God has its mysterious ways – but so does SAP. For me – a skin is a skin – and should Not have any influence whatsoever on a business process, but apparently this can happen.
For your information: at this particular customer we have created only 1 custom made specific skin. As all end-users are expected and supposed to use that skin, we clearly only perform unit and integration testing on our development and acceptance system, using that same skin. (but you know end-users I guess …they always play with new tools)
1. Finding that personalization table
As we noticed once again some user was stubborn, and decided to change skins, we now wanted to actually “find” back who was using the Customer Skin or not...so we needed to find out in which table this information was stored.
On a regular basis I have some sort of game/competition where a colleague and I try to solve an issue or in this case find an answer the quickest. As my colleague Rob has more experience in debugging (he has developed in the past) he usually starts his “quest” using the debug style ….
As a functional consultant I use other approaches (although it usually includes some debugging…as a last resort –as my colleague would obviously beat me on that particular topic).
- I looked at the technical details of the view that allows Skin Personalization. Using the F2 button, I quickly found out the component/view information: CRM_BSP_PERS/Layout
- I next quickly checked the class of this view using the BSP component workbench (BSP_WD_CMPWB): CL_CRM_BSP__LAYOUT_IMPL
- I next moved on to SAP OSS notes (my biggest source in finding relevant technical information). Looking at notes relevant to Skin changes/issues, I then would quickly check if I could find a relevant class/function module/method that I can check via SE24/SE37/SE80/…. By looking at the code of such a method or function module I was hoping to find the relevant table. Well – I found 2 useful classes/methods –but still had troubles finding the relevant table.
- Now my time was ticking away–and I tried an ST01 or ST05 table trace (SQL).
In the output of this trace there were quite some tables, so I quickly tried to scan them via transaction code SE11/S16. Suddenly I heard my colleague say – hey Davy – I found the table. When he mentioned the name I got a bit frustrated, as 2 minutes earlier I actually already had a brief look at that particular table, but thought it was not the relevant one…if you look at how you need to look up the skin details by user –than you’ll probably understand why I overlooked it in my haste.
We found out a lot of personalization objects of a user are stored in table SPERS_OBJ. Below some of the things you can find in this table are displayed.
Go to the table SPERS_OBJ using transaction code SE11 or SE16 and display the data browser:
Use CRM_THTMLB_PERS_SKIN as PERS_KEY and enter the user ID as OBJECT_ID:
Executing this results in getting the value of the skin personalization for this user in the field FIELDVALUE (in this case default):
In the SAP CRM WEBUI, choose “Personalize” in order to personalize the skin:
In table SPERS_OBJ we can now see that the value has changed (HIGH CONTRAST in this example:
Text Size settings/personalization:
In table SPERS_OBJ, use CRM_THTMLB_PERS_FSIZ as PERS_KEY to find the text size for a specific user:
The first performance setting can be found using CRM_THTMLB_PERS_NOEF as PERS_KEY in table SPERS_OBJ:
The second performance setting can be found using CRM_CONFIG_MODE_ENABLED as PERS_KEY in table SPERS_OBJ:
Recent Items settings/personalization:
Choose ‘Recent Items’ in the dropdown list:
The chosen options are all stored in table SPERS_OBJ. Use PERS_KEY CRM_PERS_RECENT_OBJECTS. Per profile you’ll find three values that return in the field FIELDNAME:
- HIDDEN: The opposite of the value of the checkbox that indicates whether the recent items should be displayed or not
- MAX_NUM: The number of entries that are displayed as recent items
- PROFILE: The profile the personalization of recent items is valid for (e.g. SALESPRO)
2. Hide skins
As a second topic of this article, I will show you how to hide certain skins. For our earlier problem, this seems the best way to avoid any future problems due to using a different skin.
Let’s assume I want to disable the skin “Serenity”.
First of all, find out the name of the skin you want to hide from the personalization settings. Do this by using following path in transaction code SPRO:
The table in which you can define which skins should be “disabled” is
Maintain table CRMC_THTMLB_SKNE in transaction code SM30:
Choose new entries and add the skins you want to hide/deactivate:
Using the input help, I now can see the list of available skins:
As I want to ‘disable’ SERENITY for this example, I select it.
Now I log-off and on again, I check the result in the CRM WEBUI.
Great – Serenity is no longer visible in the list – as you can see in below screenshot.
Cheers and talk to you soon
The SAP University Team