What is a SAP Landscape? What is my role in a SAP implementation?

The SAP Landscape is like a layout of a complex garden you have areas for roses, and areas for lilacs, and it is all laid out in proper form. A SAP landscape can range from one SAP instance with one client and one user who does all the input into the instance via keyboard to dozens of instances with hundreds of clients and thousands of users, with keyboard input, RFC (Remote Function Calls) and ALE (Automatic Link Exchange) from other SAP instances, links to external databases, EDI (Electronic Data Interchange) via flat file from banks, vendors, etc., and RF units in the warehouse. In other words, a SAP landscape can be very simple, or very complex. A bed of petunias, or the Hanging Gardens of Babylon.

A normal SAP landscape consists of a Development (DEV) instance, a Quality Assurance (QAS) or Test (TST) instance, and a Production instance (PRD). Some very small implementations will have only a DEV and PRD instance, with the DEV instance containing a QAS client for testing purposes.

A non-Production SAP server should have 2 (preferably more) processors, at least 4 gig of memory, and at least 100g of disk space. A Production SAP server should have at least 4 processors, from 4 to 8 gig of memory, and at least 200g of disk space. A hefty server with 6 8 processors, 6 8 gig of memory, and at lease 200g of disk space can host two SAP instances. This can be done for DEV and QAS but PRD should never share a server with any other SAP instance.

The SAP instances form the core of a SAP landscape. The other installed SAP products are peripheral to the SAP instances.

What is a SAP Instance?

A SAP instance is all the components created by the SAPinst program who all share the same database. There are three mandatory sub-instances; the Database Instance (DB), the Central Instance (CI), and the Dialog Instance (DI) aka Application Server. This is the minimum configuration of any SAP instance. There can be multiple DIs but only one DB and only one Active CI which means that a copy of the CI can exist for High Availability but only one of the CIs can be active at any given time. You will hear about SAP being multi-tiered and that term is referencing these three layers. Sometimes you might see other SAP tiers like ITS but that really isnt a separate tier, it used to be an additional piece of software working with IIS, and now ITS is part of Basis/WAS so it is part of the CI Tier. These layers, plus other SAP written software, are also known as the SAP Business Framework.

You can probably guess at what the DB contains. There are any number of tables in a SAP instance, from 21,000 to 38,000. Many have four or five character names that are usually abbreviations of things like USR for user, MANDT for client, etc. You could guess that USR is short for user. But MANDT? So, we add one more variable to the equation those four or five character names are abbreviations of German words. Needless to say, trying to look at SAP from a typical DBA prospective is almost impossible. Fortunately, SAP supplies the tools for you to manage all these tables.

The Central Instance is a lump term for all the SAP executables, the installed OS file structure, and anything that is placed on the OS to support and communicate with the SAP instance. It talks to the database, handles requests made by the application server(s), and sends back the information. Other software products often call this the middleware layer.

The Dialog Instance connects the users to the CI, passes the issued requests to the CI, and sends the returned results to the users session. SAP uses a client piece called SAPGui which handles the user-to-DI communication on the users workstation.

These are the three main pieces of a SAP instance installation. There are other parts that can be added for various sub-access and external tasks. For a Development SAP instance or a Quality & Assurance or Test SAP instance, all three layers are normally installed on the same server. For a Production SAP instance, the DB/CI are often installed on one server and the DI on another server for load balancing purposes. It should be noted that the installation of a CI instance automatically installs a DI which can be used by everyone if needed, be used only as needed by Basis staff, or never be used.

Instance can be a difficult term to understand almost every major database applies this term to the installation of the database software. So if you see reference to an Oracle instance, this means the installation of the Oracle software. An Oracle database is the creation of a new empty database within that Oracle instance.

Understanding the Startup and Shutdown prodedures may help solidify this layer concept.

The normal SAP instance start up consists of three parts: starting the SAP OS Collector, starting the Oracle Listener, and starting the SAP instance. The process mainly goes like this: ora<sid> logs on and starts the Oracle Listener then <sid>adm logs on and runs the startsap script.

What? You say we missed a step? What happened to the SAP OS Collector?

The startsap script takes care of the SAP OS Collector for us. When the SAP Instance starts up via the startsap script, it checks to see if saposcol is up and running whether from the root user starting it manually or from another SAP Instance already starting it up, it doesnt matter. If saposcol is up and running, the script simply moves on to the next step. If it is not, the script starts saposcol as root and then proceeds. So the SAP OS Collector gets handled one way or another.

However, you may need to bring up multiple Oracle Listeners depending on the database configuration. If the MCOD installation option was used then only one Oracle Listener is used since both databases share one Oracle listening port which is normally 1527. If, however, two Oracle instances were installed, and each database uses its own unique Oracle listening port, then multiple listeners must be started. The startup procedure for each SAP Instance would be exactly the same as if only one SAP Instance resided on the server.

