Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
JoeGoerlich
Active Contributor
Profile parameters accompany the SAP Basis administrators their entire lives. Still, in many SAP systems one can find sub-optimal handling of those and when it comes to monitoring or compliance checking one may be curious how to determine the currently effective values. This may be from a special interest if one considers to implement a tool for compliance checking.

In this blogpost I like to give a brief overview about profile parameters, maybe some handling tips and evaluate how the effective profile parameter values can be determined.
Please note: This blogpost does not cover the configuration parameters stored in the .ini-files of a SAP HANA database system.

 
Updates:

2023-08-21: Added section for function module PFL_READ_FROM_FILE, PFL_READ_PROFILE_FROM_FILE, PFL_READ_PROFILE_FROM_DB.
2023-07-12: Corrected SAP Instance Agent and GetProcessParameter which displays the dynamic value as well.
2023-03-30: Added note regarding calculation of profile parameter values and usage of variables in formula parameters. Added hint about the change history for dynamic changed parameters.
2022-11-17: Added report RSPFRECOMMENDED and ZSPFRECOMMENDED.
2022-10-25: Added note that changes to default values of profile parameters are announced in the What's New Viewer.
2021-09-09: Added function module ICM_SET_VECTOR_PARM to dynamically change vector parameters for ICM to the corresponding section.
2021-09-08: Added section for function module RSPO_R_SAPGPARAM. Adjusted section for table PAHI.
2021-08-11: Added section about checking profile parameters in SAP HANA 2.0 database using the python program getParameter.py
2021-06-22: Added short section about UI Data Protection Logging for SAP S/4HANA
2021-06-16: Added section about monitoring of Dynamic Parameter changes in the syslog of SAP NW AS ABAP or ABAP Platform
2021-06-01: Added section about checking profile parameters in ABAP on SAP HANA using a sql script
2021-05-23: Refined the details in all check methods.





Effective Parameters


At first we must know that many profile parameters have a so called „kernel default value“. This value is compiled into the kernel and will take effect if it is not overwritten by other means - we will come to that in a few.

