This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP Sender Address for Communication Method

Whilst configuring SAP to send email oubound via SMTP you have to configure the node in SCOT to point to an SMTP server.
Once this is done, you would expect it to just work.
Unfortunatly, you may get the following issue.

When you create a new email message in SO01, you enter the recpient and the message text, then click send, and you are prompted with an error:

The error in the log book says:

You do not have a sender address in the chosen communication method.

This was an odd error, but a quick search on SAP notes revealed note 552616.

https://service.sap.com/sap/support/notes/552616

The note mentioned either setting my user’s external email address in SU3 (or SU01), or alternatively, instead of doing this for all users that wish to send external mail, you can set the “default domain” in SCOT.

Set the default domain to something like “mydomain.com”.
This means SAP will create an outbound sender address comprised of the SAP username plus the default domain (sapuser@mydomain.com).

I was then able to send mail externally.

Transporting SAP User Groups

I’ve blogged about SAP user groups before: https://www.it-implementor.co.uk/2011/09/sap-user-groups.html
Let’s say you’ve set them up in your DEV system and now you’re expecing to just transport them.  Well, as with all things SAP, it’s never quite that easy.

Create a new workbench transport request in SE01, SE09 or SE10 (doesn’t matter which).
Then open the request at the request level by double clicking it.
Switch to change mode by clicking the pencil button:

Now manually type in the program Id, object type and object names as follows:

R3TR TABU USGRP
R3TR TABU USGRPT

Click Yes at the prompt:

On each item, click the Function button (key symbol):

Enter * in the Table Keys field:

Save the request again.

That’s it!

Release the transport and import into the next system.
This is a farily generic process that can b used to transport any table values.
NOTE: You should be aware that the “*” in the table key, means all items specific to the current client.

Gathering Oracle Statistics – the SAP way

Gathering stats on a table in an Oracle database, can significantly change the SQL excution plan.
In some cases this can be detrimental to the system performance.
I have seen this in a real production system, where the indexed column was 38 characters long.  The system had just been upgraded from 9i, the original table stats carried over and left up to Oracle.
Performance was dreadful, the 9i stats had been refreshed but not re-created.

See SAP note 365480 (“CBO: Field filled with leading “0” aligned to left”).
It suffered from an Oracle “bug” (773462) where only the first 32 characters are used to measure the distinct number of values for the column.  In a 38 character field, left padded with zeros, using the index can cause a problem.
If we had removed all stats and re-created them, no problem, as Oracle 10g would have probably generated histograms.
However, the real issue was that the stats shouldn’t have been there according to DBSTATC.

NOTE: SAP notes say to specifically disable the default Oracle 10g/11g GATHER_STATS_JOB.

As noted, if you let Oracle gather statistics it overrides the settings in the SAP DBSTATC table.
The DBSTATC table (see transaction DB20) controls where stats are gathered and how stats are gathered.
In actual fact, this is why you sometimes see “Harmful statistics” in the BR*Connect DBcheck results.

The stats are gathered using the Oracle DBMS_STATS package with Netweaver 7.0’s version of BR*Tools (more specifically, BR*Connect).

Below are some SQL and PL/SQL commands useful for analysing statistics problems in a SAP Oracle 10g environment.

/* Check if gather stats auto-job is enabled */
SELECT JOB_NAME,
OWNER,
ENABLED,
PROGRAM_NAME,
TO_CHAR(last_start_date,'DD-MM-YYYY HH24:MI:SS') last_start_date
FROM DBA_SCHEDULER_JOBS
WHERE JOB_NAME='GATHER_STATS_JOB';

/* Get GATHER_STATS_JOB program details */
SELECT PROGRAM_TYPE,
PROGRAM_NAME,
PROGRAM_ACTION
FROM dba_scheduler_programs
WHERE PROGRAM_NAME='GATHER_STATS_PROG';

/* Get the last time the GATHER_STATS_JOB ran and log info */
set linesize 400
col ADDITIONAL_INFO FORMAT A100
col LOG_DATE FORMAT a20
col JOB_NAME FORMAT A20
col RUN_DURATION FORMAT A25
col ACTUAL_START_DATE FORMAT A40
SELECT log_id,
actual_start_date,
run_duration,
job_name,
status,
log_date,
additional_info
FROM dba_scheduler_job_run_details
WHERE owner='SYS'
AND job_name='GATHER_STATS_JOB';

/* VERIFY STATS ON A COLUMN */
SELECT num_distinct,
density,
num_buckets,
sample_size,
avg_col_len,
histogram
FROM dba_tab_col_statistics
WHERE table_name = &TABNAME
AND column_name=&COLNAME;

