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.

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. 

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!

Apps that Irk Me and one that suprisingly doesn't

I am trying to break the mindset I have that applications need to be hosted locally in order for them to be valuable or useful. I am used to having the DB server be on a system I can administer or a webserver that I can tweak by updating a config file using vi. So I am highly skeptical that an online application can provide me all the necessary functionality needed to complete my tasks.

I apply that same 'locally hosted' mentality to office suites (although, I don't really know why). I just want to have them local so I at least the ability to change or fix one of the upteen hundred silly things that seem to happen with Microsoft applications (one example being the stupid disappearing menus in Excel 2007). Which brings up the question of whether we have reached the pinnacle of usability with Excel (which I will save for later in this post).

So I am off to try and create documents using Google Docs (http://docs.google.com).

So far, I have been able to copy in a list of performance metrics taken from a clients system and create a graph. Hmm. That is a pretty big step for an online application. Even more impressive is I did not have to hunt for menu or icon needed to create the graph. Its right there on the front screen (see micro screen shot below). That's cool. I don't have to hunt for something. That probably saved me at least 45 seconds and quite a bit of invective energy.

What impressed me even more was I created the graph based on three columns of information and did not have to identify which column contained the labels and which contained the data. That's amazing! This application created a graph without my having to go back and poke around through the selection parameters. I'm stunned I tell you. In all the years of using Excel I can't remember a time where creating a graph did not at least require going back and making adjustments to the data.

So, back to the question about whether we have reached the pinnacle of usability with applications like Excel. I have to believe that at some level there is nothing further that can be added to this spreadsheet, in this current format, to make make it more efficient as a tool for creating reports. All the gizmos and extra doodads in Excel 2007 make it less usable and more annoying. Do we really need to have hiding menus? No.

So, if using local apps means having to live through the silliness of ever expanding application gizmo wizardry, then maybe there is something to this hosted application thing after all.

Back from the Westminster Elks Club

It was a joyful occasion. We met my mother in-law and her boy friend at the local Elks club for dinner. The thin t-bone steak was pretty good and the potato and corn were good additions.

Other than that nothing else of note happened today. I had quite a few meetings at work and was too busy to get back to by SAP Business by Design.

A brief note about BBD. It is a very clever application. It takes much of the functionality found in the Enterprise Portal and applies pre-set business processes against it. So quite a bit makes sense from the minute you log into the hosted application.

Once you do log in you are met with the home page which presents any outstanding tasks that are nearing a due date or have been recently assigned by other workers. Across the top of the screen are tabs that contain business concentrations. Each of these can be assigned one-by-one to each user.

After learning some basic navigation, I was able to go from concentration to concentration. What made the transition easy is each default page within each concentration is the same for each one. So when you go from one concentration to another, you are met with the same layout.

That may not seem terribly important for seasoned SAP users but for mid-market companies that lack the resources for training, this can make a big difference. This can also play a key role where a user is tasked to many different assignments and has to remember how to complete a process in between them.

So far my impression of BBD is favorable and I look forward to how the interface is extended in the future.