Wednesday, April 12, 2017



Passing Parameters to a Scripted DataSet;or any DataSet for that matter


The first time I heard the phrase "parameter binding to a data set" cold chills shot down my spine. I was thrust right back into my first OO Programming Class, where concepts like "pointers", "polymorphism" and others were thrown around like we were all just born to understand these abstract descriptions. Why not call it something simpler... like Parameter "place-holder" or "access point" ? Using the word "parameter binding" just makes it sound more complicated than it has to be. ...Maybe that's the idea? We are talking about nerdy techie types after all.


That said, I will try to make sure I don't needlessly try to impress with my cryptic verbage. So, here it goes. If you are both new to BIRT and have to use a scripted source the way IBM’s Maximo implementations do, you might not know where to begin right off the bat. I will break it down into smaller pieces, so that it is easier to follow and less complicated.

Start with a report that is easy for you to understand from a conceptual perspective if nothing else. In this case person_details.rptdesign should do just fine. What you see here is the 7.5 Maximo Server. In the spirit of keeping it easy, the report chosen has a single user prompt, PersonID.


The purpose of the report is to display all Assets, Contracts, Tickets or Work Orders that the selected person is assigned to. This is shown by utilizing multiple sub-tables within the primary summary table listing information coming from the Maximo person table. Looking at the report layout perspective you see each sub-table maps to a DataSet.

The first thing you do is add the Parameter, this can be done under the Data Explorer or Outline view (I find it easier to do it in the Outline). Here is where you define the parameter prompt for the user as well as consider the type of data you are expecting to work with in the dataset. This parameter was defined as a String value that will be provided via a Text Box.






Once you have a parameter you have increased the usability and functionality of the report significantly. But the most effective, or rather most efficient one is utilized in this report, it is applied at each DataSet level. Let’s take a look at a portion of the open event of the first DataSet, assetdetail:


You can see where BIRT is going to replace the ? with the provided Person ID in the where clause. But it can be used against multiple fields. For example, here is the workorders DataSet open, in this DataSet it will compare against 3 fields; the owner of the workorder, who it was reported by or on behalf of:




The best way to tackle handling anything new, and in particular anything new with BIRT or even troubleshooting complicated reports or queries is to break the system down into simpler and simpler terms until you begin with something which is easy for you to understand. This report is a good example of creating a highly functional report using small manageable pieces. Using a default parameter values you not only makes unit testing quicker for you, you also have the ability to run each DataSet individually to troubleshoot any potential scripting issues.


Like I often mention to my clients, and any of my BIRT classes, if you are confused by the BIRT report development process, you are not breaking it down into it's three simple parts....
  1. Data 
  2. Layout 
  3. Formatting & Features 


If you would like to take a class from us, or would like to get some help with your BIRT Project(s), please visit our Website or give us a call (888)234-DATA.

Wednesday, March 1, 2017

Business Intelligence Implementation & Project Help...over here.

The Better Pathway to a Successful Business Intelligence Implementation.

Like Raw Chicken, Raw Data is NOT usually good for you:

More and more companies are jumping on the Big Data, Data Analytics, Data Mining, Data Science, Data-Driven bandwagon(s). Nothing like stating the obvious, but I made reference to the first five "Data" buzzwords I hear throughout the course of any given day. Why only five? After all, there are plenty more "Data" buzzwords out there... and lets not forget "Analytics"!   

The point is, that it's no secret that businesses recognize what they need to stay in business; Data! Actually it is my belief that data in an unto itself is not inherently good. Consuming raw data, much like consuming raw chicken is not all that good for you. In fact trying to consume it raw is likely to produce sick behavior at best and could lead to the death of your business. 

Business Intelligence is a mind-set:

As companies go, I have consulted the whole spectrum; small start-ups to fortune 100 multi-national well established firms. I've even been exposed to a wide variety of market segments, from the tech-sector to federal to manufactured goods. So, it is fair for me to say I have seen almost every permutation of Business Intelligence implementation. So, here are a few overall sentiments I've encountered. 
  1. Data users believe if you "just show them all the data, they'll sort it out..." 
  2. Business data, is either not reliable, not timely, or both. 
  3. Business Intelligence tools and applications are complicated and very difficult to use. 
  4. IT and in particular DBA's are very protective of their data stores. 
  5. It takes too much time! 
Just like any worthwhile endeavor, implementing and using a business intelligence solution takes dedication, hard work, time, and even maybe a little pain or sacrifice. Being open to new ideas, trusting your team, and a little focus will go a long way toward a successful implementation. By no means should you take shortcuts. There is no magic wand. 

Choose the right tool, and you'll achieve the maximum benefit:

I'm not sure how many times I've heard the question "can we get it in Excel?"... But it does confirm a statistic I've recently heard; "...1 in 5 businesses are using spreadsheets as the main tool to communicate data internally."[forbes] With all the inexpensive and even free Business Intelligence tools out there, why jump straight to Excel? It is my opinion that the answer is, "because it is familiar". 

