The BASIS of SAP

SAPCAR is SAPCAR ……

Over Christmas / New year, I’ll be upgrading a customer from a very old (as in unsupported by both the vendor and SAP) release of their database to the latest release supported by 46C.  As part of the exercise, we are bring the Support Packs (Support Stacks came in after 4.6C) up to date.  However, when I loaded the Support Packs into the target system’s /usr/sap/trans, I couldn’t decompress them for processing via transaction SPAM.

I transferred the latest SPAM (SAPKD00040) and the 50 Support Packs (yes, I know) required from http://service.sap.com/swdc to the UNIX server via my PC.  When I started decompressing the Support packs on the UNIX system, everything went OK for the BASIS (KB46Cxx.CAR) and and ABAP (KA46Cxx.CAR) Support Packs, but when I went to decompress some of the R3 Support Packages, SAPCAR failed (with a less than useful message).

 

The tool used to decompress the CAR files is SAPCAR – SAP’s own version of the UNIX / Linux tool tar.  I sat back and had a think about what SAPCAR actually does, and what could have gone wrong.  My first thought was that I had corrupted the files somehow in the transfer process.  I still had the CAR files on my PC, so I downloaded SAPCAR_5-10000854.EXE (4.6D 32-BIT Windows Server on IA32 32bit – a windows compatible version of SAPCAR) to test whether the CAR files on the PC were OK – I went to http://service.sap.com/swdc, selected ‘Search for Support Packages and Patches in the Archive’, and searched for SAPCAR, but you can also search directly for SAPCAR_5-10000854.EXE (remember that the part of the name following SAPCAR will differ between SAP different releases and platforms).

 

When I attempted to decompress KH46C36.CAR on my PC using SAPCAR_5-10000854.EXE, it worked quite happily.  More importantly, it also worked for all the CAR files that were causing me problems on the AIX server.

 

Now, remember that I was thinking that the original problem was caused by corruption during the file transfer, either from SAP to my PC, or from my PC to the server.  The logical conclusion, if that was the case, would be to restart the transfer at whichever step had corrupted the file(s).  However, because it appeared that the problem may have been with the UNIX SAPCAR, I wondered whether the decompressed files created on the Windows system would work with the AIX system.  As it turned, after I transferred the decompressed files from Windows to the EPS/in directory on the AIX system, I was able to import the the Support package using SPAM.

This makes sense, given that what we are working with is the source of the platform independent ABAP code.  The code that ends up in the transport may look differently depending on the machine architechture (read up on little endian versus big endiann), but the contents of the transport will be the same across platforms, for the same release of SAP.  On the other hand, if I wanted to upgrade AIX or DBMS specific parts of this particular installation, I would be upgrading the kernel (i.e. /sapmnt/XXX/exe for 4.6C) files, not loading my data into the system via SPAM. 

More to the point, what does this get me ?

I can get the OS / DBMS independent upgrades completed, so that the testiers don’t get held up.  I get this done before I get distracted by tracking down the kernel error (i.e. why the AIX SAPCAR doesn’t work).  The division between SAP Application code and the Operating System / DBMS dependent code allows for some interesting ways of solving problems. Where have you used code or executables for one platform to help fix a problem on another platform ?

A brief summary of SAP Tech Ed 2010

Some thoughts on the ‘On Premise, On Demand, On Device’ mantra which was very evident at at TechEd in Las Vegas this year. 

* There was less empahasi on the iPad and iPad nano (aka iPhone), compared to the impression I had received about SAPPHIRE (despite the presence in the timetable of the session CD125 iPhone and iPad in the Enterprise).  I do know that the number of Android devices on the the market has driven their prices well below those of the equivalent Apple devices, with the implication being that choosing one device type over another may make the difference in the financial viability of a large scale mobile rollout.

* Another issue was device standardisation (See presentation CD123 The Device Challenge – Selecting the Right Mobile Devices for Your Enterprise).  On the one hand, designing interfaces to be device agnostic means you end up with the lowest common denominator, but on the other hand, each device type does have unique capabilities.  One interesting approach with some potential is a product called Caffeine (you’ll need Code Exchange access), written and released into the public domain by an SAP employee.  It enables, the execution of ABAP on new platforms, such as Java (JVM), Android (Dalvik VM), the iOS (ObjectiveC).  The most obvious use case is where an ABAP programmer writes ABAP code (that runs on the device, not the server) and this code is used by device specific programs.  The idea here is that the ABAP people know the business structure and logic, and this is written once, while the device specific coding is handled by device specific programmers.

