Feb 22 2016

When Charts Go Bad…

Categories: Rants Dave Rathbun @ 4:16 pm

I was reading about the FBI versus Apple issue earlier today and came across this graphic:

Pie charts are viewed with anything from disdain to downright hatred at times. I don’t want to open a debate on that. But you would think for something as simple as this, they would have managed to get it right…

I emailed the author of the original article and hopefully they’ll get the picture fixed.


Feb 17 2016

“Working As Designed”

Categories: IDT,Rants Dave Rathbun @ 12:19 pm

Those three little words: “Working as designed.” I hate them.

I don’t know why it took me so long to experience this, as I found this topic on BOB that brought the issue to light years ago. That being said, here’s what’s going on…

In Universe Designer (UDT) a designer can change the state of an object from visible to hidden without impacting a report. I use this technique to create objects that have a specific purpose but keep them out of general circulation. For example, I will often create a class called “Report Objects” that contains objects with special exception handling or a unique purpose. That class is visible in the development environment only, which means my report developers have access to this class. Before the universe is migrated to the QA (and production) environments that entire class is hidden.

This allows me to create report-specific objects without risking an ad-hoc report using one of them incorrectly. It’s a great technique.

A secondary reason why I use the “hide” option is to retire old objects. I don’t want to break reports, but I don’t want any new reports to be created with these objects. Hiding them means existing reports continue to work.

In Information Design Tool neither of these strategies will work. Once an object is hidden, any report that includes that object fails. 👿 Based on information from SAP, that’s the expected behavior. They acknowledge that it’s a change in behavior, but so far I have not found the reason for the change. The bottom line is that it’s “working as designed” and will not be fixed.

Keep this in mind when you consider converting your UNV universes to UNX, as if you’re using the hidden object trick for any of the reasons I outlined above (or others that I may not have considered) that technique will fail in IDT.


Nov 05 2015

Downgrading from Multi-Source to Single Source

Categories: IDT,Universe Design Dave Rathbun @ 10:01 am

I mentioned a few weeks ago that I had found a way to “downgrade” a multi-sourced universe to a single-source. I wanted to create a beautiful blog post with screen shots to walk everyone through the process, but have not managed to carve out the time. 😳 Rather than continue the radio silence, I’m going to write up the steps and hopefully come back and make this post prettier later on. I also have a request to make which will be at the end of this blog post, so please read to the end, and if you can help, please do so.

Background

We, like I am guessing many Business Objects legacy customers, have been slow to dip our toes into the “multi-source” waters offered by Information Design Tool (IDT). When we did our major upgrade to BI 4 a few years back, we evaluated whether we needed to convert all of our UNV universes to UNX, and decided not to, for a variety of reasons. But for new development we are typically looking at IDT as our universe creation tool. Continue reading “Downgrading from Multi-Source to Single Source”


Oct 12 2015

Yes, Virginia, You Can Switch a Multi-Source Universe Back to Single Source

Categories: IDT,Universe Design Dave Rathbun @ 10:07 pm

What’s the first decision you have to make when creating a new universe with the Information Design Tool (IDT)? You have to specify if you want a single-source or multi-source data foundation. Once that selection is made, it cannot be changed.

Well, sort of.

We had an odd performance challenge with a particular universe. It seemed that when it was created, the developer thought they might want to eventually (perhaps) use multiple sources, so they went ahead and created a multi-sourced data foundation. But the project never ended up needing a second data source, so for over a year they’ve been using a single-source multi-source universe. (Did you follow that?) As a diagnostic tool, I thought about recreating a new universe as a single-source data foundation and resetting the various reports and dashboards so they would use the new universe. That would have been a lot of work, and with no guarantee that it would fix anything, much less have an impact on the issue.

Then I wondered to myself, what if I could figure out a way to “downgrade” the existing multi-source universe to a single source? That way I could still test my theory that our data federator engine wasn’t working as well as it should without having to re-point each report and redo each dashboard.

“spoiler alert” … it worked. 🙂 I was able to convert a multi-sourced universe to a single-sourced version without impacting the reports and dashboards, and we’ve been running on that version ever since.

How was it done? Well, I’m working on a presentation for the local DFW ASUG chapter meeting this coming Friday, and once I have that done I’ll post the details here as well. You’ll just have to wait a few days. 😛

Update: I won’t be presenting at the DFW chapter meeting after all, but I will still be posting this solution soon, hopefully next week.

Secondary note: I have also done the process in reverse… converted a single-source universe to a multi-sourced version, but with significantly more work involved. If you have a large number of reports, however; it may be easier to rework the universe and not have to re-point every report. Time will show if I’m successful or not…


Sep 16 2015

It’s Alive!

Categories: General Dave Rathbun @ 9:24 am

Wait… what’s this?

Yes, my blog has a heart beat again. It has been a long time since I’ve been here, and I hope to fix that. I started this morning by reviewing all of the comments that were queued up for approval. I approved most of them and answered quite a few as well. One common question was related to whether my universe comparison macro would work with BI 4.1 or not; I have not had to use it in production on 4.1 yet, but I do have a sandbox environment where I can test that out. Hopefully I will have that done in the next week or two… along with posting the promised update.