The process to stop the SAP instance is close to being the reverse of the start procedure. <sid>adm stops the SAP Instance, ora<sid> stops the Oracle Listener, and root stops the SAP OS Collector. The only real difference is that saposcol is not automatically stopped by the stopsap script there may be other SAP instances on the server which means this software needs to stay up and running to gather OS information until that instance comes down.

One thing to note the Oracle Listener does not start the database, it simply watches port 1527 for any database related activity. The startsap and stopsap scripts handling the startup, mount, opening, and shutdown of the database. None of this activity could occur if the listener was not polling port 1527, relaying the requested database function, and returning the results through the same port.

The <sid>adm and ora<sid> users are assigned environment variables using the SAP installation run that identify them as users of a specific Oracle database and SAP instance. So when oraabc

starts the lsnrctl program with the lsnrctl start command, oraabcs environment variables tell the server which database for which the listener is to listen.

What are the different kinds of SAP software? What kind of hardware will they need?

Although the most common flavor is SAP is called R/3. This is SAPs main ERP product that handles Financials, Controlling, Logistics, Sales, Human Resources, and lots and lots of other ERP stuff. All these modules that is what the functional people call them live in and use common data in one SAP instance. All the modules are installed during a SAP instance installation. Whether all the modules are implemented is up to the SAP customer.

Each SAP flavor must be installed in its own SAP instance. Products such as APO (Advanced Planning & Optimization), BW (Business Warehouse), CRM (Customer Relationship Management), SRM (Supplier Relationship Management), SolMan (Solution Manager), and SCM (Supply Chain Management) are all SAP flavors installed into their own instances all of which are pretty much installed the same way installed with a DB, CI and DI - and the process is pretty much the same depending on the age of the product. Just like SAPs product line, its installation program SAPinst has changed over the years as well.

In addtion, there are add-ons supplied by SAP. Products such as plug-ins for communicating with other SAP instances; the SAP Learning Solution, Sarbanes-Oxley, Best Practices, etc. can be added to an existing SAP instance. These add-on products are what the name implies they add more functions and data on to an regular SAP instances.

Some SAP transactions communicate with external software but the functionality is either in the SAP instance or out on your network or on the internet. SAP transactions like SCOT use built-in communication ports for the use of sending email from SAP to a SMTP server. Transaction SICF activates business packages for access via the internet.

RFC Remote Function Calls can originate in the SAP instance and go out to talk to some other product that knows what to do with the request passed, and information is send back into the SAP instance. And, of course, an SAP instance can talk to another SAP instance using RFC for example, this is how the Transpost Management System moves changed from one instance to another. There are also products written by SAP partners which can be accessed externally from a SAP instance: products like Vertex which is a Sales Tax database, and BSI which calculates payroll taxes.

As for hardware, SAP has special hardware sizing software on which it trains its hardware partners like IBM, HP, Dell, etc. They have worked together to create templates for very small, small, medium, large, and very large SAP landscapes. Once you contact the hardware vendor of your choice, they will meet with you to calculate your SAPs a unit of measurement SAP uses to estimate workload decide into which category your company fits. From there it is pretty much a plug-in the company data and spit out a sizing reports.

Lets get this out into the open early: a Basis consultant does not do hardware sizing. Normally, they will look at the sizing report from your hardware vendor and tell you if they think it is too weak or too strong. That is about all you can expect of them their career could be very shortlived if they say Hey, they are just trying to get you to purchase some really expensive boxes that you just dont need!. Remember, SAP created the sizing program and trained this hardware vendor on it and that is what your quotes will be based. Anything critical said about the proposal could get back to all sorts of people who could more or less hurt you in certain circles. Im not talking about punching you out or stalking you. More along the lines of every problem message you open with SAP gets its priority bumped down to like a -5.

Also, we recommend that you get hardware estimates from more than one hardware vendor. Even if you mentally are locked into an IBM box running AIX and Oracle, it doesnt hurt to see what the other platforms are selling for. And it doesnt hurt if rumor gets back to IBM that you are talking to Dell. Playing hardware vendors against one another can lead to some hefty discounts given by a vendor who doesnt want to see a sale walk out the door.

You can get a head start on the hardware sizing process by reading the documents available at http://service.sap.com/sizing. If nothing else, you can impress your hardware vendor by sprouting out all these SAP terms like SAPs and High Availability and SANs.

Besides servers for your database and SAP instances, you might need other servers for your SAP landscape depending on the complexity of your SAP implementation. At the very least, you will need an additional not-too-hefty server for a Solution Manager instance which is what SAP is now requiring as the tunnel to get into your SAP landscape; youll need a small server having a public IP address and located in your DMZ for your OSS connection. More about this later.

And there may be a need for Portals servers, UME server, a SAPConsole server the list goes on and on. As stated earlier, a SAP landscape can be very simple or very complex.