On the minimalist end of the scale, my team got a bit of praise at the Innovation weekend for having a simple HTML interface that used a server based PHP program with REST APIs to communicate with an application we developed in SAP’s River cloud.  This meant we could have demonstrated the product with much older technology than Androids or iPhones – an important consideration when dealing with volunteers and non-profit organisations.  A much more impressive example were the 2010 Las Vegas Demo Jam Winners Matt Harding and Al Templeton (BTW, I’ms not a barbarian, I’m a Tasmanian was made about these guys) who used an HTML5 interface for data entry requiring a modern browser, but still relatively device independent.

* As an aside, Rui Nogueira gave a presentation on Code Exchange.  Some people (myself included) had some issues with what we saw as onerous licensing requirements.  I was able to have what was effectively a one-on-one with Rui later on in the week, and have a seperate post percolating away on that, to be posted real soon.

* The current and soon to be released features of the Adaptive Computing tools (See ALM208 Adaptive Computing Virtualization and ALM214 Virtual Reality) now let you manage the entire stack, from the physical in-house AND cloud resources, right up to starting and stopping individual SAP instances.  There’s an argument that vendor specific tools may do a better job of managing these resources, but the whole point is that the resources at your disposable may not be vendor specific.  I certainly got the impression that the latest release (due out in GA early 2011) provide more than enough sophistication for a site where the majority of the workload is SAP based.  And the ACC tools come with the Netweaver license, no extra cost except for configuration.

 * BusinessByDesign will come with an SDK (see CD107 Developing SAP Business ByDesign Applications Using Partner Development Infrastructure), supposedly available to partners only, for creating and modifying functionality.  The version we got to use in the hands-on session was a bit clunky, but it was functional, and it was still a pre-release version.  From my perspective, the elephant in the room is that sizing becomes even more of a black art; Architechs can estimate what queries wil be made and how often, and the impact that this will have on system load (from hardware resources to virtual server to network load to preseentation device), but this can all be blown out of the water by a developer or end user ‘having a bright idea’  It’s a reminder that the physical infrastructure needs to be supported by a new (for SAP, anyway) type of agile process, to allow for qucik but accurate provision of the resources to back up demand surges, while making sure that they are in fact real demand and not caused by an error in the application

* To me the biggest takeaway from the conference was the one phrase, especially from the SAP mentors (I know a few and have worked with a couple of them, so I may have got to go and hear a few things I possibly shouldn’t have…),

“It’s not your Grand Dad’s / Grand Ma’s SAP any more”

Whether you’re part of a System Integrator or large partner, like I am, or an independent consultant, or somewhere in between, we all need to get up to speed on what tools and techniques are available to us and our customers.  While conferences like SAP TechEd provide invaluable networking opportunities, you don’t have to go…. for example, most of the SAP Teched 10 presenatations are available off the SCN e-learn page (search for the SAP TechEd 2010 link). 

But there’s more (no steak knives though) …

1) ondemand.com is an SAP site which allows you free access to perform BI analytics on small sets of data  (you can pay for more storage if you wish).

2) Sustainability is supported by SAP’s Carbon Impact on Demand,

3) the live Collaborative Decision Making site. 

4) Don’t forget the Development versions of the latest SAP software from Crystal Reports to ABAP that you can install on your laptop, at home or in the cloud.

 It also helps to keep up to date with the latest news; for example, did you know what was happeing to Web Dynpro Java ?- See The Future of SAP Java UIs – Breaking News and Customer Dialogue from SAP TechEd Las Vegas and Kiss of Death for Web Dynpro Java – The Follow-Up Questions.

I have an aggregated SAP News feed which includes most SCN articles and blog entries from the last 30 days, but also other industry sources (such as jonerp.com ).  Feel free to use it.

Life is changingg, SAP is changing, and while there is always too much information to absorb and lots of new things clamouring for our attention, there are easy ways to keep up to date with SAP the company, SAP the product(s) and SAP the industry.

The JAVA equivalents of the SAP* password, some history and a usefull tip.

See Forgot or Lock Administrator or J2EE_ADMIN Password on SDN

A little bit of History….

If you’ve administered, or even worked on, any release of R3 or the other ABAP powered SAP systems, you’ll be familiar with the user-ids of SAP* and DDIC.  The SAP* user, in particular, is very powerful, but early releases of R3 had some flaws in how the SAP* password was stored or calculated.  You created a SAP* userid, with it’s own password (encrypted and stored, just like all the other passwords) or you used the default settings (including the default password) for SAP*.  The problem was that if I didn’t know the SAP* password, but could access the database (via telnet as most R3 systems were some UNIX variant back then), all I had to do was delete the SAP* user record (using SQL) and logon using the very well known defaults.

R3 is a business system, owned by the business, and us technical people have no right to go poking around where we are not wanted (OK, a bit tongue-in-cheek, but there’s more than a grain of truth in there).  To help resolve this issue, somewhere around version 3.0, SAP introduced the profile parameter login/no_automatic_user_sapstar which, when set, meant you had to have an explicitly defined SAP* user record. 