/* VERIFY STATS ON A TABLE */
SELECT sample_size,
TO_CHAR(last_analyzed,'DD-MM-YYYY HH24:MI:SS') last_analzed,
global_stats,
user_stats,
stattype_locked,
stale_stats
FROM dba_tab_statistics
WHERE table_name = &TABNAME;

/* VERIFY HISTOGRAMS ON A TABLE */
SELECT *
FROM dba_tab_histograms
WHERE table_name=&TABNAME;

/* GATHER COLUMN STATS FOR A COLUMN ONLY */
BEGIN
       DBMS_STATS.GATHER_TABLE_STATS (
                                OWNNAME => 'SAPR3',
                                TABNAME => '< A TABLE>',
                                METHOD_OPT => 'FOR COLUMNS < A COLUMN> SIZE AUTO');
END;

/* GATHER TABLE STATS USING ESTIMATE 10% */
BEGIN
        DBMS_STATS.GATHER_TABLE_STATS (
                                 OWNNAME => 'SAPR3',
                                 TABNAME => '< A TABLE>',
                                 METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
                                 ESTIMATE_PERCENT => 10);
END;

/* ORACLE'S DEFAULT JOB TO GATHER STATS */
dbms_stats.gather_database_stats_job_proc;

/* DELETE ALL THE TABLE STATS CASCADE TO INDEXES and COLUMNS */
BEGIN
        DBMS_STATS.DELETE_TABLE_STATS (
                                   OWNNAME => 'SAPR3',
                                   TABNAME => '< A TABLE>',
                                   cascade_parts => TRUE,
                                   cascade_columns => TRUE,
                                   cascade_indexes => TRUE);
END;

/* DELETE COLUMN STATS ONLY */
BEGIN
         DBMS_STATS.DELETE_COLUMN_STATS (
                                   OWNNAME => 'SAPR3',
                                   TABNAME => '< A TABLE>',
                                   COLNAME => '< A COLUMN>',
                                   FORCE => TRUE);
END;

Connecting SAP Netweaver ABAP Stack To SAP SLD

If you’ve ever quickly needed to know the points to check for customising settings connecting your SAP Netweaver *ABAP* system to an SLD (System Landscape Directory), then here they are:

Transaction: SLDAPICUST
Transacion: RZ70
Transaction: SM59 – TCP/IP connections: SAPSLDAPI (Use by ABAP API)
                                                                 LCRSAPRFC  (Use to read the exchange profile)

Here’s the SAP Help article: https://help.sap.com/saphelp_nw04s/helpdata/en/be/6e0f41218ff023e10000000a155106/content.htm

To Delete or Not To Delete (an SAP user account)

Having read around the SDN forum recently, I was surprised that no one had done any particular research into the consequences of deleting SAP user accounts.
This is probably quite a common question when you first get your shiny new SAP system implemented.
Generally, auditors prefer that you delete IT accounts. It’s a nice catch-all and means that they can tick the box that says “done”, knowing that what happened was the most secure option. But it might not be the best option.
Most procedures require locking the account for 1-2 months before eventually deleting it, therefore catching rogue background jobs etc.

After some heavy procrastination I have come up with the following reasons why it might always be better (safer) and actually more audit-friendly to just lock the account and not actually delete it:

– Adding a new user of the same user id as the one just deleted, will attempt to re-use the old address details.
This is really bad and could cause awful confusion. It could also cause a problem with regards to auditing.

– Customer modifications/code in programs and workflows that utilise the user id.
If the user is deleted, then re-created later on for a new employee of the same name, that new user may inherit authority, receive SAP Office emails or any other actions that were previously meant for the old owner of the user id.

– When a user creates a transport, this is recorded in the code version history for the objects transported and the transport co-file and a file in one of the the /usr/sap/trans sub-directories (off-hand I think it’s called sapnames…).
Deleting the user removes the tie between the user id that created the code version, and their real name/details. In a large organisation it can be difficult to find the right “Smith” that made that change.

– When a user is deleted, you can not see what authorisations the account used to have.
Once again, how can you prove that some malicious action happened if the account has been deleted, removing the evidence that the user had access to perform the crime.
Alternatively, someone may have legitamately left the company, but recruiting didn’t find a replacement for 6months. Guess who will need to create a new user id where the request form says “same roles as Joe who left 6 months ago“.

– If you delete a user account after they leave, then re-create a new one for a new employee, what if you’ve missed an account on a system somewhere.  Nobody will know if it should be for the user who currently exists.  This is a major security risk.

This may lead you to thinking about a better user id naming scheme that could provide a unique name for every account created.
That really would be a worthwhile exercise.

Don’t forget, locking the account does not mean that you need to pay a license cost for it, it’s not usable.