Remote installation on your SAP servers can make the installation task simpler it is always more comfortable to do the work from your own workstation than having to sit in a cold, noisy computer room. The Basis group of Hitachi recommends Terminal Services aka Remote Desktop for this work. PCAnywhere and products such as Tight VNC do not possess the stability of Terminal Services.

How does SAP get installed?

First, it must be noted that only the SAP company is allowed to KT (Knowledge Transfer) installation information. Clients may watch all they wish during installation, and are encouraged to install and delete sandbox instances on a spare server rather than let it gather dust. But installation is not part of your purchased Technical Knowledge Transfer package.

Without getting into the little details, here is what gets done during the typical SAP install the work that gets done after the hardware has been installed into the network and DNS:

1. 2.

Make all server configuration adjustments as specified in the SAP installation guide. Download and install JDK 1.4x you can use JRE 1.4.x if you arent going to use the ABAP add-on.

3. 4. 5. 6. 7. 8.

Install the database software. Patch the database software. Run SAPinst to install the CI and default DI instances. Run SAPinst to install the DB instance. Run SAPinst to install any additional DI instances. Download and install the most current SAP kernel.

9.

Current the TMS for the SAP instance.

10. Download and apply all outstanding SAP patches. 11. Request and apply the permanent license key. 12. Do remaining post-installation work such as connecting SAP Online Help, creating clients, adding users, etc.

Normally the post installation work takes 2 - 4x the amount of time of the actual installation. The installation itself normally take a one eight hour working day and the postinstallation work two eight-hour working days for a total of three working days to install a SAP instance. This regardless if it is a DEV, QAS, or PRD instance.

What is a SAP client?

OK, we have the concept of a SAP instance, and that instance has a database which contains thousands of tables which contain a whole bunch of rows. After SAP is installed, these tables need to have some base data in order for customization and configuration to begin. Like state abbreviations, country codes, HR titles, etc.

SAP provides a subset of this data so that the Basis team can get in the new instance, add themselves a user ID in client 000 our client - and start the real work. We dont want to mess this subset of data up so we need to populate it to a work place for the Functional Team to do their work. Or several work places.

The base SAP instance comes with two clients: 000 and 066. Forget client 066, it is used by SAP when you get close to GoLive and you want an EarlyWatch report. This is optional and I believe a fee is involved for this service.

All the base or subset data is contained in client 000. Also, client 000 is where the Basis Team does a lot of its maintenance like patching. The Basis Team people are the only implementation members who will ever have access to client 000. You can think of client 000 as the owner of all the client independent data in the SAP instance. Explanation in a minute.

So, in order to let the Functional Team do their own thing without screwing anything up, we create a new client for them. Think of a client as a view of the database. If you log into client 000, you can see all client independent data like the ABAP programs and all the data that is dependent on client 000 only. If you log into client 100, you see all client independent data like the ABAP programs and all the data that is dependent on client 100. You cant see the data that is dependent on client 110 while you are logged on to client 100.

Thus the concept of client dependent and client independent data. All rows in some tables are accessible from any client like T000, the Data Dictionary tables, tables that contain the ABAP programs, printers, etc. These are said to be client independent. Data like users, companies, vendors, customers, etc. are client dependent. You have to go into a specific client in order to see this data.

How do I create a new client?

This is a pretty easy procedure. Basically, you add a new logical system in transaction SALE, create a new client in transaction SCC4 using the logical system you created previously, create a RFC target destination using transaction SM59 with the same name of the logical name, create a RFC source using transaction SM59 for the source or from client, log on to the new client, and schedule a client copy from the source client to the destination or to client. Thats all there is do it

When you bring up a new SAP instance, you add a client 100 and schedule a client copy from client 000 to client 100. This is called a local client copy since the source or from client is contained within the same SAP instance as the target or to client. When you add a new SAP instance to your landscape, like QAS, you might want to copy client 100 in the DEV instance to client 200 in the QAS instance. This would be a remote client copy.

A client copy is destructive in other words, all the data in the target client is deleted during the client copy. So the procedure is not just for creating new clients but refreshing existing data. The only exception to this rule is the using the SAP_CUST profile to do the copy it will leave all the data in the target client intact with the exception of the user master data which will be deleted and replaced with the source clients user master data. You can even mix and match, the data from one client and the user data from another, and copying them both at the same time in the same client copy run.

A client is created using transaction SCC4 and at the time of creation you must specify what type of client it will be. Is it to be used to create configuration changes that are to be transported to QAS and PRD? Is it a reference client, frozen so it can be used to refresh the data contained in test clients? Can both client-dependent and client-independent data be changed in this client, or only client-dependent data, or no changes allowed at all? These various types of client have their own labels to the SAP implementation team: golden client, unit test client, configuration client, ABAP client, production client, etc. If someone references a client with which you are not familiar, be sure to ask for clarification so that the wrong client does not end up being the source client for a client copy!
y

What is this permanent key stuff?