Thanks for your patience.


Nov 17 2014

Dagira Change Log Script Update Coming Soon

Categories: VBA Tools Dave Rathbun @ 1:23 pm

Hi folks… a few days ago I posted an update via a comment on my universe compare tool page regarding a small bug. It’s not a huge deal, otherwise I am sure someone would have reported it by now. If for some reason you had a context that had zero joins then the program would not properly detect that and move on without generating an error. I posted what turns out to be a partial fix in the comment area.

While validating that change, I discovered that there are in fact two places where the code has to be updated in order to properly detect an empty context. I also found out that the process was not really finding changes in class properties at all! Oops. 😳 In order to handle the recursive nature of classes (class can contain sub-classes which can contain sub-classes and so on) the output row number for the target worksheet is passed as an argument. It seems that the first row was then cleared out, leaving the actual change log data to start on row 3 rather than row 2. (Row 1 is the column headers.)

Later on when the “detect changes” algorithm is called, it looks for a non-empty value in row 2. Given that this was never true for the class extract, changes in classes were never properly documented. The reason I suspect nobody called this out as a bug before is because the object change detection process was already capturing changes in class names, so at least that part was there. But if there were changes in class help text or visibility attributes or other class properties they were not being captured.

Given that there are several changes coming, I will be posting an update to the downloadable code within the next week or so.

As of today I don’t have any time to even make plans to create a similar version of this utility for .UNX universes created via the Information Design Tool.


Aug 22 2014

Yes, Virginia, You Can Refresh One Data Provider At A Time

Categories: General,Report Techniques,Web Intelligence Dave Rathbun @ 11:45 am

For a while now I have been whining about the fact that there were features dropped from XI 3.1 during the upgrade to BI4, including how the dimension merging process works. Another gap? In XI 3.1 we had the ability from the query panel to run only a selected data provider, leaving the others alone. When working on complex multi-query documents this could be a big help, especially if some of the data providers had longer refresh times.

A few days ago I was grumbling about this yet again and discovered a way to refresh a single data provider! It’s not perfect (nor was it the most obvious workflow for me) but it does work. I had one data provider that was scanning a huge multi-billion row fact table. To supplement this data I needed to run an additional query against an Excel data provider. I had to make several changes to the Excel file in order to help my data match up correctly, and each time I updated the XLS I had to refresh the entire document in order to see the changes… which was annoying and time consuming. Now I have a solution.

Note: Since I’m talking about joining with Excel, clearly I was using the rich client application. However the same technique outlined below works online with multiple universe data providers as well. Continue reading “Yes, Virginia, You Can Refresh One Data Provider At A Time”


Jul 08 2014

Airlines Could Save Millions in Fuel Costs By Providing Everyone An iPad

Categories: General Dave Rathbun @ 11:30 am

There’s an interesting article over at fivethirtyeight.com that discusses various ways that airlines could save money. Like many airline profitability studies this one focuses on things that Southwest Airlines does to remain in the black while other airlines seem to go through bankruptcy every five or ten years. For example, Southwest does not have any in-flight entertainment systems. That saves money in a whole variety of obvious ways (they don’t have to pay for the systems up front, and they don’t have the on-going costs of keeping the systems running) but also in less obvious ways.

Southwest runs about 1.6 million flights every year. At the most basic level, they are in the business of moving cargo (human or otherwise) from point A to point B, therefore one of their primary costs is fuel. The more cargo they carry, the more fuel is required. When I carry my cell phone I hardly know it’s there. Southwest jets have an average of around 140 seats. If I assume 100 of those are filled with passengers with cell phones, the weight becomes a bit more noticeable. Imagine loading up a box of 100 cell phones. 🙂 and then repeat that for 1.6 million flights and the extra cargo weight adds up! In the article they crunched the numbers and determined that Southwest probably pays $1.2 million dollars in extra fuel costs just to carry all those phones. If passengers carry laptops that would add almost $21M in fuel costs. Entertainment systems – if they were present on Southwest – would add almost $40M a year in additional fuel costs. I found it interesting that entertainment systems apparently weighed more than laptops, but then I realized one factor was that planes are not always full. A laptop won’t fly by itself, but an entertainment system might.

Which brings me to what I thought was one of the more interesting propositions made in the article. Airlines that currently offer in-flight entertainment systems could save a ton (pun intended) by eliminating those systems and giving everyone an iPad instead! They could save even more by allowing passengers that bring their own iPad free access to the in-flight media server. Content could be uploaded to each plane while they’re loading passengers. The airline wouldn’t need to provide high-capacity iPads since everything would be viewed from the server, so the 16GB model would be plenty. The cost of a 16GB iPad currently hovers around $400, so they’re not cheap, but given the weight savings (and the fact that iPads could be loaded on an as-needed basis rather than always being on board) the fuel savings would likely more than make up for the added cost.

