Saturday, January 23, 2016

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.