When a SAP instance is first installed, it installs with a temporary license that expires in 4 weeks. You must request a permanent license key via the SAP Marketplace. More about that later.
y

How do the users communicate with the SAP instance?

Well, of course, you need to add them to the SAP instance. Then the user has to be able to connect to the application layer in some from. Normally this is using the SAP supplied program SAPGui which is installed on a users workstation, but here are other ways such as connecting to a Citrix server on which SAP is installed or connecting from the internet using a SAP product via Portals, ITS, or some other product, or using one of the SAGUi alternatives like SAPGui for Java.

SAP uses some common ports no matter where it has been installed. The first instance installed on a server is labeled as System Number 00. It would use ports 3600 for the Dispatcher, 3300 for the Gateway, and 3600 for the Message Server. If you had a second SAP instance installed on the same SAP server, it would normally use the next available number in the port range. So SAP instance #2 would be System Number 01, use port 3601 for the Dispatcher, 3301 for the Gateway, and 3601 for the Message Server. As long as a user can access these ports from his workstation, he can log on via the SAPGui installed on his workstation.

How do I limit what my users can do when they log on to a SAP instance?

SAP user security is done via roles. A role is basically a group of transactions, authorizations, and authorization objects bundled together for use by a group of users with common functional

needs. This group definition is saved and generates a profile which is attached to the SAP user who needs it.

People often get intimidated by SAP security there are thousands of transactions, authorizations, and objects. It helps to think of all this is simplistic terms.

Lets say you have a user who needs access to one transaction in the SAP instance. All he needs to do it log on, go to transaction SPAD, and print a list of available printers. That is his whole job, to create this printer list once a day. So he needs the authorizations that allow him to log on to SAP, to go to the SPAD transaction, and to print the list to any available printer. He has * to all printers. He basically needs a role containing the transaction he is allowed to do, SPAD, and the authorization object S_SPO_DEV set to all because he can see and print to any printer.

Then lets says a new check printer gets added to SAP, and we dont want the user to be able to print his printer list to the new check printer. So we change authorization object S_SPO_DEV to a list containing authorizations for the printers to which he can print, excluding the check printer. His dropdown list for printers wont even show the new printer now. And he will be able to print to any printer in his printer authorizations list.

This is a simplistic example but you can see how it works. SAP security can be very tight or very loose. In general, it is loose in DEV, using a modification of the SAP_ALL profile sort of God-like powers and what the Basis people normally use since it already exists and why make a role that does the very same thing? - to allow every DEV user to do everything with the exception of Basis tasks. QAS may be a little tighter, or a combination, allowing the user SAP_ALL during training but limiting the user to his/her PRD role in another client on the last day so he can test the role he will really use out. In PRD, of course, users should only receive the rights to only what they absolutely need to do.

How do I patch a SAP instance? How often should I do it?

There are three different types of a SAP patch: support packages, kernel replacements, and SAP Notes aka OSS Notes.

Support packages are used to make ABAP code and functionality changes. ABAP is the language in which SAP is written and it is pronounced AAAA-bop and not AAAAAbap. Support packages contain a group of ABAP fixes that must be installed via transaction SPAM from within a SAP instance. You apply these fixes in a specific order: Basis, ABA (Application Basis patches the software that supports the interaction of SAPGui with the SAP instance), APPL (application functional patches), and then plug-ins, etc. that also exist in the instance because add-ons and stuff have to be patched too. After you apply support packages to a SAP instance, you need to regenerate all the ABAP loads so that users dont have to sit watching Compiling messages the first time a changed ABAP program is called.

Kernel patches are simply a replacement of the SAP executables on the OS level. This is always done to a new SAP instance and most likely done following a support package application run.

SAP Notes or OSS Notes contain a patch or two to solve an immediate problem. The Basis staff either manually applies an ABAP code fix or uses the SNOTE transaction in the SAP instance to apply the fixes. There are times, however, when the note contains instructions that must be done manually in other words, things must be done that SNOTE cannot do. Eventually, as the SAP Note corrections become more and more, SAP will group them together and release a new support package so that they can be applied en masse and not one-byone.

In order to download any of these patches, you must log in and download them from the SAP Marketplace athttp://service.sap.com/patches. And you must have a valid OSS ID aka SAP Front-end User ID or s number with the rights to access the patches webpage.

Other products, such as J2EE, are patched via a combination of deployment of packages and replacement of OS executables.

In general, you should schedule your support package maintenance often enough to prevent shell-shock to users due to massive changes in the SAPGui screens, and rarely enough that you dont spend all your time preparing for the next support package application window. Often, patch application is driven by an identified problem that can be fixed via a support package referenced by SAP.

Just make sure to get a list of all the packages that will be applied, and use the SAP Notes SideEffects tool off the SAP Support Packages in Detail site at http://service.sap.com/patches to get a list of everything that is changed during patching for your Functional team leads.

What are all these numbers? s number, license number, etc.

