The Season for Logs; Yule and otherwise – Part 1
As 2010 winds down, I will resist from writing the typical reflection posting from the past year, and will refrain from the projection posting with my personal forecast of 2011. Instead, I will make a distinctly BOBJ twist on a Holiday mainstay; The Yule Log. How, you ask? Well, it’s simple. The Yule Log is a log. BusinessObjects Enterprise has logs. Lots of them! In this first of a two-part blog, I want to focus on one kind of log and how it can help you, the BOBJ Admin when things go bump in the night. The topic of this part is the Import Wizard, and it’s associated logs.
Not My Favorite Tool
Those of you who know me already know this, but I am not a fan of the BusinessObjects Import Wizard tool. It’s a funky little thing that sometimes does its job and sometimes does not, and isn’t always as reliable as one would hope.
That being stated, I was so pleased to learn earlier this year that the Import Wizard is gone from BI 4 and has been replaced completely. That is totally great news.
Many of us, however, will not be seeing BI 4 for a long time, and are stuck with our friend, the Import Wizard for a bit longer. Whether you are still on XI r2 (like me) or are on XI 3.x and can make use of the LifeCycle Manager, you still have to use the Import Wizard from time to time. When you use it frequently, you will find that it doesn’t always perform as expected.
Down to Basics
The Import Wizard (IW) is most commonly used to move BusinessObjects content either from one server to another (Dev to Test to Prod), or package up BI content into the famous BIAR file. (De-Constructing a BIAR File) Most BOBJ administrators know that part. What they may not know is that the Import Wizard creates a log file on your hard drive for every import job it conducts. The IW stores logs in two places:
- C:Program FilesBusiness ObjectsBusinessObjects Enterprise 11.5Logging
- C:Program FilesBusiness ObjectsBusinessObjects Enterprise 11.5win32_x86
In XI 3.x
- C:Program FilesBusiness Objects 3.1BusinessObjects Enterprise 12.0Logging
- C:Program FilesBusiness Objects 3.1BusinessObjects Enterprise 12.0win32_x86
You would think that the logs in the Logging folder would be the best, but they aren’t so much. The best logs are in the win32_x86 folder, and each log is paired with an XML file. These are the logs I have found to be the most useful, because it has a record of every single object that was published during the IW job.
I know what you’re saying… “Why do I need to bother with this log when the IW gives me a summary of the job once its done?”
I’ll tell you why, and back to my beef with the tool. The IW is not always perfect at telling you when something went wrong. There are times when it will deliver an entire job with no errors, and yet, when you check the target system, things got missed. This is where you log files can be invaluable, and why I make a habit of saving them.
For example, I moved a BIAR file from Dev to source control, then from source control out to Testing. I knew there were 27 reports in my BIAR file, and when I was done with the deployment, the summary told me that 24 reports were moved successfully and reported no errors! So now I had to figure out which 3 reports got left behind, and why. Log files to the rescue!
I opened up the log from when I created the BIAR file, which had the names of all 27 reports in it. I loaded those up into my favorite text editor, and after a little manipulation, find and replace, and cut and paste, I had a list of 27 report names. Then I took the log file from the deployment to Test which had errors, and spent some more time creating the same list of reports. I did an alphabetical sort on both lists, the lined them up and it became apparent pretty quickly which three reports were missing!
I was then able to target my next deployment to just those three reports, and the second time they went into Test just fine.
Of course, the log wasn’t able to tell me why they didn’t go the first time. I even opened a ticket with SAP Support, and when I told them what I did to recover from the issue, he said it was (his word) “amazing”. I’m not sure I agree with that assessment, but it was nice to hear. Flattery aside, it’s a pretty solid way to figure out what got missed in the absence of an error message, but it means you have to be a little diligent beforehand and make sure you have the logs from a good deployment and a bad deployment.
The IW isn’t perfect, which is why it’s being phased out from the product and being replaced with much more sophisticated content management tools like the LifeCycle Manager. But for those of you who are stuck with it for the time being, like I am, I hope this makes your administration job a little bit easier.