Actuate Programming Journal

Report design from a guy who thinks he knows what he’s doing; you decide . . . .

Actuate Colors

leave a comment »

Actuate allows you to define your colors using a color picker–then converts them to RBG(51,22,255) in the properties box.

Or you can use the commonly named values you see below.  I think these are straight out of CSS or maybe Windows’ color list.

actuate color chart

Advertisements

Written by Douglas

20070718 at 08:37 am

Posted in Actuate, Color

Tagged with , ,

Viewing Actuate Files

with 11 comments

This is inspired by my trawling of the referring ‘search terms’ part of my stats program for this site.

Unless you are a developer, attempting to view an Actuate file is probably a waste of effort.  What you want to focus on rather is the output on the web.  Here is a run down from first to last…

RODs are design files that are only openable using Actuate’s IDE.  ROLs, libraries, are the same deal.

The IDE produces a BAS file from the ROD when compiling.  It’s not clear to me if this is a requirement of the compile or a bonus for developers.  In either case its a text file easily viewable in anything that displays text.  You cannot compile this file, but you can painfully reconstitute a ROD using it.

ROXs are generated by compiling a ROD and are placed on the server for execution.  They are not viewable.

ROIs are the result of the execution of a ROX (and some other less important files).  In the old days we viewed these files directly in the web browser with a plug-in for te browser.  These days Actuate has some bit of code ont he server that translates these into DHTML.

So, if you are a user, you are most likely going to view these on the web.  Depending on your acess you will have options to download as text, PDF, or spreadsheet.

If you are a developer, it’s a weird search to be doing.  Stop it!

Written by Douglas

20070124 at 12:43 pm

Posted in Actuate, Requests

Tagged with ,

Overriding ObtainSelectStatement( ): Why

with 2 comments

20061218 Update: Sorry for the big tease.  Life slapped a big old “Hold” on me and it’ll be a bit before I can get to the other parts.  Check back, leave comments, or for God’s sake subscribe to the RSS.

This is one part of a five part series: Why, How 1, How 2, How 3, When, Conclusion

Without reservation I always override the ObtainSelectStatement (OSS( )) in lieu of using the Graphical Query Builder (gQE) or even the Textual (tQE) one. It’s been years since I wrote a simple SQL statement without parameters or other dynamic elements, but I am sure I would find myself typing it out by hand in the OSS( ) even if I did get a chance to write something plain.

Why?

I like to work with my hands. And, while I wouldn’t go so far as to claim to be a real programmer, I do like to be able to manage the SQL at the written code level rather than just draw pictures of it. Overriding the OSS( ) allows me to program old school.

The gQE is a great tool for visualizing the database and even constructing SQL (more so than it used to be). You can easily indicate what fields you want to report on, create reasonably sophisticated predicates for filtering data, and even add different kinds of parameters to change things on the fly. The first project I went on back in ’98 used a combination of the gQE and the OSS( ) to build out the SQL logic. SQL statements that could be designed in the gQE was. The more complex needs were worked out by an unholy dovetail of the gQE and the OSS( ).

Even the years I taught the Actuate Suite, I relied upon the gQE. It was fast and obvious and something the students could see. Plus the official materials used it. At the time I hated the syntax for identifying parameters and to this day don’t know how to write them into the gQE.

But let’s fast-forward to my more recent efforts…

In order to meet the often schizophrenic needs of our customers I need to be able to write flexible SQL. SQL that can add an additional table and the requisite joins based on a runtime parameter. Or I need to collect a piece of data from another query in the report and use it in some nested Report Section. Or I need to conditionally modify the predicates in the Where Clause. Or I just have a big-ass database and can’t be bothered with waiting on all the thousands of tables to load in the browser.

In any case, I need more control.

More access.

Less hand-holding.

Overriding the OSS( ) gives me the power I crave.

I’ll show you how.

Written by Douglas

20061201 at 12:33 pm

The Actuate Scratchpad

leave a comment »

For those of you new to building reports and maybe IDE usage in general, the scratchpad is a handy little tool that operates exactly like the top of your fridge.