When you become a new SAP customer, SAP assigns you a customer number. This number is like any other customer number you assign your own customers, or that companies assign to you. It uniquely identifies your company to SAP.

Once you sign your software license, each of the SAP components you purchase is assign an installation number. So, you signed a mySAP.com Business Suite license? Then you will be assigned an installation number for R/3, another installation number for BW, another installation number for CRM, etc. You also signed a license for KW? That would be another installation number. SAP sometimes splits existing products out to other divisions, so you may even be assigned a second customer number with new installation numbers assigned under that number. SAP did that with Enterprise Portals. An installation number identifies a customers SAP component. If you open a problem under your R/3 installation number, SAP knows that the problem is going to deal with R/3 and not CRM, BW, etc. A few weeks later, SAP shipped your installation kits and you installed R/3. Four weeks later your users get a message saying that the license has expired. But you signed your license agreement! When an SAP instance is installed, it gets assigned a temporary license key that is good for approximately four weeks. You need to request a permanent license key as soon as you finish your installation of the SAP instance. How? First, you will need yourhardware key. This identifies your operating system information so SAP can generate a key that is not only good for your SAP version but for your hardware as well. To see your hardware key, log on as <sid>adm and go to a command prompt. Type saplicense -get and your hardware key will be displayed. Jot it down, you will need it later. The hardware key for NT is different than, for example, the hardware key for AIX. So if you change your SAP license from AIX to NT, you will need to make sure that your company is attached to the new hardware key or you wont be able to request new permanent license keys. To request your new permanent license key, go to http://service.sap.com/licensekey. Use this website to give SAP information on which SAP flavor your have installed. You will have to provide your hardware key as well. SAP will generate the new key and e-mail you a text file. Save the text file on your SAP server, log on as <sid>adm, and go to a command prompt. Type saplicense -install ifile=<path and name of txt file from SAP>. Your key should be installed! In later versions of R/3, you can use the SLICENSE transaction as well.

Now your system is flying! But your ABAPers sign on for the first time, and they need to add a new program to upload master data. When they enter se38 they get a message asking for their developer key. This key is generated by SAP as well, and is used to register your super users who will be responsible for adding new code and changing SAP-owned code. Go to http://service.sap.com/sscr to register your programmers. Once you have the developer key, give it to your ABAPer and he can enter it into the system. He will only have to supply it once per SAP instance. Now your ABAPers are cranking out code, your system is humming, and then! Pow! The dreaded short dump hits you when you arent looking. You look up the error code and find a valid OSS note to fix the problem. You log on to apply the advance correction, your give yourself a developer key, go to transaction se37, but a new popup wont go away, it keeps asking for an access key for R3TR FUGR XXXXXXXXXXXXXXXXX. You must get an object key in order to modify an SAP-owned object. Since SAP owns all the ABAP code that comes with the SAP instance, you have to get a key in order to apply the advance correction. Again, you would use http://service.sap.com/sscr, this time to generate an object key. All this SAP website access also demands that you have an OSS User ID, or as it is now known, SAP Service Marketplace User ID or S Number. The user ID to perform the tasks outlined in this message must have administration rights. You should have received your primary OSS ID when you got your SAP license. If you have not received a primary OSS ID, or your SAP reseller seems to have control of your primary OSS ID, contact SAP AG to resolve the problem. Your OSS ID is connected to your SAP customer number, so if you have two customer numbers, you will receive two OSS IDs. Make sure to limit the powers of any subsequent OSS IDs generated by the Basis group. More on this later. SAP has recently complicated the license scenario by introducing user licenses. Do not confuse your software license keys with SAP licensing of the usage of named users. These are two different things! Usage by users of an SAP instance will be monitored by your auditing team, and normally the only function of the Basis group in this regard is using su01 to register the type of each user. Now there is only one other really important number you need to know: the phone number for your Basis technical consultant!

How do I add users? Do I have to add them all to each client one-by-one?

You use transaction SU01 to add and change users. If you want to copy the users from client 100 to the users in client 110, you can do a special kind of client copy that is nondestructive. When the profile SAP_USER is used during a client copy, just the user master data is copied from the source client over the target client, and the rest of the database is left intact.

No matter how you manage your user security, there is no getting around the fact that you have to manually add them all to at least client at some time or another. The best way is to add them all to client 100 in DEV since that is the Golden client and should never be refreshed or written over by a client copy. Once you have them all in one spot, you can use a client copy for just user master data and pop all the clients wherever you want them.

There is another way to add users to clients called Central User Administration (CUA). CUA allows you to designate one client in the SAP landscape that is the parent of all or specified clients, both local and remote. When you add a new user to the parent client, the child clients get populated with this data. Thus, one user add will trigger others within the instance and to other SAP instances as well. This technique should only be used on clients that are not to be refreshed in the future.

Do I have to add printers to each client too?

