Wednesday, February 3, 2016

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?

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.

Saturday, January 23, 2016

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.

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.

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.