Monday, October 12, 2009

SAP TechEd 2009 - Phoenix - The Start

This convention has started out just fine. I got to Phoenix late and just barely made the early registration at the convention center. I got to the hotel only to find that my room key didn't work. So I hauled all my stuff down the nineteen floors to the lobby only to be told to come back and wait for security to help me with my door (apparently their thought was I am too stupid to know how to use an electronic key). Magically it worked when I came back up so 'apparently' I'm not that stupid.

Talked with an interesting gentleman named Keith from the Canadian Railroad. He's a system architect here to learn about SAP for the first time. We discussed how much there is to learn about SAP and why it may be better to just try to learn as much as one can 'fire hose' style.

As much as that sounds like a bad idea it's actually a good one. There's so much to learn about SAP that trying to figure it out one tiny bit at a time takes too long. It's better to jump in with both feet, gather as much information as you can, and let time help you figure out the larger aspects of these massive applications.

I also had a chance to catch up with an old colleague that I worked with on a 4.7 install in Montana. All of the original SAP applications I installed have been replaced. But many of the smaller Linux based applications that I helped develop are still running in the same form that I left them. It's good to know that something I built in my Pre-SAP admin days are still alive and kicking (demonstrating the stability of Linux based applications).

My last task for the night is to get ready for tomorrow by downloading my agenda (one thing I forgot to do before flying in).

Tomorrow I look forward to meeting new folks and catching up with a few others. Good times ahead.

Tuesday, July 7, 2009

Crazy Day

Today was one of those crazy days where you have little time to sit down and sort out the day before the requests start coming at you. This morning it started off with a bunch of transports coming for our European system. We've recently taken over this system so we have been getting up early to move transports in while the folks over there can test. The upside is we have been updating like crazy. The downside is there is quite a bit to keep track of.

Once that blast was finished I started off with some requests for user changes. Our other basis guy is out so I took over the auth updates. These sound all so simple but like everything else with SAP it requires a bit more energy as changes need to be tested and updates verified. Luckily, we only added a few transactions to a new role so we just verified that the transactions worked for a series of company codes.

The next project came up as some functional folks working on some IDOC payment transfers wanted to start the process of moving transports into a QAS system. From my side, all they needed was some verification on what should move when. I responded by listing all the changes that needed to be made and the order they need to be made in (create directories first, then setup the port and then the partner profile). Once they had this info they wanted to test some port setups in DEV and called for my assistance once again. So back I went to discuss the role of the ports (WE21) and partner profiles (WE20) and if they could assign one port for each message type within the partner profile (this is possible).

In testing we came across an interesting issue. We updated the ports within a partner profile and went back to test with some unprocessed IDOCS (within BD87). This did not work because the old IDOCS had the port settings already cast within the IDOCS themselves. So to test the new ports we created new IDOCS (which confirmed that the new port settings worked as needed).

Finally, I ended the day working on some metrics for a new SAN that is being installed. Due to resource constraints, the original SAP systems were installed on to one storage partition. We provided the size of this to the vendor but found out that these are not that helpful since we will be splitting up partitions for the various application areas (this will include partitions for the Oracle logs, data, control files and so on).

In short I was busy all day. It feels good to be so productive. The hardest part about being so busy is I had little time for some planning that needs to be done. But tomorrow is another day which will hopefully be less busy.

Wednesday, June 24, 2009

Migration Follow-up

After completing a system migration and trying to fix the issues created by using a newer SAPINST I thought I would follow up with one final set of steps I followed to complete my install. 

To fix the kernel issue I downloaded and extracted a new set of tools and a set of brtools to match the kernel. The SAPINST program installed version 7.00 of the BRTOOLS which won't work with Oracle 9.2. so I had to 'downgrade' to a working version. Before applying the new kernel and brtools, oradev was able to attach to the database and update statistics. But after the update I started receiving an 'NLS' setting error. I tromped through all of the environment variables thinking this was the issue but everything I tried failed. That's when I returned to the Oracle Client install and re-ran the linking script named 'CROCLLNK' (the whole command was 'CROCLLNK -v -b 64'). That fixed the brtools issue for both oradev and devadm. Luckily, the SAP notes were helpful on this matter so score one for the folks in support. 

Again, I think the lesson here is to not use the latest version of SAPINST to complete the import portion of a migration. 

Thursday, June 18, 2009

Hetero Migrations

I just came through a test where I migrated an SAP system from an old Solaris system to a newer system running on AIX. Which, on paper, seems like a simple process but yet isn't.

I have to express some frustration because the migration tools from SAP often get in the way of completing a simple project. And most of the issues that arise from these tools are often things that could have been fixed if there had been more diligent programming and better access to specific pieces of information.

One example is the migration key. I created one of these ahead of time in hopes that I could save time by not having to stop during the data import just to generate a key. Did that work? Nope. I found out the way I was generating the key was wrong (I had selected R/3 as the application type and not 620 which was the kernel). This is not mentioned in the migration guide. 

When something like this fails it can be from various reasons. Is a library missing? Did I leave out an environment variable setting? I have to look through each of these potential issues when a SAP migration fails because the logging just isn't very helpful. Even worse, this error shows up late into the migration process. So the immediate thought is, should I start over? Did I just waste the last 10 hours on this only to run into a minor issue that stops the whole process? Again, this creates a huge amount of wated time that could have been saved with better programming and/or documentation.

The next issue I ran into was an issue created by the R3load program. On import, R3load created multiple entries into one table. Then the entire install crashed because it tried to create an index on a key field with duplicate entries. How stupid is that? The whole migration fails because it can't create an index on a table that I could create manually once the entire migration is completed? That's just silly. How about some restart options that would allow me to get through this? [a newer version of the R3load program did not fix the issue as mentioned in a recent SAP Note]

The other issue I was presented with was the SAPINST program itself. Creating the R3load data from the source system was easy. I just set up the system to generate the export files. But the import process was another matter. For these systems I was migrating from 4.7 to 4.7. The implementation guide states to use the latest SAPINST program to complete the system copy process. Okay. That should be easy I think to myself. So off I to to run SAPINST on the target.

Normally, what I like to do with a system migration is to install a regular version of the application first. This helps get many of the technical issues out of the way (at least that's the plan) and assists in seeing if the system is sized appropriately. Then I wipe out the DB and go back to re-install it using the exported migration data. This works fine except for some crucial problems that the new installer introduces. 

First, even though I chose NOT to install the SAP kernel files the installer ignores my choice and installs them over my current (and in this case an older version) kernel folder. Same thing happens with the DB client files. I chose not to install these and yet the installer uncompresses these into a new folder (again this created a version issue since I was migrating into an Oracle 9.2 database and the client files contained the programs for Oracle 10.2). Again, I found this out during the migration process and it cost me yet more time as I had to locate an older version of the Master Installation programs to continue the process. 

I was able to complete the migration and now have the process documented to the point where we will be able to repeat it several more times without the huge delays encoutered during the massing learning process outline above. 

So if you have to complete any kind of migration yourself, be prepared for spending lots of time hunting down solutions based on the error messages dropped into one of many log files and not based on the information within the system copy guides. 

Hope that is helpful!