ZBasisAdm.com Consulting - Basis documentation you should have for your SAP systems

When I start with each client, I like to collect as much 'meta' information as possible. To make my job easier and to leave each client with a solid deliverable, I collect each of the following items:

I. General – Client Background

1. Where is the client located?
2. What is the clients business?
3. Are there access requirements for the site and building?
4. What are the operating hours?
5. Who are the key contacts?
6. What are the up time requirements?
7. Who are the client's other key vendors?
8. Who handles the operating system environments?

II. Infrastructure

1. How to connect with the client (is a VPN used)?
2. What operating system(s) and database(s) are utilized?
3. Which third party applications connect to the SAP systems?
4. Are there any special security requirements?
5. Which flavor of virtualization is used?
6. Are there any DR requirements?

III. Diagrams

1. Landscape
This should include all the SAP systems and any relevant connected systems
2. Transports/Updates
Shows the flow changes between systems
3. Network
How are the systems connected?
4. Server/Virtualized Instances and Systems
Where to the systems reside?
What processors and memory is on each system?
Do any of the systems share database instances?
5. Data Flows
How does data move between each of the systems?

IV. Processes

1. Change management
How are changes approved and moved through the systems?
Is there a ticketing system such as Jira utilized?
2. Communication
Who should be alerted when issues come up?
Is there an incident call tree?
3. Incident Management
How are issues and problems managed?
Are incident tickets created and are RCA's expected after problems resolved?
4. Security
Who and how are security requests handled?
5. Project Management
Is there an internal team that manages each project?

V. Strategies and Standards – Infrastructure

1. Backups
How and where are backups saved?
How are backups and restores requested?
2. Business Continuity
3. Downtime
When and how long are the scheduled maintenance periods?

VI. Strategy and Standards – SAP Specific

1. Client Strategy
Are there separate configuration and development clients?
2. Security Standards
Are there gateway or message server security requirements?
3. Authorization Standards
Are there firefighter roles available for production systems?
Is there a policy for who can run debug mode or SE16 in production?
4. Transports
Who imports transports?
Is there a scheduled date/time for production imports?
5. SLD
What infrastructure has been setup for the SLD systems?
6. ABAP
Is there a code review process in place?
7. System/Data Refreshes
Is there a scheduled process for refreshing data back to other systems?
8. Updates/Upgrades
How often are updates scheduled for the systems?
Is there a review process for SAP upgrades?
9. Monitoring
Is there a monitoring matrix that shows when alert messages should be generated and who should receive those alerts?
10. System Settings
Who approves the opening of systems?
Who should be notified what systems are opened and closed?

zBasisAdm.com Consulting - Scheduling Standard SAP Basis Housekeeping Tasks

When I first come to a client site, one of the first things I check is to see if they are running standard tasks to maintain their systems. Below is a template I created for the first SAP system I managed (way back in 4.7 on a MAX DB system nonetheless).

1. Housekeeping jobs for ABAP Systems
Job Name	Report	Repeat	Client Specific	PRD - Scheduled?
SAP_REORG_JOBS	RSBTCDEL2	daily	Y
SAP_REORG_SPOOL	RSPO0041/1041	daily	Y
SAP_REORG_BATCHINPUT	RSBDCREO	daily	Y
SAP_REORG_ABAPDUMPS	RSSNAPDL	daily
SAP_REORG_JOBSTATISTIC	RSBPSTDE	monthly
SAP_COLLECTOR_FOR_JOBSTATISTIC	RSBPCOLL	daily
SAP_COLLECTOR_FOR_PERFMONITOR	RSCOLL00	hourly
SAP_COLLECTOR_FOR_NONE_R3_STAT	RSN3_STAT_COLLECTOR	hourly
SAP_REORG_PRIPARAMS	RSBTCPRIDEL	monthly
SAP_CCMS_MONI_BATCH_DP	RSAL_BATCH_TOOL_DISPATCHING	hourly
SAP_SPOOL_CONSISTENCY_CHECK	RSPO1043	daily
SAP_REORG_ORPHANED_JOBLOGS	RSTS0024	weekly
SAP_CHECK_ACTIVE_JOBS	BTCAUX07	hourly
SAP_DELETE_ORPHANED_IVARIS	BTC_DELETE_ORPHANED_IVARIS	weekly
SAP_REORG_ORPHANED_TEMSE_FILES	RSTS0043	weekly
SAP_ADS_SPOOL_CONSISTENCY_CHECK	RSPO1042	daily
SAP_BTC_TABLE_CONSISTENCY_CHECK	RSBTCCNS	daily
SAP_REORG_XMILOG	RSXMILOGREORG	weekly

This is something that I've compiled over the years to better track scheduled housekeeping tasks. These I've compiled from Notes 16083, 1411877, and 1440439.

Most of these jobs can be scheduled from within SM36 (standard jobs). I like to manually check these against the list above to make sure the jobs are running with the correct reports and in the correct clients. If a job isn't scheduled, I'll create a new job and assign the task to a dedicated SAP Basis background account (something like 'BATCH_BC' should work). Please don't assign your account to these jobs! Almost every site I've worked at has had jobs fail because the Basis admin used their own account and these all failed when their account was deleted or locked.

