Tuesday, December 21, 2010

Actuate iServer RSSE upgrade

So you're going to upgrade your Actuate iServer implementation. After you read this, you might consider moving to the 'Cloud' with your deployment. Then again, it really isn't to difficult to do but you'll need to know how to apply version specific jar files and recompile.

On the topic of moving your reporting enterprize to the 'Cloud' check this article, where Actuate's CEO talks about being architected to 'move from the warehouse to the cloud'. http://www.v3.co.uk/v3/news/2273651/actuate-birt-open-source

Now the secret to upgrading the iServer RSSE... Really it is a matter of first simply extracting your iServer installation and deploying the iServer. Then you will have a folder named /acrsse/. Here you'll find a few example Security Extensions. Pick the one that you have implemented for your custom RSSE, then pull all the bin/jars out and use those in your RSSE project.

Compiling against those, and changing the version number in your configuration class will give you the new updated RSSE, provided something doesn't happen to the foundation classes... As it sometimes does; just read the release notes if you don't want to do a bunch of needless troubleshooting.

Wednesday, June 23, 2010

Why does it take so long to do something so "simple"?

If I've been asked once I've been asked a thousand times; "how long will it take to create / convert / build / etc... ?"

So, how do you answer this question? For example each report request is like a custom implementation of a one-off design. Sure, a report request is rather limited by what a user is asking for. Sometimes it is a request that the user wants some information based on how some other information is reported. For example; "I'd like a report that looks like the Marketing and Sales Report, telling me how many inquiries my reps are answering per hour.?

Sounds simple enough; basically locate the source of the data, do some simple math and use the template (or the Marketing and Sales Report as a template) to build the report. Ultimately you'll be asked "so, when do you think I'll have it?" What they want to hear is probably expressed in minutes or hours. And some tools and frameworks can make this happen (BIRT Report Studio) but you'll still need to do some work on the front-end to set this stuff up. In either case, it takes some time. So, back to the question, how long will it take?

If you were to simply piece together some attributes from a data set created from the query you built from your investigation on where the 'Call Center Inquiry' data resides, you'd have something to show in a matter of an hour or two at most. Problem is, it will very likely not be what the user wanted or they'll have some fine-tune suggestions / requests. Before you know it, you'll have gone back and forth between tweeks & fine-tune requests for a week. So, how long did this simple request take? an hour or two or a week?

How do you answer this question? Do you have a formal request process? If so; does this process severely reduce your service level overall? Should you simply not make reports request available untill after a "Self-Service" Reporting framework like BIRT Report Studio is in place?

Thursday, May 6, 2010

Down To The Wire Change Requests

So, I'm logging out to catch a flight. Code freeze is tomorrow, and code release is scheduled for next week. Why then, do some users wait until NOW to tell me about corrections and tweaks to reports? -- (...yes, a couple... even I am not perfect!) -- My answer; they just don't care until they're reminded of the code freeze and impending release. Procrastination at its finest!

It's a good thing I am using something as flexible and easy to modify as the BIRT Reporting Application. Changing things like column header names, some data type formatting, even script logic on various report elements is not a big deal (most of the time). This reminds me, that it is always a good thing to take the responsibility as a developer, to create a 'sign-off' check list. Trouble is, I HATE lists! But worse than that, I REALLY HATE being late to the Airport!

I think I'll create a check-list and post it here (later)... why not procrastinate? everyone else does!

Monday, May 3, 2010

In Canada again!

Longterm assignments are good, but they do have their drawbacks. First and possibly the biggest drawback is the "boredom factor". Secondly, it seems to me (possibly related to boredom factor), they longer I go, the longer the weeks seem to get.

Now that I have gotten that off my chest, this is not a bad assignment at all. I most certainly have had worse. The best assignments are usually a blend of three things; 1-Location, 2-interesting / cool people, and 3-technology of interest. There is nothing worse than being on an assignment where you can't stand the location, if for no other reason than the office is just plain crappy. But, even in a nice location, with very cool geographic and environmental surroundings if the people suck, the job sucks. And finally if the first two items on the list are okay, I can live with the technology being boring or sucky... at least for a little while.