Of course, if you really have to login as SAP*, and you know a password from another user for the same client, you can still modify the existing SAP* user record via SQL.  Changing passwords via SQL isn’t as risky as you’d think, so long as operating system access to the database is restricted.  When I have done this, it’s been on behalf of the System Administrators, because they or we (ok I) forgot or lost the password, or got locked out, or someone changed the password and went home without telling anyone else.

Back to the 21st Century…

Now, this was all pre ABAP v Java (sorry, that should probably be ABAP and Java).  In the dual-stack systems, the day-to-day Java equivalent of the SAP*user is the J2EE-ADMIN user, which is usually (but not always) defined in the ABAP engine.  In a Java only system, it is the Administrator user, which is defined in the UME link from http://server:port/index.html.  The Java engine, whether on its own or part of a dual-stack system, also has a SAP* user, but it comes with some extra properties…
1. The system is configured, by default, to not allow access via SAP* at all,
2. When the system is configured to allow SAP* to log in, no other user can login,
3. and, of course, configuration changes require a restart..

Now, if you loose or require the Administrator or J2EE-ADMIN password, you can reset them via the SAP* user; But this requires the following steps;

• Enable the SAP* logon via the Config Tool,
• Restart the Server (to allow the previous step to take effect),
• Reset the affected passwords
• Disable the SAP* logon via the Config Tool, and
• Restart the Server

Sumit Madral has very recently published a good article on how to perform the reconfiguration for SAP* on java systems so I won’t go into any more detail.  It is enough to say that this requires two server restarts before you can start the work you were tasked with in the first place.

…and the whole point of the blog is …

I work for an SI which means we have a lot of systems to keep track of the user and passwords for.  Many of us use simple algorithms to keep track of our passwords, such PASSWORD = ‘a phrase’ + SID + incremental-value.  However, if you’ve read this far, you may have guessed that I’ve been caught out by incorrect or locked passwords a few times, including the Administrator and J2EE-ADMIN users.

When it happened once too often, I decided I needed a preventative measure.  Now, on any Java systems I support, I create an Admin_Backup user, with limited authority, to be used solely for resetting / unlocking the Administrator and J2EE-ADMIN users.  It is a backup mechanism; I know I’ll make mistakes, so I prepare for them.

BASIS at the Operating System – tp check all

It started with a request to bring a 46C landscape up to date.  The starting levels for the Basis, ABA and R3 Support Packages were all at the low 20′s, while the target level for each of them was level 53. 

This meant I needed to install about 90 support packs per instance.  Comparing the sizes of the Support Packages against the space available in /usr/sap/trans suggested that I might be able to fit everything in without annoying the Storage Management team, if I was able to clean up all the old transports.

Which was where I hit the snag:

zuxdc22:dp1adm 19> tp check all pf=TP_DOMAIN_DP1.PFL
This is tp version 305.13.24 (release 46D) for ANY database

check>Log file is written to /usr/sap/trans/tmp/CHECK.LOG

check>
check>Collected 22 filenames from [/usr/sap/trans/buffer/.]
check>Collected 5 Systemnames from [/usr/sap/trans/buffer/.]
check>Collected 00160 out of 00160 entries from buffer ZP1.
check>Collected 01233 out of 01233 entries from buffer TP1.
check>Collected 03037 out of 03189 entries from buffer PP1.
check>Collected 00094 out of 03254 entries from buffer QP1.
check>Collected 00023 out of 02671 entries from buffer DP1.
check>Collected 04547 entries from buffers
check>.
check>Collected 5082 filenames from [/usr/sap/trans/cofiles/.]
check>Found 3 invalid filenames on Cofile-directory
check>No Cofile found for TA STOPMARK
check>HALT 20100916141327
ERROR: A target system group (/U9C_ALR/) is used with a name longer than 3.
This is only possible with NBUFFORM=TRUE!
ERROR: EXIT(16) -> process ID is: 87782

tp returncode summary:

TOOLS: Highest return code of single steps was: 16
ERRORS: Highest tp internal error was: 0204
tp finished with return code: 204
meaning:
parameter is missing
zuxdc22:dp1adm 20>

 

However, when I checked the domain profile TP_DOMAIN_DP1.PFL, the values for NBUFFORM (and a related parameter, CTC) were set correctly….

#

TRANSDIR            = /usr/sap/trans
#
DP1/CTC             = 1

DP1/DBHOST          = zuxdc22
DP1/DBNAME          = DP1
DP1/DBTYPE          = db6

DP1/NBUFFORM        = 1

 