If you have ever wondered "...what happened to that spreadsheet with all those formulas" or "who changed the columns!?!!?? now my look-ups don't work" or "...that data doesn't look right..." you'll get a kick out of the Forbes article I've linked to in the previous paragraph. The bottom line is that for as popular, familiar, and easy as Excel is, it is NOT always easy, it is NOT always popular, and it is NOT always the fastest way to communicate your data. 

Choosing Excel, just because you don't know anything else, or because you feel like it is the quickest solution to your BI and Data problem is almost always neither. In the long-run, just like crash diets, it will likely make you fatter, or in the case of data give you a bigger headache! 

Choose your Business Intelligence partner wisely:

More money is wasted on failed Business Intelligence efforts than I care to admit. Most of the time the wasted money comes from a handful of reasons. One is that the company or sponsor of the project doesn't know exactly what they've signed on for and jumps at the first thing through the door. Another reason is that internal politics and protectionist attitudes in the Information Technology group, hinders true and efficient implementations. Sometimes it is because resources are more focused or familiar with IT projects than they are BI projects. 

Ultimately it comes down to who you engage with, and why. To find a true Business Intelligence partner, you'll need to choose them for just as much their ability and experience in BI implementations, as well as for their ability to align with and identify with you and your business. Business Intelligence implementations are more about the BUSINESS than the TECHNOLOGY. 

UniVant Corporation

We at UniVant Corporation strive to do one thing for you. We strive to help you achieve a unified vantage point into your companies data. No matter the source of the data, be it inside your own systems, in the cloud, or maybe you simply want to leverage social media, we can help you. You can find out more about us here: UniVant.


Friday, March 28, 2014

How to create a Histogram with BIRT

You'll find my example and post on the Actuate Developer Forum.

Friday, October 18, 2013

Working while traveling

Working while traveling?  
So, I've been referring to myself as a sort of Digital Gypsy for a few years now. Until this past year, this was not a completely accurate statement. I had a condo, home base, paid property taxes; what ever would constitute as "normal everyday American" typical living. Enter, moving onto the sailboat and just leaving the rented condo behind for someone else to worry about, and taking off!

So how do you maintain enough stability, without loosing freedom?
To maintain a place to receive paychecks, paper correspondence, and simply ensure that you have the things necessary to provide a prospective client that you're not a vagabond, get a mail service. We use St. Brendan's Isle mail service (http://sbimailservice.com) another service if you'd like to comparison shop, is Mail Forwarding Services in Oregon (http://www.mailforwardingservices.com).

Having these services even if you have a permanent home address is wonderful for anyone who would like to have their mail received and scanned, then review the envelopes on line. This way you don't need to wait until Saturday to unload an overstuffed mailbox; I'm sure your postal carrier would appreciate that. With scanning services, you also have the benefit of letting the mail service send or shred based on what you see.



Friday, March 25, 2011

POC & Implementation

Never Confuse Selling with Implementing
I just heard these words said for the second time in as many weeks.I've recently been involved in my first sales / POC engagement, and it was an eye opener. I think we all have some responsibility to "sell" our product, skills, ideas, etc... No matter if we're the technical help, or the sales professionals. The issue as I've seen it comes in when a techical person is asked to perform in a sales capacity.

Sales by nature, doesn't seem to focus on the technical aspect of anything outside the "FAB" talk. "FAB" "Features, Advantage, and Benefit" are usually decided upon by marketing and the talking points are well established. This is why it is probably a little easier to "Sell" an idea or product this way. As a technical resource, the only selling and marketing information we are privy too or care to study are the standard set of specs. Then we're off to try and figure the "thing" out, by applying our knowledge to the product, kicking the tires so to speak.

As a technical focused professional, we are responsible for ensuring good practices are followed and that the product we put out can be maintained. It's sort of like a craftsmanship issue. You wouldn't want to be known for shoddy work as a carpenter, you'd never get to build and admire sturdy houses. Likewise being known for shoddy software work, will not afford you the opportunity for long-haul development.

The trick is to balance the Sale with the Implementation. Sales gets you in the door, good implementation keeps you there, and eventually provides you an opportunity to do it again and again...

Tuesday, February 8, 2011

Who's to blame?

So you've been on a project for three weeks, and it becomes apparent that things are not going well. What should you do? As an implementation specialist, developer, or integrator do you have any more responsibility than to "just do your job"? Though some if not most projects are full of political motives and egos. Trying to point out flaws is almost never met with a welcoming attitude.

You have perhaps a very few set of options, but options none the less; so, what are you to do?

Plug along, and let the project manager blame you for being slow or ill prepared. This option does nothing for anyone involved, you look bad, your project manager is stressed, and the client is loosing faith all the way around.

Point a finger, and highlight the flaws in the plan. This option will surely make your project manager defensive at best and down-right hostile at worst. In either case the client might get what they want, but depending on how highlight the flaws you might alienate your PM.

The best option perhaps is to evaluate the entire SOW and Project Plan early in the project, if not before. Using your past experience, make very certain that every single red-flag is noted and discussed to your satisfaction. Identify the concern (number it if you must) and write up a description of the potentially concerning outcome, and identify mitigation.

With good communication on the outset and ongoing and frequent (appropriate) communication will be key to successful project outcome. Have daily status contact with your PM so that there are no surprises and that the numbered concerns are brought to the surface.