Even more amazing is the number of sites that don't run all of these. I run some of these jobs at older sites and found one that deleted over 6 years of stale temporary variants! Needless to say, it took less time to create new variants after this cleanup.


You should also remove the jobs below. These are defunct and only generate errors in the system.

-->

2. Defunct Jobs
Job Name	Report	Reason
SAP_REORG_UPDATERECORDS	RSM13002
SLCA_LCK_SYNCHOWNERS	SLCA_LCK_SYNCHOWNERS	Only schedule on livecache systems
SAP_WP_CACHE_RELOAD_FULL		Only schedule on workplace servers

As a standard process, I'll add a check to standard system checks to ensure that these jobs are still scheduled (I'll check every month or so).

It is important to run these jobs so tables that hold transient data don't grow out of proportion to the rest of the data. Over time, you'll find the system starts to slow down as it reaches performance thresholds. As a Basis admin, you can return value to your client by ensuring that standard tasks are running and cleaning out those transient tables. Making sure these stay small, will make upgrades and migrations a bit easier.

-----------
Joseph P. Haynes
SAP Basis Consultant
zbasisadm.com

SAP Basis – What not to do when you run SAP

The benefit of working for different SAP clients has give me a keen insight on how best to run SAP and what you should not be doing. Believe it or not, I've come across each of these conditions at companies that should have known better.

Don't do any of these:

Mix databases, hardware or operating systems
It is hard to believe but I've run into clients who have different hardware, databases, and operating systems all within the same system landscape! This makes is really hard to complete system copies and almost impossible to gauge upgrades.

Update components less than once a year
Keep up with your updates to your current version of SAP and get in the habit of updating almost twice a year. Yes. You will need to establish a standard validation process around this but you should already have one in place.

Upgrade less than once every 4 years

Get into the mindset that you need to upgrade SAP every 3 to 4 years. The functionality and tool sets that you will gain will make implementing new technologies much easier (i.e. in-memory databases, big data, etc.).

Run on the same hardware for over 5 years
Yes. It is expensive to buy and implement new equipment but not nearly as expensive as support contracts for older systems or long  production downtimes. Don't be that company that ends up searching Ebay for old hard drives just to keep an old Sun machine running. When it comes down to it, hardware is one of the cheaper parts of running an enterprise application.

Install or upgrade a system without sizing
I've shown up at sites where an application has been running fine but suddenly slows to a crawl once a new external application was implemented. You can quickly overwhelm a system by adding functionality without first determining if it can handle the additional load. Systems are funny. They run fine until they reach a certain threshold and then suddenly become an issue. Save yourself the trouble by first sizing the system before making any major changes.

Let your IT technical team determine your infrastructure
What you run for your applications and systems should be determined by the business and not your internal technical teams. I've been at too many places where the Linux/Windows admin dictates what gets installed. Don't marry yourself to a platform or a database because that is what your internal team is comfortable with. Go with the best technology at the best price.  

SAP Basis - Better questions you should be asking your SAP Basis candidates

On my last few jobs I was asked to help screen candidates for open Basis positions. The unfortunate side of the business is there are quite a few candidates that appear to be qualified who are really just book smart and not necessarily tech smart.


I developed the questions below to help identify candidates who had the requisite skills needed to be a Basis Administrator in a high volume environment. One of the services I provide is candidate reviews. Please call me at 720-335-5727 if you would like to discuss how I can play a key role in identifying the best candidates for your company.

I. General Questions

• What do you know about the company?
• How do you manage a high volume of tasks?
• What would you do in a case where there are more than one or two severity one issues?
• What type of environment do you excel in?
• How do your managers get the best out of you?
• When working remotely, how do you stay connected to others on your team?
• What tools can be used to find out more about an issue with which you are not familiar?
• How to you handle frustrating circumstances?

II. Technical Questions

• What are the first things to check when a SAP system is reported as being down?
• What transaction is used to tell if database backups are failing?
• Users report that data from a remote system is missing. What are the first things you would check?
• What transactions are used to check the flow of messages in PI?
• You attempt to RDP into a Unix system and the connection fails. Why?
• What files should be reviewed in the case where a Java instance is no longer starting?
• Users are reporting that the system is slow. What transactions would you use to identify the source of the performance issue?

In general, the best Basis candidates are well rounded individuals who can think laterally, know how to research an issue, and enjoy taking on technical challenges.

Tricks with Putty

As I go from location to location I like to keep a small cheatsheet of steps that have come in handy over the years. Of these is my trick for capturing Putty settings from the Windows Registry.

Most of this information I gathered from the web but I'm posting it here so I have it for my own reference.

I. Where PuTTY Settings are stored

The settings for PuTTY are stored in the windows registry. These steps show how to back-up those settings, edit them, and re-load as needed. Note that you should make a backup copy of both the registry and PuTTY settings file before loading any modifications.

 

II. Saving the Settings

These steps will export the PuTTY settings out to a text file on your Windows desktop.

1. Exit to a command prompt by running cmd.exe

2. Run the following command (remember to insert your username):
REGEDIT /E “C\Documents and Settings\\Desktop\PUTTY_SESSIONS.REG" "HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\"

This should create a '.reg' on your desktop. Please make a backup copy of this file and only edit the copied file (i.e. keep a file to re-load in the case the settings are corrupted). Once you are done editing the file, double-click to load back into the registry.