But that’s OK – This problem (NBUFFORM and CTC are set correctly, but don’t take effect) will probably be fixed when I upgrade the kernel, which I’m going to have to do as part of the Support Pack upgrades.  But I need to upgrade the kernel when I upgrade the Support Packs, and I couldn’t reliably do that until I cleaned out the transport directories.  Which required an upgrade to the kernel, ….. and of course what happens if the kernel upgrade doesn’t fix the problem ? I needed another solution.

Sometimes you need more than SAP knowledge to get things going.  At this point, I knew there was at least one ‘invalid’ Target System Group in the transport directories, with at least one transport using it.  So I decided to find out what that transport  (and any others with the same Target System Group !!) was ….

zuxdc22:dp1adm 21> cd ../cofiles

zuxdc22:dp1adm 22> pwd
/usr/sap/trans/cofiles
zuxdc22:dp1adm 23> grep U9C_ALR *.*
K111738.DP1:HERMANNMA    K /U9C_ALR/  3   0   0   0   0   0   0   0   0 1 46C   .  0   0   0   0   0 000

zuxdc22:dp1adm 24>

Remembering that the contents of the /usr/sap/trans/cofiles directory are text files (the /usr/sap/trans/data files are binary), I was able to edit the cofile for the transport in error (I used vi because this was on an AIX system).

zuxdc22:dp1adm 24> vi K111738.DP1

zuxdc22:dp1adm 22> pwd
/usr/sap/trans/cofiles
zuxdc22:dp1adm 23> head K111738.P9C
HERMANNMA    K U9C  3   0   0   0   0   0   0   0   0   1  46C   .  0   0

0   0   0 000
….
….
zuxdc22:dp1adm 24>

 

I corrected the transport in error, and reran tp check all to see if there was anything else in error, before running tp testold or tp clearold.

 

Some Notes
This is a fairly esoteric example of where pure SAP skills won’t help with an SAP related problem.  It was actually worse than I’ve described above, as my second run of tp check all highlighted a Target System Group that had 45 transports belonging to it.  I fixed these, thinking if there were any more errors, I would have to find a different way to approach the problem, but they were the last errors.

Depending on the number of errors, I would also look at installing the latest copies of the tp programs and modules in a separate directory.  Without having gone through it, I can’t think of any logical problems, but it would have been an interesting exercise…  It may have been more time consuming, though, which also needs to be taken into consideration.  For what its worth, the way to check the release level of the tp program is described in OSS Note 155350.

When have you had to go above and beyond SAP, to get the job done ?  What non SAP skills do you get to use on a regular basis in your SAP work ?

Validating Passwords on Websites

I feel a bit ordinary writing a blog post about something as trivial as one line of javascript, so I decided to include a picture as well.

It shows a screen from the guided procedure for Solution Manager Configuration.  The interesting part is what I have done wrong.  I’m using the javascript referred to by this link ( Show Passwords ) to display the value(s) of all password fields on the current web page.

In this case, the Administrative User values are the same, but the Administrative Password fields are different.  Since they are using the same User Source (the ABAP engine), one of the values (or both !!) must be incorrect.

Save the javascript by dragging the Show Passwords link to your bookmarks, or by saving the link to your bookmarks.  This has been tested in IE6 thru IE8 and in Firefox.

SAP’s SME Solutions – A Guide to the Product Portfolio

I recently came across an interesting article on SAP’s SME Solutions – A Guide to the Product Portfolio. It breaks down the four SAP products for SME products by size, functionality, industry coverage, deployment options and cost of ownership.

The most important point the post makes is that there exists a range of SMEs, and that a one-size software solution does not fit all. This leads to some further points worth noting.

The smaller the SME, the less likely they are to adopt complex technology. While there is movement to Linux and open source ERPs (because of the TCO perceptions), when they do get into technology, they tend to select Microsoft platforms (e.g. .Net, SQL Server).

Because of TCO concerns, the smaller SMEs were the first to adopt software as a service (SaaS), and that model continues to gain traction within the SME market. The implication is that any SME strategy must include a SaaS strategy.

SAP Product	Product Description
SAP Business Suite	The “original” suite of applications for enterprise-class customers. Includes ERP, CRM, PLM, SCM and SRM. Built on the original (and evolving) ABAP/Java platform.
SAP Business All-in-One	A partially “pre-configured” version of Business Suite, offering 80% configured solutions for larger SMEs in a wide range of industries.
SAP Business One	>A completely different product designed for smaller SMEs. Acquired in 2002 (through TopManage), the product is developed in Microsoft .Net technologies.
SAP Business ByDesign	A completely software as a service (SaaS) system developed by SAP and introduced in 2007. For SAP, it’s an entirely new approach to software design and deployment.