No, printers are client independent data. Once you add a printer using the SPAD transaction in an instance, it is available to all clients in that instance.
y

So what does the Functional Team do in their own little client(s)?

They do configuration and customization. Think of configuration equal to you going into Outlook on your workstation and changing things in your Tools -> Options. You change your Calendar Default Reminder to 5 minutes instead of the default 15 minutes. Now, multiple that by about 1000x and you have an idea of what configuration entails. This configuration covers tax rules, country codes, company codes, sales regions, sales areas, sales pipeline, all that stuff technical people really dont want to know.

Customization is changes made to SAP-owned objects when configuration does not have an option for what you need to do. For example, SAP comes with several canned Sales Invoice documents. If none of them contain a format you can use, your Functional Team will work with an ABAP consultant to create a new Sales Invoice document that better suits your companys needs.

Depending on the configuration and customization changes made, the SAP instance may force you to register these changes in the form of transport. The implementation will try to group all these changes into transports that contain all the work done for a project or a unit of work so that they can be moved to QAS and later PRD easily.

The TMS (Transport Management System) is used to move these transports between SAP instances. Movement of these changes between clients in the DEV instance can be done by the functional people using SCC1. What goes on in the DEV instance mostly never is important to Basis. Once the changes need to go to QAS, the Basis team takes over and uses TMS to move them for the functional team.

TMS movement can be very loose or very tight. Some shops simply release a transport and then send email to the Basis group asking them to move the transport into QAS, and later into PRD during off hours. This is called manual TMS control.

Some companies schedule jobs to move any transport found in the QAS queue to QAS at a set time once or twice a day. The transport is also moved into the PRD queue where is stays awaiting approval. Once the transport has been tested in QAS and is ready for PRD, the project supervisor and/or system administrator uses a transaction to OK the change import into PRD which releases the transport in the PRD queue which gets imported into PRD during the next scheduled PRD TMS job run. The method is automatic and requires little intervention by the Basis Team.

Most companies use some combination of these methods. There are several variations such as moving changes to client groups in DEV the same time the change is imported into QAS, and importing the change into multiple clients across the landscape.

The TMS tool is used by the SPAM and SAINT transactions in order to manage the support packages waiting to be applied which is why it is one of the first post-installation steps that must be done in a new installation. All the SAP instances of a particular flavor share a transport directory which is normally owned by the DEV instance since it is the first instance installed. Different SAP flavors need their own SAP transport directory, meaning all CRM instances share a TMS, all BW instances share a TMS, etc. Very few transports can safely be

cross-instance applied since not only the SAP flavor should be the same but the Basis version as well.

ABAP programmers are special. No only do they create new ABAP programs, they sometimes have to change existing ABAP program. These programs are SAP-owned so things can get a little sticky. Whether adding a new program or changing an old one, every programmer need a developers key that we previously discussed. This will be fine for new programs, programs that should either begin with Y or Z. So if you hear someone reference Z programs, you know what they are talking about, it is a general term to refer to all homegrown SAP programs and include not only the programs whose names begin with the letter Z but the ones that being with Y as well.

SAP doesnt like programmers just going in and changing ABAP code that it owns. And remember, ABAP programs are client independent, so if a bug gets into a program from a change made by a programmer in client 120, it affects client 000, 100, 110, etc., all clients share one version of the ABAP programmer. As a form of security and to allow better tracking of SAPowned objects, a key must be generated at http://service.sap.com/sscr - SAP Software Change Registration that is unique to the object about to be changed. Only the Basis group can do this, programmers cannot request SSCR key on their own, or that is the way your Basis group should make it work. Basis has control over the other S numbers generated against your SAP license, and you have to have a S number with administration rights in order to generate a Developers Key or an Object Key. So, genereally, when adding a new S number for a non-Basis group person, allow note searching and any message to SAP options on, and everything else off.

What factors affect SAP Performance?

Like every other complex piece of software, performance in a SAP instance depends on many factors. So you often have to play detective to find the core of your problem.

The most common complaint is when a SAP instance is cycled meaning stopped and restarted. As we touched on earlier, a SAP instance is comprised of millions of lines of ABAP code which are generated into load objects. When a SAP instance is stopped and restarted, all data and program information is flushed from SAPs internal buffers. So every time a new SAP program needs to run after being cycled, the needed program has to be read and then placed in

the program buffers for use. Not only that, if the ABAP code for that program has been changed or the load object invalidated in any way like a kernel replacement that added new functionality, etc - the program must FIRST be recompiled and then loaded into the buffer. The next time the program is called, it will execute faster since its load object is already out there in the buffer. The most commonly used programs in a SAP instance number in the thousands, so as the day goes by, SAP response time goes faster since getting a hit in the buffer for a certain program happens more and more often. But there might come a time when some of these fast program have to be switched out of the buffer because their date/timestamp is the oldest of all the programs in the buffer, and the buffer is full. Buffer swapping can slow a SAP instance down.