Returning home from the market with orange juice and a fresh gallon of milk you discover the old milk–which is still good–on the front half of the shelf and all the other shelves are full. The orange juice needs to be all the way in the back, then the new milk, then the old milk. Without hesitation you swap the old milk to the temporary top of the fridge, slot in the OJ, the new milk, and return the old milk to the front.

Mainly this scenario occurs in relationship to Group Sections for me. I have Nation, State, and City groupings and someone changes the requirements to have County between State and City well after I have created the others. The whole City mess goes into the scratchpad. Create the County grouping and then drop City back into the content slot of the County group.  I have used it for a few other temporary things but not much else.

Handy, but also a little evil.  Because everything I have ever left in the scratchpad too long went bad quickly.

  • The scratchpad gets compiled, so you can’t have errors in the code you aren’t using
  • You can subclass things from the scratchpad–this becomes the same kinda mess I find with libraries

Any component in the scratchpad has EXACTLY the longevity of milk on the top of your fridge.

Written by Douglas

20061115 at 11:12 am

Posted in Actuate, Best Practices

Actuate Interviewer Questions

with 4 comments

I struggled over the wording of the title. Then decided I would leave as is and simply clarify in the body.

These are questions I ask you when I interview you for an Actuate Report Designer position at the company I work for not questions you should ask as the interviewee.

My role in these interviews has always been in the “some of our technical guys would like to talk with you” capacity. I am most definitely not the descision maker, so I can’t say that proper responses to the following questions will result in new and improved employment for you. But if you can’t answer them, you should scrape off any adjectives on your resume that indicate you are more than a noob.

If you happen to be an HR person or manager doing the interview sans “those tech guys” the accuracy of the answers provided is less important than the clarity and confidence of replies.

In this order:

Verbally walk me through the construction of a simple Actuate report. I invite the candidate to alternately describe the creation of a recent report they worked on. The nuts and bolts answer is that they add a Report Section, a Connection, Datastream, DataRow, most likely a Group Section, a Frame and a few display controls. I want them to at least talk me through the three categories of Actuate components and how they contribute to the report: Data, Structure, and Display.

Anyone that has been working on Actuate for over a year ought have created enough reports to answer this without hesitation. If they can’t, then I don’t know what they have been doing with their time. Suprisingly, in the 15 or so people I have interviewed over the years, not one has given me a satisfactory answer. But, I don’t focus on the correctness or accuracy of the reply as much as the organization and confidence.

A good developer will be able to immediately describe something at this point. Whether it’s on target or not, they will not stumble around clearly making up information. The response could be long or short, but it will be well delivered. Most times even the best devolve into desacribing a single interesting part of a report they have built. THis is good in its own way, because it allows them to detail the construction of something they are proud of doing. If this does happen, listen to how the candidate responded to the challenges and how the resolved the problems.

I have heard numerous so-called experts ramble off on trails so bleak that it makes you wonder if they even know what Actuate does. Imagine driving for a year and not being able to name the parts of a car you use to go from your house to the mall.