Given that its a blog post, the article does a good job of detailing the four SAP products that resulted from the new SME Strategy, albeit at a high-level view. While it won’t answer all your questions, it will give you a good starting point, especially about costs and appropriate products, for your conversation with SAP or your implementation partner,

SAP career paths for BASIS or Netweaver Technical consultants ?

Now, I may be biased, but I had to start off with this quote from Jon Reed

Before I get to the videos, I want to say that Basis is one of the most neglected areas in terms of SAP career content. Even on SDN, there are way more conversations and forums on development than Basis. This is too bad, as the Basis/NetWeaver Admin role is a vital one to most projects.

No one else is managing your career or your future. If you want more control and choice over where you work and what you do, I recommend you read Jon Reed’s latest career advice and career trends. Jon is an SAP Mentor and his name is probably familiar to you already through his SCN blogs and ASUG and Sapphire presentations. He’s got about 15 years experience in analyzing the SAP career market, and he has worked in SAP recruitment. This all adds up to someone who knows what the SAP job market is looking for, and what makes some candidates more marketable than others.

The white papers Jon created are

• SAP Career Outlook 2010 – Part One: Creating a Winning SAP Skills Strategy for 2010, and
• SAP Career Outlook 2010 – Part Two: Beyond the Social Networking Hype: Achieving SAP Career Visibility

You can also access the white paper on Jon Reed’s website.

However, one thing you will notice is that these particular whitepapers emphasise the functional and developer career paths; there is not much reference to the BASIS or Netweaver Technical Consultant career path. Jon identified this himself in another post, this time on his web site, What is the SAP Career Path for Basis Administrators – NetWeaver Engineers?. He has taken a presentation on the career path for Basis-NetWeaver prosby SAP Mentor Tony de Thomasis of Australia Post (based in part on Jon’s earlier work referred to above) and taped four commentary tracks through Tony’s Prezi slides.

…. just resting on our laurels isn’t going to cut it in this economy – “stronger measures” are required. Part four gave me a chance to share my views on the content as a whole, and why it’s so important to find an SAP career path that combines skills marketability with a passionate, or even soulful, angle.

I used to say I was in BASIS (which is why this blog was called basissap.com). However, many people seem to see this as being restricted to R3 ABAP Administration, with perhaps some particular combination of OS and DBMS skills. Nowadays, regardless of the platform your SAP system(s) run on, BASIS Administrators / Netweaver Engineers need knowledge of their site’s OS / DBMS combination, good windows server administration skills (for managing your TREX, and possibly EP, systems), maxdb knowledge (for your SRM system), etc etc.

With all these skill requirement, possibly including other duties as well (depending on the size of your environment), how do you avoid being jack of all trades and master of none ?

For your own sake, you pick two (maybe three) Core Skills in BASIS or Netweaver and become the local guru in those. This provides security of employment; in other words, you know enough about the SAP core to be valuable to both your current employer, and future employers.

Pick another couple of areas that interest you, but aren’t crucial to your organisation (at least, not yet). Jon refers to these as Edge Skills. They should be skills that are on the horizon, either within the SAP ecosystem, or your organisation. These are the skills that will make you employable in the future.

But what about all the other areas ? In one of my previous incarnations, I was an MVS Systems Programmer. The most important thing I learnt was how to use the manuals (they weren’t online when I started). A key part of this was my own notes – Knowing where to find the official answer or process isn’t always enough, you need to get it working, and sometimes you only perform the process once every couple of years or so, and it is difficult to remember exactly how it works from time to time.

Keeping records of what works and what doesn’t work, especially in relation to your own environment, gives you an edge on those who don’t, and of course, it is nice to know what the real process is (as opposed to what the books say !!).

A word of advice here; do not horde your documentation or knowledge –

• its hard to get moved to the exciting new project if you’re irreplaceable, and
• after all, you’re getting paid to support and help.

It also identifies you as someone who will help, who will answer questions about (or can find out) what really works.

Another way of finding out stuff is experimenting with your own system; an SAP preview system, or one of the New Community Developer Systems. These systems, well removed from the semi production status of the ‘real’ Development and Testing systems, provide scope for you to experiment and develop ideas into implementable services. This identifies you as someone who can bring real value to the SAP Environment, the IT organisation, and your employer in general.

Finding what tables and fields lie behind an SAP transaction

A standard BASIS problem is the generic “what is it doing and why ?” question. This could be in the context of debugging a program or process, or trying to work out what configuration changes are required to make something work. It generally occurs when the development or functional team have moved on, leaving someone who knows what to do but not why – usually a user (under pressure from their boss) who just wants to get the system doing what they’ve been told it should be doing….

However, your BASIS team (or person) has to be a jack of all trades, with not just a smattering of SAP functional knowledge, but also a working knowledge of Networking, Desktop PCs, the Operating System(s) and Databases(s) their SAP systems are running on and so on.

