In many ways, completing a mySAP component
installation is only the beginning of the installation process; to
actually prepare a system to be configured by programmers for use by
end users, a wealth of additional post-installation tasks must be
addressed. These core tasks include
Setting up a client and transport strategy
Addressing security and authorizations
Setting up printing and faxing
Implementing a backup/restore solution
Addressing archiving
The
last two points in the preceding list occur outside SAP, whereas the
first three are directly related to tasks performed by explicitly
logging into the SAP system itself. I take a look at each of these
broad areas in the next few sections, and address them in detail
through documents found on the Planning CD. For a more complete list of
tasks and activities that must occur after a mySAP component
installation, refer instead to the SIPP master project plan, or a
published SAP InstGuide.
SAP Client and Transport Strategy
Don’t
confuse a SAP “client strategy” with the GUI strategy employed for
accessing your mySAP solutions. Although the latter is certainly
important, attention to the legal entities created within an SAP
instance is critical. Your SAP client strategy directly impacts change
management, and facilitates cost-effective training as well. For
example, you might employ a client strategy where client 010 is the
golden or “destined for production” client, and client 800 is a copy of
010 used for training end users or developers or your SAP technical
team. And your change management process might be to promote changes
from client 010 to client 800 on a regular basis, say weekly, while
refreshing clients between instances
on another regular basis—a transport strategy. Refer to the “Sample
Client Strategy” PowerPoint document on the Planning CD for more
detail, including a sample six-system landscape client strategy layout.
With
regard to your transport strategy, you will probably initiate all
development activity in your DEV environment; alternatively, some
customers choose to initiate this activity from a special client
residing on a Business Sandbox. Regardless of origination, all changes
to any objects will also be initiated here. As development progresses,
objects will eventually need to be tested; this is accomplished by
transporting the updated object(s) to your Test/QA environment. Beyond
pure development efforts, changes can be initiated and submitted by
developers, ABAP/Java programmers,
Basis/Technical Implementation team members, and other technical and
functional SAP TSO resources.
Besides
ABAP and Java code, transports can include enhancement packages,
support packages, SAP kernel upgrades, other patches, and so
on—anything within the realm of your SAP system.
At the end of the day,
your transport strategy facilitates sound integration and Quality
Assurance testing. Often this is accomplished by moving bulk changes in
waves, as I just mentioned. In other cases, however, changes might need
to be transported quickly (as in the case of an emergency, where poor
code is impacting profitability or customer satisfaction). The key to
successfully allowing only authorized members of your SAP TSO to
circumvent change management brings us to our next topic, security.
Security, Authorizations, and Trust Relationship Management
Security
in general, even just the concept of SAP Authorizations, consumes
entire books in and of itself. SAP dedicates a great deal of training
classes and consulting time to the topic of security, too. Why? Because
SAP security is much more than managing risks to information assets, or
protecting business processes through the use of security solutions,
such as firewalls and the like. Underneath the wide-ranging topic of
SAP security lies equally broad Secure Systems Management,
which further includes areas like Single Sign On (SSO), Secure Network
Communication (SNC), secure ABAP Programming, and more. Add to this Identity Management and Trust Relationship Management, and you will begin to understand the magnitude of SAP security.
In
the world of mySAP solutions, the ability to manage users’ roles and
authorizations outside the boundaries of a single SAP component is
critical. SAP calls this Identity Management or central user
administration, and it is made possible through a directory service
that enables central security management of both mySAP and non-mySAP
systems. But that’s only the beginning; nestled underneath the broad
area of Identity Management lie three matters of importance in their
own right:
Users/Roles/Authorizations
Centralized Administration
Directory Service Integration
Authorization
management consumes a great deal of time before Go-Live. Getting
authorizations worked out and roles nailed down is time-consuming in
the best of cases—simply locking down users so that they cannot use
transaction SE38, for example, to pull practically any data from the
database, is only the beginning. You need to determine who should have
read-only access to particular functional areas and components, and who
can create new objects or edit existing ones. Authorizations apply to
different roles (or classes of users), too, not just end users.
Authorizations apply to systems administrators, for example—you don’t
want just anyone to have the ability to add or modify the supported
languages in your system, nor can you afford to allow just anyone to
use the Transport and Management system; only a select few members of
the SAP TSO merit these abilities. Similarly, authorizations apply to
developers—you need to lock down systems (like production!) such that
developers are not even tempted to make code corrections outside of
development systems. Others, like Help Desk personnel, senior computer
operators tasked with managing a mySAP enterprise, and so on also have
job-specific roles and authorizations that need to be adhered to.
In
the past, I have found it useful to create a Profile Matrix or Role
Matrix to help me manage users, roles, and so on, too. This can be
taken a step further, and adapted for specific components,
cross-application roles, and authorizations as well. I suggest
considering such an approach to document not only the roles or
authorizations inherent to your organizations, but also who has the
authority to assign a role/authorization, and who has authority to make
changes to them.
Authorization management
alone will not ensure a secure, auditable environment, however. Trust
Relationship Management takes managing authorizations to the next level
by attaching trust relationship information to the data itself,
regardless of how it might be distributed or shared through
collaboration or other means. By attaching this trust relationship
metadata to data, records can be maintained that prove that the data
has been used correctly. I believe that this will only grow in
importance as distributed environments grow to include more partners
and vendors, allowing companies to collaborate and share their data and
business processes. To learn more about Trust Relationship Management,
including Authentication, Pluggable Authentication Service (PAS), Logon
Tickets, and X.509 Certificates, see SAP’s Service Marketplace.
Printing and Faxing
SAP
uses spool work processes, which execute on one or more application
servers (or the central instance) to process print requests. In this
way, SAP supports printing in quite a few different ways:
Print
requests can be routed from an application server to its local OS print
spooler, and printed from an application-server-attached printer.
Using TCP port number 515, print requests can be routed to a standard “line printer” service from the target host.
Using a printer daemon (SAPlpd) and port 515, output can be printed.
Printing
via the dialog work process connection is maintained by a SAPGUI or
WebGUI front end; output is routed to printers (usually) defined at an
OS level and set up in SAP.
The
last printing method discussed—using the SAPGUI or WebGUI—is the most
popular approach for users who do not need to print giant reports best
handled by industrial-strength data center printers. The first step in
setting up this type of printing is simple—verify that you can access
the printer from your desktop or laptop at an operating system
level. Or make sure that you can print from a different application,
such as Microsoft Word. This will save you troubleshooting time if you
run into problems. Next, pull up the online documentation that ships
with the SAP product you are configuring for printing. For our purposes
here, let’s assume we want to set up a printer for Web AS. Drill down
into mySAP Technology Components—SAP Web Application Server—Computing
Center Management System—SAP Printing Guide. And then follow the
procedure outlined here. Through this procedure, you identify the
printer (by UNC or IP naming conventions), indicate whether you want to
print immediately upon receiving a print request, provide a cover sheet
for each print job, and define the output in terms of lines, columns,
and general format—all of which is clearly illustrated in Figure 1. Later, you can use transaction SP01 to manage your print requests.
In
some cases, it’s also necessary to set up faxing capabilities. In the
scope of my travels, I have come across many different faxing
applications. But Facsys and Faxination are the only ones that left an
impression on me, and after talking with my customers who still use
these products, they seem worth mentioning.
Faxing
is set up within the SAPGUI; afterwards, go to Tools, Business
Communication, Communication, SAPConnect, Goto, Error handling to check
the error handling status of a fax, or use SAPOffice for fax status
(depending on the faxing application). SAP notifies the sending user’s
Inbox or Outbox of fax attempts and related status, depending on
whether the fax was sent/received successfully or unsuccessfully.
Successful fax notifications are dropped into the sending user’s
Outbox, whereas unsuccessful fax notifications are dropped into the
sending user’s Inbox with a description of the kind of problem that
occurred.
To troubleshoot basic faxing
issues, use transactions SM59 and SM37. The first verifies that the
TCP/IP connection is good, and the latter can be used to see if a fax
job is running. Transaction SCOT (SAPConnect) can be used to reprocess
fax jobs if necessary. Additionally, SCOT allows you to view fax
information, process waiting faxes individually or by group, and look
at errors and other issues.
Backup/Restore Considerations
Surprisingly,
backup and restore (B/R) solutions for SAP represent one of the more
troublesome areas in an implementation. Why? I’m really not sure, other
than to say that it’s more complicated to back up a large enterprise
system than it appears. Although most people tend to lump B/R solutions
into the “tape drive/tape backup software” category, B/R solutions are
more accurately characterized in the following ways:
Backups
can be integrated directly with SAP (through SAP’s BR tools interface,
typical of Oracle database solutions) or might require their own
proprietary backup/restore application interface (such as SQL Server,
because by design it does not support SAP BR).
Backups
can be offline (where the database is shut down and all files are
therefore closed) or online (where the database is up and running).
Backups
can take advantage of a number of different tape drive and tape media
technologies, which vary in terms of price, speed, and capacity.
Backups
can be centralized (where multiple databases residing in a SAN all get
backed up to an enterprise tape library) or decentralized (where each
database server has its own locally attached dedicated tape solution).
Backups
can be configured such that the data is streamed to multiple tape
drives and protected with parity (much as RAID 5 arrays work to protect
disk data), dumped to multiple tapes (for speed), or simply dumped to a single tape (for simplest administration).
Backups
can be performed in other ways prior to dumping bytes to tape (which
ultimately needs to take place, consistent with best practices)—for
example, backups can be dumped to an array of disk drives (for speed
and as a “backup” to the backup), or they can be created from a clone
set of drives configured specifically for backup purposes.
One
of my SAP colleagues shared the following with me recently. I believe
this sums up the attitude that companies should have regarding what to back up:
If you don’t back it up, you cannot recover it.
If you don’t back it up and ship it offsite, you will not survive a disaster.
If you don’t test your backups by recovering from them, you really don’t have a backup.
If you don’t maintain your backup/restore system, it will at best perform poorly for you.
In the end, each of these nuggets of wisdom tells us the same thing—back up your data, or find another job.
Archive Considerations in the Real World
From
R/3 sales orders to CRM customer data and APO demand planning versions,
an enormous amount of data will be created annually in your mySAP
environment. It’s not too early to begin thinking about how you will
manage this data in terms of database growth and size while ensuring
excellent database response time—remember, it’s the database
performance that drags down average response time over the life of your
SAP system more than any other single component. I completely
understand the desire to kick back a bit after Go-Live and focus on
things like ironing out operational issues and getting to know your
family again. In fact, I must admit that most of my customers tend to
put off discussions of archiving until a year or two after Go-Live,
when they are fighting yet another unforeseen disk space issue and
facing potentially expensive disk subsystem upgrades or replacement
strategies. But if they were able to do it all over again, believe me,
many of them would gladly make room in their project plan to implement
at least a basic archiving solution before Go-Live.
So
let’s step back and talk about why an archive solution is needed in the
first place. If we look at typical R/3 systems, they tend to grow at a
pretty regular rate when things settle down a few months after Go-Live.
Most of my customers’ production R/3
databases grow between 5 and 10GB a month. The growth comes mainly from
transactional data—doing business day-to-day, like cutting purchase
requisitions, creating sales orders, and so on. With every extra GB of
data, the R/3 database tables grow longer and longer. SELECT
statements take longer to run as more rows of data are added to each
table. Database “reorgs” and other administrative tasks take longer,
too. Ultimately, a transaction that used to consume 500ms of database
request time will consume 600ms, and then 700ms. The system will even
begin to seem slower to its end users; their perception will be grounded in truth, unfortunately.
An
archive solution works by slimming down the database to something
resembling its former self, by removing old or little-used data from
the database—transactions run faster because there is less data to sift
through. SAP offers a host of built-in tools and interfaces to help you
archive your data, and a slew of third-party archiving solutions are
available as well. Thus, archiving simply means dumping your unwanted
data somewhere else, somewhere other than your production database. My
customers have taken a pretty liberal view of where precisely
“somewhere else” is, however:
In the most classic sense of the word, archived data is actually dumped to a near-line storage facility,
such as a magneto-optical jukebox. These hardware devices are slow
compared to disk subsystems, but provide a good tradeoff between online
data and completely offline data (like data that resides on tape). And
they exhibit phenomenal reliability, making them perfect candidates for
sensitive or critical data that absolutely must be safeguarded for a
long time.
Other customers have dumped archived data into more readily available and cheaper
media, such as inexpensive RAID 5 storage systems. With the cost per GB
of storage space dropping every year, this can be a pretty attractive
prospect over time. However, disk drives fail, and therefore must be
protected from failure.
Still others look to their data warehousing systems
as archive “systems of record.” Indeed, one of the most common reasons
I heard for implementing SAP BW the first two years after it was
released was to archive old production data out of R/3 and other
transactional systems.
In a
nutshell, before you go to the trouble of understanding all of your
requirements and needs, ask yourself the following questions:
Do you expect your database to hit 200GB in the next two years?
Do you expect your database to grow at more than 10GB per month?
Will
you have a hard time getting budget money or time later to implement
archiving, or will it be easier on everyone to earmark the dollars and
time now during the implementation?
If
your answer to any of these three questions is affirmative, read
on—there might be a lot of ways to implement archiving, but the keys to
a successful archiving project are few:
You
need to understand your data. This means understanding more than simply
what may or may not be archived. It also means understanding how
different mySAP.com components and even the discrete business areas
making up these components can benefit from archiving. And it means
understanding how both your transactional and master data grow over
time.
Understand the technologies, tools, products, and consulting expertise available and necessary to pull off an archive project.
Understand
priorities. With multiple mySAP components and hundreds of business
objects available to be potentially archived, you must understand what
to tackle first. There’s plenty to choose from—production orders, sales
orders, material and financial documents, and so on.
In the same manner, focus on OLTP environments like R/3 and CRM, where absolute response time is always
more important than in OLAP or reporting environments like BW. In other
words, go after archive projects that focus on customer-facing systems
that ultimately provide better ROI.
Understand
your access needs—can you tolerate 3–7 seconds of wait time to access
archived data, or do you need it faster? This will dictate the hardware
technology underpinning your archive solution.
Certainly,
other post-installation tasks outside of developing a client strategy,
setting up TMS, and addressing security, printing, backup/restore, and
archiving need to be considered. An SAP license needs to be installed,
as should a SAProuter (for additional security), the SAP online
documentation needs to be installed if this hasn’t already been done,
and RFC destinations need to be verified. Basic operational tasks, such
as setting up logon groups, operations modes (OpModes), background
housekeeping jobs, applying Support Packages, performing the initial
client copy of client 000, and so on, also need to be done. In most
cases, the relevant InstGuide walks you through much of this; worst
case, the InstGuide points you to SAP’s Service Marketplace, where you
can obtain further detailed information.