Another factor that often causes a slow down or even a hanging SAP instance is failure to dump the database log. This occurs more often in Oracle instances since a MS SQL Server database will just keep growing until there is no more room on the hard drive, which is something rather easy to spot. Many people fail to process the ReDo files created by an Oracle database by backing them up to tape and informing BRBACKUP that they have been processed, and they just keep accumulating until there is no place else to put them. This can cause the database to hang which causes the SAP instance to hang. For a DEV or QAS instance, most DBAs turn off log archiving. On PRD instances where a backup should occur nightly, a task can be scheduled to delete all ReDo files older than 2 or 3 days as long as the archive files are backed up when the rest of the SAP instance is backed up. Another common problem with Oracle is if the logging and automatic archiving are turned off. Both should be never both be off to prevent the archiver from getting stuck.

It is possible for someone or something to get into an infinite loop and just keep eating up your CPU. Transaction SM50 shows you what is running at any given moment. Almost every process shown in SM50 has a corresponding process on the server side. You can use the process ID in SM50 to investigate the corresponding tasks on the server. You can normally use SM50 to cancel any hung processes but sometimes you have to go to the OS level and cancel the process there.

Server space is not just critical on the hard disk where the logs are created. Any shortage of hard disk space on a SAP server should be corrected at once. SAP is like any other software; it uses TEMP space, and generates other type logs, like job logs and print logs. You want to make sure there is plenty of space available on all your SAP server drives.

Index rebuilds and statistics jobs should be scheduled on all your SAP instances on a monthly basis. This will keep your database tuned and efficient. Any time you do a mass program regen using transaction SGEN, you should schedule a statistics run on the database as well.

Every SAP instance contains three profiles that let us tune and adjust various parameters such as buffer size, default client, number of processes, etc. Rarely will you touch two of these, the DEFAULT.PFL and START_DVEBMGS00_<server>. The third, <SID>_DVEBMGS00_<server>, you will probably spend the rest of your SAP career changing. Erroneously changing one of these profiles is common reason why a SAP instance that was working perfectly in the past wont come up now. That is why even though you make your changes to the profile using transaction RZ10, once you activate it, it gets written as a flat file out on your instance server. So if a parameter change causes your SAP to fail during startup, you can undo the changes with VI on UNIX or notepad on Windows.

UNIX commands used for SAP administration:

1. stopsap/startsap for stopping/starting SAP+ DB, stopsap r3/startsap r3 for stopping/starting R3

2. Cdpro for checking the profiles path SAPMNT/<SID>/profile

3. Cdexe for checking the kernel folder

4. find . -name filename -print for checking the file in the present directory

5. dpmon pf= <Instance profile path>, jcmon pf=<instance profile path>

6. df -k, bdf for checking all file system usages; df -k ., bdf. for individual file usages

7. ls -lrt for listing of files according to the date modified

8. du -a | sort -k 1n,1 for sorting the files in a recursive manner.

9. h for listing previous used commands.

10. rm < file> for removing file, gzip <file> for zipping the file.

11. Ps -ef is to check the how many running process and Kill any running process

12. gunzip to unzip file

13. tar -xvzf file name to run the zip folder of file content

14. mv mo from one path to another

15. Rf remove forcifully any file

16. Make command to effect any coading content

17. make clean to clean the effect of make command

18. cp coppy from one location to another

19. pwd check the current directory

Configuring TMS - Transport Management System

1.

Log on to client 000 of the SAP instance to serve as the Domain Controller.

2.

Go to transaction SE06.

3.

Click on the Perform Post Installation Actions button.

4.

Go to transaction STMS.

5. You should see a popup box with the title TMS: Configure Transport Domain. If the popup doesnt say that, press F6 to change to the correct popup box.

6. Fill in the TMS: Configure Transport Domain popup with the Description, Name of DOMAIN_<SID>, and the description of the Transport Domain. Then click Save.

7. On the Transport Management System screen (if you arent there, back out until you are), assuming that this is the first SAP instance and there are no other installed SAP instances in your landscape yet, and assuming that you want your transport requests to be transportable and not local only, click on Overview Systems.

8. On the System Overview Domain Domain_<SID> screen, click SAP System Create External System. Fill in QAS if you are going to have a three system configuration or PRD if you are going to have a two system configuration, or make up a <SID> if you are never really going to have another SAP system. Fill in the rest of the information including the Path which is assumed to be \\<current server>:\usr\sap\trans for NT or /usr/sap/trans for UNIX. ClickEnvironment Transport Routes.

9. On the Display Transport Routes screen, click the User Settings button, turn on the Hiergraphical List Editor, and click the Continue button. Back out of the screen and then go back in you should see the list in a text mode which makes it easier to handle.

10. On the Display Transport Routes screen, click the Display<>Change button to toggle into Change Mode.

11. On the Change Transport Routes screen, click Configuration Configuration Development and Production System.