I’ve found that the best way of dealing with this need to know something about everything is not by trying to know everything, but by knowing how to find out everything. An example of this is comes from Jerome Mungapen’s SAPLOG, where he provides a useful reminder of some of the various ways of finding what tables and fields lie behind an SAP transaction:

Have you ever been frustrated trying to find which table and field a piece of data is stored in. You can see it on the screen, and the old faithful F1 – F9 results in some useless structure information. Or have you ever started looking at a piece of functionality you are unfamiliar with wanting to find the table structures behind it in SAP. Well this article shows my favorite five ways of digging under the hood to find out what’s going on.

Jerome lists five methods, but one of them assumes you have the time (and need) to get really in depth knowledge of a given area of SAP. I’ve listed the four methods I use (plus Jerome’s extra one) in the order I’ use them when closely examining or debugging a transaction I’m unfamiliar with.

Use a Different Field

If the technical information pop up shows a structure and not a real field, just try another field on the same area of the screen. It is surprising how often this works !!

Use Where Used on the Data Element

From the technical information pop up, select the data element then press Navigate to get to the Data Dictionary. Once there, press the Where Used button.

Trace Analysis

Transactions SE30 Runtime Analysis and ST05 SQL Trace can be over-kill for determining what fields and tables are being used, but can be used to see how (for example) configuration data controls how and / or when the fields and tables are updated. It’s also useful when dealing with Z or Y code, structures and tables.

SE80 Object Navigator

This is probably more useful for a functional person, and is not available on the older SAP releases anyway. However, if you know the program behind the transaction, you can use SE80 to find all the Data Dictionary objects (including tables and fields) associated with that program.

Environmental Analysis

For those requiring a wider understanding of how a given area works in the SAP system. Jerome’s explanation of Environmental Analysis says it all.

ECC6 SE16N vulnerability and logging – UPDATED

Please remove SE16N, or access to SE16N, from your production systems.

UPDATE

UPDATE – This topic was the subject of a blog by Kevin Wilson less than 2 weeks ago, at which time it was discussed extensively.

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16008

As long as DEBUG access is very tightly controlled, your system should be protected from the risk of this transaction….

I’ve known for a while that, in some releases of SAP, transaction SE16N can be used to change SAP tables, regardless of authorisations or security settings. It’s not something I’ve been keen to see widely disseminated, as there are major systemic risks in making changes this way. More dangerously, it provides a way to override authorisations by giving your userid (or your accomplice’s userid) the SAP_ALL role.

Essentially, you run transaction SE16N, then type &SAP_EDIT into the command field and press enter.

In the example below, I’ve changed the User Group to SUPER.

Personally, I’d recommend making the transaction unavailable (perhaps even removing it from TSTC ?) in your production system – Your firefighter userid can be given authorisation to allow the appropriate people to add it back in, if necessary.

The reason for mentioning it at all is that SAP Mental Notes and IT-Toolbox SAP on DB2 for z/OS have stated that changes using this method are permanently logged in the tables listed below:
SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data

This means, in theory, that you can can query these tables to audit the usage of SE16N to change data. Personally, my attitude is that it’s all well and good knowing Joe Bloggs has broken your system, but I would rather not have to deal with the broken system in the first place. However, there’s a bigger issue…..

When I tested this out on an ECC6 IDES system (DB2 on Windows 2003), the SE16N_CD* tables were not updated.

1 – The knowledge of this method of changing data, which is available on production systems to anyone with access to the SE16N transaction is being more widely disseminated.
2 – There appears to be at least one major platform / release that does not support audit of the method of changing data.

Install SAP on Amazon Web Services #2 – the Installation

After my previous post, you either have your own Windows 64-bit AMI image, or access to the Public AMI I have created, called sap.nw70.win-64.db2. In this exercise, we will use this as the basis of a new, private, image that will:
* contain the appropriate installation data (including registery keys) for SAP NW7,
* be capable of online / offline backups, using SAP tools,
* provide a painless way of running 24×7.

Prerequisites

* EC2 and S3 Accounts with Amazon,
* access to a Solution Manager system (for the installation key),
* access to an OSS ID with download authorisation.

Architechture

Once we terminate an Amazon instance, we lose all changes to it. Saving our database and configuration changes by bundling the changed system into a new AMI will take a non trivial amount of time; Certainly enough to prevent it being run 24×7. Additionally we will lose lots of usefull ABAP and JAVA stack logs unless we bundle the running instance every time we shut it down.

Just as well there’s an alternative, called Elastic Block Storage. This allows you to create data volumes and mount them on your image. They are persistent, and more importantly, can be backed up by snapshots, from the AWS Management Console.