We can display the kernel default values of all parameters recognized by the actual SAP kernel for example by running the command sappfpar all on OS-level as user <sid>adm.
Please note: Looking at the output we may find some profile parameters which have no kernel default value and some parameters are entirely unknown to the kernel and therefore are not listed in the output at all. Values for these profile parameters must then be set explicitly in a profile file. An example would be the parameters ccl/* to setup the CommonCryptoLib.

The kernel default values might change with newer releases or patch levels of the SAP kernel. New sub-parameters might be added to existing profile parameters. Furthermore, completely new parameters may be added and in rare cases parameters get removed.
Please note: SAP started to provide a list of what has been changed for profile parameters. We can find this in the What's New Viewer in the section ABAP Server Infrastructure -> Parameter Changes. For example, here.

To make profile parameter values configurable and persistent they have to be stored in the so-called profile files. At system startup the profile parameters’ values are read from those profile files residing on the filesystem. This happens in the following order:























# Identifier Location
1. kernel default value compiled into the kernel
2. default profile

for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/DEFAULT.PFL

for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/DEFAULT.PFL

for SAP Host Agent: n/a
3. Instance profile

for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/$SAPSYSTEMNAME_<instance_name>_<saplocalhost>

for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/$SAPSYSTEMNAME_<instance_name>_<saplocalhost>

for SAP Host Agent: /usr/sap/hostctrl/exe/host_profile

With this, we must keep in mind: A value from the instance profile might oversteer a value from the DEFAULT.PFL. In some cases this may be used by intent.

 

Determine the correct profile for a parameter and use variables to define its value


As a rule of thumb, instance profiles (file name <SID>_<INSTANCE>_<HOST>) should contain only parameters which are specific for the particular instance.
Instance specific parameters can also be shifted into the DEFAULT.PFL if there is a variable available which can be used to make values instance specific while defining them in the DEFAULT.PFL.

To make this concept more clear, I like to give an example for that based on the profile parameter icm/HTTP/logging_<xx>:

We should prefer to set the following in the default profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=$(DIR_LOGGING)$(DIR_SEP)↵
icm_http_server_$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)-%y-%m-%d.log

over setting the following in the instance profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=/usr/sap/NPL/D00/log/↵
icm_http_server_NPL_D00_vhcalnplci-%y-%m-%d.log


In this example, we also made the value independent from the operating system by specifying the path by the variable $(DIR_LOGGING) and the delimiter using $(DIR_SEP). So no matter how many instances our system has, even if heterogenous, we can rely on the desired value will take effect on each instance.
Excursus:

Having a closer look at the kernel default value of the profile parameter DIR_LOGGING we will see that it is specified as $(DIR_INSTANCE)$(DIR_SEP)log. And DIR_INSTANCE is specified as $(DIR_SEP)usr$(DIR_SEP)sap$(DIR_SEP)$(SAPSYSTEMNAME)$(DIR_SEP)$(INSTANCE_NAME). For DIR_SEP the kernel default value is hard coded in the OS-specific SAP Kernel, for Linux it is /.
Knowing this, we can note: even nested usage of variables is possible.

Another example would be the kernel default profile parameters ES/SHM_SEG_SIZE and ES/SHM_MAX_PRIV_SEGS. Both make use of variables. They are so called formula parameters. Their values are determined by using math functions:
ES/SHM_SEG_SIZE = ($(em/blocksize_KB)/1024 * (ceil(max($(ztta/max_memreq_MB) *2, $(abap/shared_objects_size_MB) + $(rsdb/tbi_buffer_area_MB) + 4*($(em/blocksize_KB)/1024)) / ($(em/blocksize_KB)/1024))))

and show that calculated values can be used as variables for further calculations:

ES/SHM_MAX_PRIV_SEGS = (ceil(max($(ztta/roll_extension_dia), $(ztta/roll_extension_nondia)) / (1024*1024 * $(ES/SHM_SEG_SIZE))) + 1)

 

Precisely, there are only very few profile parameters which must be set in the instance profile.
Please note: The only deviation I came across are the rdisp/wp_no_* profile parameters which need to be set explicitly in the instance profile to be recognized correctly by the "Operation Modes and Instances" editor of transaction RZ04. A warning will be displayed if these profile parameters are not present in the instance profile. Even though, the values for these profile parameters would be correctly determined and used if they would be defined in the default profile only.

Some parameters are flagged as system-wide when being displayed in transaction RZ11 and therefore should never be set in any instance profile.

Maintaining profile parameter values


For maintaining profile parameter values, we have basically two possibilities.

  1. Maintain the profile files on the OS-level using your preferred text editor.

  2. Logon to the system and use transaction RZ10.


Please note: In RZ10 the instance profile of the ASCS instance (/usr/sap/<SAPSID>/SYS/profile/<SAPSID>_ASCS<nn>_<hostname>) could be included after implementing SAP Note 2789094.

Profile parameter values become effective during the system startup. Some time this is also referred as 'they become "activated"'.

Change profile parameter values at runtime (Dynamic Parameters)


For some profile parameters it is possible to change their value at runtime. These parameters are known as "Dynamic Parameters". Changes to such dynamic parameters during runtime (aka. "changes in productive operation") are withdrawn after a system restart.

We can change profile parameters via web methods offered by the SAP Instance Agent (aka SAP Start Service):
sapcontrol -nr <Inst-No> -function [SetProcessParameter|SetProcessParameter2]

On AS ABAP, changes during runtime can be performed using transaction RZ11 or function module TH_CHANGE_PARAMETER. For the ICM, vector parameters like icm/HTTP/logging_<xx> can be changed using the Function module ICM_SET_VECTOR_PARM. Some components like the ICM will recognize dynamic parameter changes and will perform a soft-restart, others will just use the new value for their next task execution.
Please note: There are a few profile parameters which allow a change at runtime depending on their current value. Which means, we can change the value from 'a' to 'b' without a restart, but changing back from 'b' to 'a' would need a restart. This is for security reasons.

Transaction RZ11 provides a change history for dynamic changes performed since the last restart of the system. The link to the change history can be found below the "Current Value of Parameter"-table indicated by "Origin of Current Value: Dynamic Switch ( Change History )".
As this link is only displayed if there have been changes since the last restart of the system, Frank Buchholz provided the report ZRSPFPAR_DYNAMIC_CD which can be found at GitHub https://github.com/SAP-samples/security-services-tools to make them visible for all dynamic changes. Values different to the effective value are displayed in yellow, values identical to the effective value are displayed in green.



Please note: As of SAP note 2201397 only the last 10 dynamic changes are logged. If you want to see all changes you have to search the syslog for the IDs Q19, Q1A.

Checking profile parameter values


Since the effective profile parameter values are calculated as previously described, it is not that easy to determine those. Depending on the method used to check a profile parameter value, it might happen that the displayed value is not the actual used value since it may be the case that
the origin of the effective value was not considered.

Let’s have a look at some common methods for checking profile parameter values.

SAP Instance Agent


We can display all profile parameters known to the current SAP kernel and their values via three different web methods offered by the SAP Instance Agent (aka SAP Start Service):

sapcontrol -nr <Inst-No> -function ParameterValue




  • The displayed values are the values which have been effective at the last system startup.

  • Dynamic Parameter changes are not recognized.

  • Only substituted values are displayed.

  • Profile parameter values added or modified in any profile file at runtime typically are not recognized. After a restart of the sapstartsrv they are recognized even if a restart is still required for them to take effect.

  • Values for profile parameters unknown to SAP kernel are only displayed if they are defined in any profile file.


 

sapcontrol -nr <Inst-No> -function GetProcessParameter <ICM|"Web Dispatcher"|MessageServer|Gateway|EnqueueServer|Dispatcher>(displays also description and all available sub-parameters)




  • The displayed values are the values which will be effective after the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are not recognized.

  • Dynamic Parameter changes are recognized.

  • Only substituted values are displayed.

  • Values for profile parameters unknown to SAP kernel are not displayed. (Maybe because they are not assigned to one of the groups)


 

sapcontrol -nr <Inst-No> -function CheckParameter




  • The displayed values are the values which will become effective after the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are recognized immediately even if a restart is required for them to take effect.

  • Dynamic Parameter changes are not recognized.

  • Substituted values as well as unsubstituted values (listed as "definition") are displayed.

  • Values for profile parameters unknown to SAP kernel are only displayed if they are defined in any profile file. A warning for the unknown parameter will be displayed.


For all of these web methods:

  • The check must be performed for every instance to get the full picture. Sapcontrol supports you on that: It can query the web methods on remote hosts using the -host and -port options.


Please note: Some parameters are only relevant for a certain type of instance. So, we may decide to determine the parameter value only for a particular instance. We can find the instances of a system and the "features" each one provides by running sapcontrol –nr <Instance-no> -function GetSystemInstanceList.

sappfpar


We can also use the kernel tool sappfpar to display all profile parameters known to the current SAP kernel and read the values directly from the specified profile on filesystem:

sappfpar pf=<profile> (interactive mode)
sappfpar all pf=<profile>




  • The displayed values are the values which will become effective after the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are listed in the output immediately even if a restart is still required for them to take effect.

  • If executed for the default profile, the unsubstituted values from the default profile are displayed (the instance profile is not recognized). The values displayed in column "SAP:" are the kernel default values.

  • If executed for an instance profile, the unsubstituted values for the instance related to that instance are displayed (the default profile is also recognized). The values displayed in column "SAP:" are the values from the default profile or the kernel default values.

  • Dynamic Parameter changes are not recognized.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • It must be performed for every instance profile to get the full picture.

  • There is also an interactive mode which displays the origin of an profile parameter value which will become effective after the next system startup sappfpar pf=/sapmnt/$SAPSYSTEMNAME/profile/DEFAULT.PFL get_origin



 

sapparar


We can also use the kernel tool sapparar to display all profile parameters known to the current SAP kernel and read the values directly from the specified profile on filesystem:

sapparar all pf=<profile>

sapparar <parameter> pf=<profile>




  • The displayed values are the values which will become effective after the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are listed in the output immediately even if a restart is still required for them to take effect.

  • If executed for the default profile, the substituted values from the default profile are displayed (the instance profile is not recognized). The values displayed in column "SAP:" are the kernel default values. The values displayed in column "User:" are the effective values for any instance without an instance profile holding values tailored specific to the same instance.

  • If executed for an instance profile, the substituted values for the instance related to that profile are displayed (the default profile is also recognized). The values displayed in column "SAP:" are the values from the default profile or the kernel default values.

  • Dynamic Parameter changes are not recognized.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • It must be performed for every instance profile to get the full picture.


cat & grep


Last we can simply cat and grep through all profile files on the OS-level (DEFAULT.PFL, instance profiles) as all profiles of all instances of the same system reside in the same directory (/sapmnt):

cat DEFAULT.PFL $SAPSYSTEMNAME_<instance_name>_<hostname> $SAPSYSTEMNAME_<instance_name>_<hostname> | grep ^<parameter>

  • The displayed values are the values which will be effective at the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are listed in the output immediately even if a restart is still required for them to take effect.

  • This method does not recognize the kernel default values.

  • Dynamic Parameter changes are not recognized.

  • It does not consider substitution of variables or arithmetic formulas.

  • It does not recognize the effective profile parameter values per instance.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • For the SAP Host Agent parameters, this is the only available method to display profile parameter values. There is no method allowing to determine for which profile parameters which kernel default values are used.


 

Checking profile parameters when logged on to SAP NW AS ABAP / ABAP Platform


Besides the methods to query the profile parameter values from the outside at least for AS ABAP we have some possibilities to get the values when logged on.

Transaction RZ10


We can display the profiles using transaction RZ10.

  • This displays the profile parameter values as they are stored in the table TPFET (see below how the entries to this table are populated).

  • The displayed values are the values which will become effective after next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are listed in the output immediately even if a restart is still required for them to take effect.

  • Dynamic Parameter changes are not recognized.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • After SAP note 2789094 was implemented, the instance profile of the ASCS instance can be displayed.


 

Transaction RZ11


We can display the profiles parameter values using transaction RZ11. It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values to determine the values.




  • Profile parameter values added or modified in any profile file at runtime using a text editor are not recognized in the output.

  • It displays unsubstituted values for the kernel default value.

  • Dynamic Parameter changes are recognized.

  • Values for profile parameters unknown to SAP kernel are not displayed.

  • Profile parameter values efficient at the ASCS instance can‘t be listed, even after SAP note 2789094 (at least at time of writing).

  • The check must be done for every instance.


 

Table TPFET


We can display the profile parameter values stored in the table TPFET.




  • The entries are populated when profiles are maintained and saved in transaction RZ10 or after importing the profile files via the related functionality in transaction RZ10, when maintained on operating system level.

  • The displayed values are the values which will be effective at the next system startup.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are listed in the output immediately even if a restart is still required for them to take effect.

  • This table holds the profile parameter values of the profile files, it does not contain the kernel default values.

  • Dynamic Parameter changes are not recognized.

  • It contains only substituted values.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • After SAP note 2789094 was implemented, profile parameter values stored in the instance profile of the ASCS instance are also in there.


 

Table PAHI


We can display the profile parameter values stored in the table PAHI.




  • The profile parameters and values are written to the table (referred as 'population') by the background job SAP_PERFMON_RSSTATPH which is triggered by job SAP_COLLECTOR_FOR_PERFMONITOR. It runs the report RSORA110. This uses the (legacy) Kernel calls "CALL 'C_SAPGPARAM'" and "CALL 'C_SAPGALLPARAM'".

  • The entries reflect

    • all profile parameter values from the profile files on operating system level (stored either by editing directly on operating system level or through transaction RZ10) which have been activated during the last system start and

    • the profile parameter values of Dynamic Parameter changes which have been active at the time of the population.



  • Profile parameter values modified at runtime in any profile either on operating system level using a text editor (even if they are imported in RZ10 -> 'Utilities -> 'Import profiles' -> 'Of active servers') or using transaction RZ10, which have to be considered as inactive till the next system restart, are not displayed. Also not after the population took place!

  • It contains only substituted values.

  • Profile parameter values defined in the instance profile of ASCS aren't listed, even after SAP note 2789094 (at least at time of writing).

  • Until next population the table holds only the history (snapshot of last population), not the current state! In between Dynamic Parameter changes are not reflected.

  • When performing a Dynamic Parameter changes on the same parameter multiple times only the value active at the time of population is stored in the table. There is no history for each Dynamic Parameter change. Only one parameter change per day is recognized (this is because the field PARDATE holds only the date and not a timestamp of the last parameter change).


 

Report RSPFPAR


We can use the report RSPFPAR (which is also called by RSPARAM). It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values (by utilizing the class CL_SPFL_PROFILE_PARAMETER).




  • The displayed values are the values which have been activated during the last system startup.

  • Dynamic Parameter changes are recognized.

  • It contains unsubstituted values at least for the kernel default value (here listed as "System Default Value").

  • Profile parameter values added or modified in any profile file at runtime using a text editor are not recognized.

  • Values for profile parameters unknown to SAP kernel are listed in the output only if they have been activated during the last system startup.

  • Profile parameter values defined in the instance profile of ASCS aren't listed, even after SAP note 2789094 (at least at time of writing).

  • The check must be done for every instance.


 

Function module TH_GET_PARAMETER


We can use the function module TH_GET_PARAMETER. It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values



  • Dynamic Parameter changes are recognized.

  • It displays only substituted values.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are not recognized.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • Profile parameter values defined in the instance profile of ASCS aren't listed, even after SAP note 2789094 (at least at time of writing).

  • The check must be done for every instance.


 

Function module RSPO_R_SAPGPARAM


We can use the function module RSPO_R_SAPGPARAM. This uses the (legacy) Kernel calls "CALL 'C_SAPGPARAM'"

  • Dynamic Parameter changes are recognized.

  • It displays only substituted values.

  • Profile parameter values added or modified in any profile file at runtime using a text editor are not recognized.

  • Values for profile parameters unknown to SAP kernel are displayed.

  • Profile parameter values defined in the instance profile of ASCS aren't listed, even after SAP note 2789094 (at least at time of writing).

  • The check must be done for every instance.


 

Function module PFL_READ_FROM_FILE


We can use the function module PFL_READ_FROM_FILE. This allows to read the profile files from disk.
Please note: This function module will be removed after implementing the SAP Security Note 3348000.

 

Function module PFL_READ_PROFILE_FROM_FILE


We can use the function module PFL_READ_PROFILE_FROM_FILE. This allows to read the profile files from disk.

 

Function module PFL_READ_PROFILE_FROM_DB


We can use the function module PFL_READ_PROFILE_FROM_DB. This allows to read the profile files from table TPFET.

 

Syslog


We can monitor the syslog for the following Message IDs to determine Dynamic Parameter changes:















Message ID Message Text
Q19 The profile parameter &a&b&c&d was changed in productive operation
Q1A >>> Old/New value : &a&b&c&d




  • This can be used to monitor Dynamic Parameter changes.


 

UI Data Protection Logging for SAP S/4HANA


It may also be an option to utilize the Add-On UI Data Protection Logging for SAP S/4HANA (license required) to monitor changes made through RZ10 and RZ11.

 

Report RSPFRECOMMENDED


Shows only parameters for which the Kernel knows about a recommended value. Available in ABAP Platform 7.55 and higher.

 

Report ZSPFRECOMMENDED


Shows an overview about the recommended profile parameters according to the secure-by-default project. Downported to 7.40. Source: https://github.com/SAP-samples/security-services-tools

 

Checking profile parameters for ABAP on SAP HANA


SQL script HANA_ABAP_Parameters


SAP provides a lot of useful sql scripts published in SAP note 1969700. In this package also the script HANA_ABAP_Parameters is included which can be used to query the table PAHI.
Please note: Due to the limitations mentioned for table PAHI, parameters of the ASCS instance can not be checked using this script.

 

Checking profile parameters for SAP HANA 2.0 database


Python program getParameter.py


SAP provides some useful python programs shipped with SAP HANA 2.0 SPS 04. These scripts are stored in $DIR_EXECUTABLE/python_support. One of these is the getParameter.py which can be used to check ini-file parameters but also allows to retrieve the value of profile parameters:

python getParameter.py --key=sapprofile/<parameter>

 

Checking profile parameters using SAP Solution Manager / SAP Focused Run (FRUN)


"Configuration Validation" or "Configuration and Security Analytics“ (CSA)


In SAP Solution Managers' "Configuration Validation" or in FRUNs' "Configuration and Security Analytics“ (CSA) validation the profile parameter values can be checked for compliance. In order to do so,

  • for AS ABAP the ABAP_INSTANCE_PAHI ConfigStore in the CCDB is filled daily by the extractor framework with the data from the managed systems.



Please note: As its name indicates, it is filled with entries from the table PAHI. Due to the limitations mentioned for table PAHI, parameters of the ASCS instance can not be checked using this store. A similar workaround as described below for SAP Web Dispatcher might be used.



In addition to that the ConfigStores ABAP_DEFAULT_PROFILE, ABAP_INSTANCE_PROFILE and ABAP_ASCS_PROFILE (Store type: TEXT) are available,




Please note: The limitations of these ConfigStores are described in the blogpost linked below.




  • for AS Java the „Parameters“ ConfigStore is available,

  • for SAP Web Dispatcher the ConfigStore INSTANCE_PROFILE (Store type: TEXT) is available.
    How to use this for compliance checks is described in the detailed blogpost How to monitor standalone (non-ABAP) Web Dispatcher Security in Solution Manager written by kai.bauer (which inspired me to write all this),

  • for SAP HANA no ConfigStore for profile parameters is available and therefore no checks can be performed,



Please note: The parameters for SAP HANA itself are stored in the .ini files, while the profile files hold the profile parameters for SAPStartSrv, CommonCryptoLib, etc.




  • for SAP Host Agent the "host_profile" ConfigStore (Store type: TEXT) is there.


 

Checking profile parameters using other tools/workflows


Combining AWS services to carry out a parameter check


The blogpost Compliance Check of SAP Systems Using AWS by jaskisin describes very detailed how to combine AWS services to a custom compliance checker which utilizes the web method ParameterValue of SAP Instance Agent.

 

Conclusion on how to check profile parameter values


Sadly we can not rely on the central monitoring tools provided by SAP to get this job in general comprehensively done. There are some drawbacks for example when it comes to checking profile parameter values related to the ASCS instance or to check whether profile parameter values are defined by using variables.

Also if we like to implement a custom compliance check we must consider what capabilities the utilized check method provides and what exactly we can expect from them.

For (near-)real-time checking of the effective profile parameter values, whether the parameters are known by the SAP kernel or not, on a SAP NW AS ABAP or ABAP Platform system the method of choice seems to be the function module TH_GET_PARAMETER. Since this is a "pull" process we have to think about the check interval to have the latest status in time for example after a system was restarted. In addition to that we may need to combine this with other methods like syslog monitoring to get informed about Dynamic Parameter changes.

 
13 Comments
Labels in this area