Standard

12. Fill in the Development and Production System popup, using your current SAP system SID as the Development system and the SAP instance you created in step #8 as theProduction system. Click the mark to Continue.

13. Back on the Change Transport Routes screen, click the Save icon and confirm all the popup questions.

14. On the Change Transport Routes screen, back out until you can once more see theTransport Management System screen. Click Overview Systems.

15. On the Display TMS Configuration: System XXX screen, double-click the TMS Domain domain controller SAP instance.

16. On the Display TMS Configuration: System XXX screen, click the Display<>Changebutton to toggle into Change Mode. Click the Communication tab and make sure that the Transport Group Name is correct. It should contain of the Domain Controller in the format of DOMAIN_<SID> where <SID> is the System ID of the SAP Domain controller. Use the dropdown to find the correct entry it the field is blank. Click the Transport Tool tab. Verify that the information on the tab is correct and click the Insert Row button. Add a Parameter of CTC and a Value of 1. Click theSave button.

17. Do step #16 for every system in your TMS Domain, making sure to change allTransport Group Names are the same and the CTC row is added to each with a value of 1.

18. Save your way back the the main STMS screen. Step by Step Procedure to copy a Client to the Remote SAP Server.
y y y y y y

Logon to destination SAP server Use Transaction Code SCC4 Go to change mode Create a new client, assign client number & description as per request Logoff from current client. Login to newly created client in destination SAP server using the following credentials : i. ii iii Client Number User Id Password : Newly created one : SAP* : PASS

Use Transaction Code SM59 to create a RFC Connection for client copy if does not exist already. RFC Connection should have Target Server as Destination and the test results should say Connection test OK

Use SCC9 Transaction code to go to client copy screen.

y y y

Give profile as per the request. Select RFC destination created for the purpose for the source client to client copy Use Transaction code SCC3 for monitoring the progress of client copy

___________________________________________________________________ Golden rules for CLIENT Copies

1. Master data can not be copied without copying transactional data and transactional data can not be copied without copying master data. 2. Application data (transactional and master) should not be copied without copying configuration data. 3. Client copy requires a valid client as the destination client. Make sure that the client exists in T000 table and you can logon to that client. 4. The transport system and the transport management system of 4.0 are the only proper tool to be use to keep multiple systems in sync by transporting development and customizing changes to another instance. 5. When you copy a client from one system to another, client-independent tables should only be copied if they are not yet modified in the target system. 6. We recommend the users to read all the OSS notes regarding client copy that applies to their SAP release. It is always better to schedule the client copy job in the background for the night run when normal work is not taking place. 7. Always check the database space before performing a client copy.

8. To avoid data inconsistencies all the users working in the source and target clients should logoff from the system. 9. RSCLICHK program should be run in the target system remotely before doing a client export. This program will give information about the missing definitions from the data dictionary in the target. After executing this program and getting successful results you can ensure that the client copy will have no problems. In case some tables are different; you can use SE11 to compare and adjust the table structure in both the system before the client copy. A remote test client copy also can be executed to know the differences between source client and target client.

10.

If you are not in release 2.2 then do not use R3trans to copy a client.

Step by Step Procedure to create a copy of a client locally in the same SAP server. 1. 2. 3. 4. 5. 6. Logon to SAP server Use Transaction Code SCC4 Go to change mode Create a new client, assign client number & description as per request Logoff from current client. Login to newly created client using the following credentials : i. ii. iii. 7. 8. 9. Client Number User Id Password : Newly created one : SAP* : PASS

Use Transaction Code SCCL for local client copy Give reference client for copy and profile as per the request Use SCC3 Transaction code to monitor progress of Client Copy.

Golden rules for CLIENT Copies 1. Master data can not be copied without copying transactional data and transactional data can not be copied without copying master data.

2. Application data (transactional and master) should not be copied without copying configuration data. 3. Client copy requires a valid client as the destination client. Make sure that the client exists in T000 table and you can logon to that client.

4. The transport system and the transport management system of 4.0 are the only proper tool to be use to keep multiple systems in sync by transporting development and customizing changes to another instance. 5. When you copy a client from one system to another, client-independent tables should only be copied if they are not yet modified in the target system. 6. We recommend the users to read all the OSS notes regarding client copy that applies to their SAP release. It is always better to schedule the client copy job in the background for the night run when normal work is not taking place. 7. Always check the database space before performing a client copy.

8. To avoid data inconsistencies all the users working in the source and target clients should logoff from the system. 9. RSCLICHK program should be run in the target system remotely before doing a client export. This program will give information about the missing definitions from the data dictionary in the target. After executing this program and getting successful results you can ensure that the client copy will have no problems. In case some tables are different; you can use SE11 to compare and adjust the table structure in both the system before the client copy. A remote test client copy also can be executed to know the differences between source client and target client. 10. If you are not in release 2.2 then do not use R3trans to copy a client.