So that leads to an architechture (or rather, disk layout) as follows:

• Drive C: AMI instance, boot disk
• Drive D: AMI instance, ephemeral disk (data lost whenever instance shuts down)
• …
• Drive H: AMI instance, ephemeral disk (data lost whenever instance shuts down)
• Drive W: Persistent Disk, for storing disk-to disk backups DBMS and / or logs
• Drive X: Persistent Disk, for SAP and DB2 Intallation
• Drive Y: Persistent Disk, for DB2 logs
• Drive Z: Persistent Disk, for storing installation files

Creating EBS (Persistent) Volumes

To create EBS Volumes, go to the EBS Volumes section of the Amazon Management Console. The major issue with creating volumes is that you can only attach / mount an EBS volume on an instance that is running in the same Availability Zone. This does mean that all your volumes must be in the same Availability Zone, if they are to be attached to the same instance.

I’ve created four volumes, corresponding to the Drive Letteres I gave in the Architechture section above.

• Drive W: vol-a82bc7c1, for storing disk-to disk backups DBMS and / or logs
• Drive X: vol-3f658956, for SAP and DB2 Intallation
• Drive Y: vol-4451bc2d, for DB2 logs
• Drive Z: vol-fc2bcb95, for storing installation files

Note that these are empty, unformatted, unmounted, unattached volumes (at the moment…).

Attaching EBS Volumes to our Instance

To attach the volumes to an instance, we need to have an instance running. Start up an instance of your image or of sap.nw70.win-64.db2.

Note that I am creating an x.large instance in the availability zone US-east-1b. I need the x.large instance to provide enough RAM and Swap Space for an IDES ECC6 system, and I’m starting it in the US-east-1b availability zone because thats where I located my volumes (no particular reason).

Once the instance is running, we can attach our volumes via the Attach Volume Button.

The result is that our volumes are now “physically” attached to our instance. Again, these are empty unformatted unmounted volumes.

Now we need to logon to this instance. If you are running an instance of sap.nw70.win-64.db2, you can logon as user sapinstall, password sap123. Use the Remote Desktop Connection, and specify the public dns name from your instance.

You assign a name to a volume when you are formatting it. You do this by running the Computer Management (if you’re running an instance of sap.nw70.win-64.db2, this should be on the Desktop of user sapinstall) and formatting and naming the volumes. Make the names distinctive, and related to their purpose, for example sw_repository.

Now use the C:\Program Files (x86)\Amazon\Ec2ConfigSetup\Ec2ConfigServiceSettings.exe program and the Drive Mapping tab to control which volume gets mounted to which drive letter. This is important, because we want to make sure that our sap_install, db2_logs, and backups volumes are always mounted on the same drives. Once the current image is bundled and registered, any instance launched from the new AMI will contain the setting we have configured in Ec2ConfigServiceSettings.exe.

Note the relationship between the volumes and Drive letters in the image below compared to the description of each volume given in the Architecture description above.

System Specific Configuration

Change the hostname (or in Windows terms, the Computer Name) to one of your choosing (Start –> Control Panel — System –> Computer Name –> Change). Run Ec2ConfigServiceSettings.exe. and make sure the Set Computer Name flag and the Sysprep flag on the Syprep tab are disabled – They should already be disabled, if you are using a copy of sap.nw70.win-64.db2.

Check the swap space (Start –> Control Panel — System –> Advanced –> Performance Settings — Advanced, Virtual memory). Again, this should already be correctly set if you are using a copy of sap.nw70.win-64.db2.

Edit the hosts file in C:\windows\system32\drivers\etc to include your Computer Name as a valid host name, for internal SAP and DBMS connectivity.

Do not forget to change the password of the sapinstall user. Otherwise, anyone who reads this will know the password.

Finally, bundle the instance using the AWS Management Console and register the resulting image under your own image name. The purpose here is to save the customisation you have done if you have a problem with the SAP installation. As part of the process of bundling, the instance is shut down and restarted.

You do need to have an S3 Bucket (or directory) to store the Image in.
However, you can store multiple images in the same bucket, by varying the Amzon S3 Key Name.

For future reference, if you restart the instance yourself, using Start –> Shutdown and specifying Restart, you don’t loose any information or configuration from the C drive as you would if you terminated it from the AWS Management Console. This is because the later removes the underlying resources, while using Start –> Shutdown –> Restart doesn’t release the underlying resources.

Security and Firewalls

EC2 provides its own set of firewall rules called Security Groups. The defaults values are, essentially, just enough to get you access to the server itself.

Since SAP communicates via TCP/IP, we need to make sure that our instance(s) can be accessed via the ports used by SAP for its various services. This means we need to add the ABAP and Java ports for both our instance and the diagnostic instance.