Using Southwest’s network as a proxy for similar-sized airlines carrying embedded in-flight entertainment systems, we found that fuel costs to carry these systems are approximately $39.7 million per year. When compared with installing embedded systems in the seats, simply handing everyone an iPad when they stepped onboard could save about $32.7 million per year in fuel costs.

Plus I have to imagine if Southwest Airlines called up Apple and ordered 100,000 iPads they would get a better price than $400. 😉

Related Links


Jun 24 2014

Did Florida State Win National Championship By Using Big Data?

Categories: Rants Dave Rathbun @ 9:53 am

Florida State University won the 2014 college football national championship game this past January in a thrilling come-back victory over upstart Auburn. Did big data help?

It turns out that a few years ago FSU started using GPS devices on their players during practice. Each device collects around 1,000 data points every second. The devices are downloaded and analyzed by a special group of coaches and analysts who report back to the head coach. Right now the team is not allowed to tag players during games, so they only use them during practice. Did they help?

One of the things that always amuses me is how often reports — based on big data or otherwise — reveal something we should already know. Two years ago the FSU coaching staff was getting frustrated with the lack of game-day performance from one of their star receivers. It turns out that because he was so good, the coaches were constantly asking him to run extra routes during practice to demonstrate to the other less experienced receivers on the team. By the time the game day on Saturday arrived, he had run much farther than anyone else, so of course he was tired!

Greene was Florida State’s most refined receiver, so when Fisher would grow agitated with poor routes or dropped balls by other players, he would ask Greene to illustrate the proper form. Again and again, Greene would run a route or catch a pass, and his workload mounted. The GPS device offered clear-cut data that showed Greene was simply doing too much.

After tagging the players with the data collection devices the coaching staff was able to recognize this (duh) and make sure he got the proper rest during the week. The player responded with a career best year last year during the FSU championship run.

Related Links


Jun 07 2014

Business Intelligence Lessons from Star Trek – Part Two

Categories: General,Rants Dave Rathbun @ 12:57 pm

Author Note: This blog post was originally a guest entry at The Decision Factor, a site that appears to have ceased publication. I have reproduced it here. It was fun to write, and I hate to see good content go missing. The original post was published in 2012 but I believe the content is still relevant today.

In my first Star Trek post, I explored two lessons learned from Captain Kirk’s leadership skills and how we could apply them to business intelligence. Today, I’ll cover three more lessons.

Be Part of the Away Team

Captain Picard of Star Trek: The Next Generation rarely joined the away team, leaving that role to his Number One, Commander Riker. Kirk operated with far more freedom. Whenever there was an opportunity to beam down to a new planet, he was there. His leadership style demanded that he lead from the front.

I think the corollary with business intelligence work here is obvious: the success or failure of our systems depends far more on establishing correct requirements than on the actual implementation. By being part of the away team, we can be directly involved. Lack of user involvement and poor requirements gathering are generally two of the top reasons projects of any kind fail, and business intelligence is not immune to this problem.

Play Poker, not Chess

In Star Trek, there were numerous times when Captain Kirk and his crew were in a bad spot. In one episode, The Corbomite Maneuver, the Enterprise and her crew were experiencing first contact with a new alien race and it wasn’t going well. At one point, Spock had to tell Kirk that they were out of options and the alien had backed them into a corner from which there was no escape. In chess terms, checkmate. Spock, as a character, was the very embodiment of chess: cold, logical, and process driven. It was natural that he would see things this way. But Kirk was different.

Capt. Kirk: There must be SOMETHING to do. Something I’ve overlooked.
Mr. Spock: Chess: When one is outmatched the game is over. Checkmate.
Capt. Kirk: Is that your BEST recommendation?
Mr. Spock: I’m s… I regret that I can find no other logical alternative.
Capt. Kirk: Not chess, Mr. Spock. Poker!

Kirk took inspiration from the game of poker and bluffed his way out of the situation. How can this possibly apply to business intelligence? We don’t want to lie to our business partners, do we?

Perhaps we do – but in a good way.

I often come into contact with people or business processes that have been rigidly followed for many years. To the mind of the many, there’s no other way to do that particular process. In order to convince them otherwise, sometimes we have to bluff. I like to call this a demo. 😉 In order to make a difference, we have to get past that initial resistance; and sometimes a well-placed bluff demonstration helps us along that road.

Blow Up the Enterprise

Sometimes there’s no way around it. A system that’s well known, trusted, and loved just isn’t cutting it any more. The original Enterprise made it through several years of TV shows and a couple of movies before ultimately meeting her end. As much it pained Kirk to let her go, he realized that in order to move forward, the Enterprise had to be sacrificed. (I may have shed a tear or two myself.)

Legacy systems can often inspire the same attachment, but at some point we have to blow them up so we can move on. “It’s always been done that way” is a poor reason to keep a system around when there are so many new and exciting technologies that have come to market recently. Don’t be afraid to blow up the Enterprise to move forward.

But I think the overwhelming lesson to be learned from Star Trek is don’t wear a red shirt to work.


« Previous PageNext Page »