Name a report component that you consider to be representative of a complex report. Again, no correct answer here. Though plenty you won’t want to hear because they indicate a low level of experience (frames, . What compent they pick and how they describe it as indicative of complexity will tell you where the lie on the spectrum of skill. I personally think that a Memory Data Sorter is the cutoff to the world of complex reports–it has been in my experience. But others might think that a Sequential Section or a Parallel Section is the cutoff. Another great one would probably be a Multiple Input Filter.

Just because a candidate doesn’t produce what you think of as a hallmark of complexity doesn’t mean they don’t have the skills you are looking for, nor does it mean they are neccessarily junior developers.

The trouble here is that Actuate reporting is so insular that a person could be an expert and never have used one of the above–I have never used a MIF for example. So, again the quality of the answer, the communication skills, are what you are after. Do they float around unable to name a component at all or do the immediately offer up a component by name and start explaining why?

What are the differences between an Actuate Group Section and a SQL Group By within a report? The answer to this is the only one that can be truly incorrect or correct. But this is not a trivia question designed to poke the interviewee in the eye. You can decide for yourself, but I believe that if a candidate has a deep understanding of reporting and Actuate reporting in particular they will be able to produce these correct answer.

An Actuate Group Section will group similar records together by a key field. A query pulling all the records from a table with 100 records and grouping by State or Province will still display 100 records on the report. No data is lost or aggregated.

By contrast, a SQL Group By will aggregate data being pulled from a table. Grouping By State or Province will result in somewhere less than 100 records being delivered to the report. The results most likely will be 5 records containing a count and the state name: Texas-20; Oklahoma-10; Maine-5, California-25, and Delaware-40. A Group By processes the data and creates new information about that original data.

When talking about Actuate Group Sections a good candidate will tell you that the Order By clause of the SQL is more directly related to Group Section controls.

Describe the relative contribution that SQL and Actuate make to the resulting report. This is a glimpse into my personal design patterns about as much as it is about the interview. Oh well. I personally believe and constantly say to my co-workers that Actuate is for making stuff look pretty.

When I develop a new report I start with the SQL first. Make sure the SQL does nearly everything I need from selecting data, to creating fields, to filtering records. I like to do it this way because it gives me one place to find the logic the customer wants.

If a candidate dismisses the contribution of SQL to the overall report then they don’t have the skills you are looking for to implement your solutions.

Written by Douglas

20061110 at 11:21 am

Posted in Actuate, Employment

YYYYMMDDHHMMSS.ZZZZZZ WTF?

with 3 comments

Somewhere along the way I created a report to compare the elapsed time from OPEN to CLOSED to a target number of hours. And it works (or no one complained).

I must not have done enough research, because I learned today that in DB2 TODAY minus YESTERDAY doesn’t equal 1 day, 24 hours, 1440 minutes, or even 86400 seconds.

It equals 1000000.000000

Huh?

The value returned when subtracting one date from the next looks like a number, feels like a number, acts like a number, but isn’t. Not really. Its a coded string. And the format is: YYYYMMDDHHMMSS.ZZZZZZ. It took several minutes of banging my head to come to grips with this silliness followed by more than a bit of screwing around to realize that the answer to my problem was to convert the static target values I comparing my results with to this format:

4 hours = 40000
48 hours = 2000000 (not 480000)
47 hours = 1230000

And that’s great for me for this report since my targets are static and I just hardcode them in to the SQL in the report. But what happens when I need to display the returned ‘numeric’ value as a pleasant (pleasant = appealing to customer) looking duration?

From 3/30/2006 8:59:23 AM to 4/6/2006 3:26:32 PM returns 7062709.000000 (not pleasant)

7 days, 6 hours, 27 minutes, and 9 seconds (pleasant)

You and I can do that our heads, but in a report we’d have to distill that logic into a complex parsing code in order to get that pleasant result. Sure, that just a little more code maybe a handy function, but come on, why isn’t pleasant the default?

Further, what if the customer wanted this in just hours or minutes? Not only would I have to parse the returned ‘numeric’ value as if it were a string, but I would have to come up with all the multiplication too. Don’t even ask me to think about how to deal with the fact that there aren’t a consistent number of days in a month.

I have to assume that sharper folks than I are building enterprise class databases and that they decided that this was best for us all. Anyone know why?

Consider yourselves warned.

Tags: , , ,

Written by Douglas

20061025 at 12:21 pm

Posted in SQL

Two Controls in Two Minutes in 200 Inches

leave a comment »

If you hadn’t already noticed, you’ll start figuring out that my head has been in the SQL of late and not in the Actuate. As I tell my co-workers, Actuate is just around to make the database look pretty for the suits.

I don’t think I had ever cared to notice, but the display width limitation of Actuate is 200 inches. Meaning you can’t make a frame wider than that. Half of you just wondered why you’d ever want to and the other half just wondered why there is a limit at all since what’s another few inches on the web. My replies: a report developer would never want to, but the afore mentioned suits want things we can rarely imagine; pretty sure 200 isn’t the limit if there is one.

This fun report of mine has 150 controls and 150 labels.

Since the sizing of reports falls to me alot of the time, I was wondering how long it would take me to create a label/control pair in the open field. I was able to create 24 pairs in 48 minutes. So 1 control / minute.

Can anyone recommend a good wrist brace?

Written by Douglas

20061023 at 18:52 pm

Posted in Actuate, Best Practices