Remember that the Windows Server underlying your new SAP system is on the Internet, and is accessible (by Design !!) from anywhere else on the internet, so only open the bare minimum of ports.

Installation

Download the appropriate files from http://service.sap.com/swdc (you’ll need an S number with download authorisation), extract / expand them and store the results on the Z drive. I stored the download files under Z:\NW70SR3 and expaneded them into their own folders on the Z drive.

Make sure you read the appropriate OSS notes. For the ECC6 IDES, the important ones are:
0799639 – General IDES related
0956921 – NW7 ECC6 SR3 IDES related
1244548 – NW7 ECC6 SR3 IDES related
and
1126127 – DB6: Deferred Table Creation and Row Compression

Otherwise, the install follows the standard process, as detailed in the appropriate installation guide (in my case, the NW7.0 SR3 ABAP+JAVA / Windows/ DB2). The two exceptions are:
* Specify that the SAP and DBMS Installations go on an EBS volume (i.e drive X)
* in my case, specify that the DB2 logs go on an EBS volume (i.e. drive Y)

The full IDES install took around 30 hours run time (think of it as $20 or so well spent) from when I started sapinst (that time did include checking and amending my previous implementation notes). The majority of the time is spent loading about 150GB data into the DB2 database. However, once sapinst had accepted the Solution Manager Key, you can disconnect RDP and leave the install running.

Saving your image

Once the installation is complete, you’ll want to back it up before you go any further. Using the SAP MMC, shut down SAP (or logon to Windows as the SAPService<sid> user and shut down SAP).

Use the AWS Management Console to bundle your running instance.

Once it is bundled, register the bundle as an instance.

You can share this with anyone with an EC2 account, by using Permissions to mark it Public, or you can share with individuals if you know their EC2 Account number. Note – Bundling a windows instance restarts the instance.

Basically, the image consists of whats on the C Drive, so backing up your EBS Volumes requires you to use the AWS Management Console to save snapshots of them. The EBS volumes are stored and charged for at the Amazon S3 rates. Just like EC2, however, you are only charged fo what you use. This means that if you define a 500GB volume, write a 1 GB file to it and create 4 snapshots of the volume, you will charged for 5GB of storage; 1GB data on the volume, plus 4 lots of 1GB of snapshot. backup.

When you’re finished with the instance, shut down SAP and don’t forget to terminate tthe instance via the AWS Management Console (otherwise you’ll be charged for it !!).

Running your SAPSystem

Start an instance of your image and attach the EBS volumes to the running instance. The work of of assigning drive letters, in the correct order, to each volume is controlled by our configuration work earlier in Attaching EBS Volumes to our Instance. One of the issues currently outstanding is that thess will actually get mounted on subsequent restarts of this instance (which we perform below).

Logon to the instance and update / verify the Swap Space sttings via Start –> Control Panel — System –> Advanced –> Performance Settings — Advanced, Virtual memory.

Regardless of the previous paragraph, restart the image using Start –> Shutdown -> Restart. With all Drives correctly assigned, and sufficient Swap Space assigned the DB2 and SAP Services for SAP MMC will start. Go into SAP MMC and start your SAP instance. Once SAP is running, you can disconnect from the instance.

Accessing your SAP System

Assuming you have opened the correct ports in the Security Group specified for this instance, you can now put the appropriate values into your SAP GUI …..

…..and access the ABAP Engine.

Again assuming you have opened the correct ports in the Security Group specified for this instance, you can go into the SMICM transaction and enable a simple service, then access it via a browser or web service.

Whats next ?

You now have a running SAP system. However

• No DBA processing, i.e. no DB13 jobs, no backing up of logfiles etc has
  been implemented, so once you’ve tested connectivity, stop the SAP and
  DBMS systems and take snapshots of your SAP & Database volume.
• The SAP*, DDIC and IDADMIN passowrds are well known (or easily determined). Change them
• No post implementation work (i.e. SGEN) has been done,

The purpose of the exercise is to demonstrate how quickly you can run up a demonstration, training or testing system. Depending on how many resources you want to pay for (CPUs and memory), this can be quicker or slower.

However, it has been my experience, based on several green fields implementations, individual system implementations and upgrades, and feedback from others, that building an appropriate server – whether physical or virtual – can take up to 2 weeks. Using the approach detailed here, services such as provided by the Amazon EC2 service reduce this to the 45 minutes it takes to configure and bundle a standard public instance.

One of the obvious issues is that it is well and good using predefined data, which you can download, in zipped form, from OSS (such as the IDES data I used in this example). What about copying ‘real’ data fron an existing SAP system, especially if we’re talking TerraBytes ?

I’ll discuss this, the bandwidth of a portable hard disk and more of the Amazon Web Services features that are particularly useful for SAP in my next post.