Category Archives: Maximo

How to embed .js files into BIRT report for Maximo

One of the most unique features of BIRT is its ability to use other programming languages to do complex tasks within the report file. Take a look at the forums on and you will see examples of people using PHP, java, javascript and more. This post will show how you can embed a javascript file (.js) into a Maximo BIRT report to do complex tasks.

One of the common tasks a report writer will get asked to do is make sure the report looks good. The goal is to have the information laid out cleanly so the end user will clearly see the information. A typical request is to transform a text string’s case, say from upper case to lower. That’s easy to do in BIRT, just apply a string transform on a dynamic text field like this:


Now the beauty of BIRT means it can also use the javascript method to apply a lower case string transform too. Like this:


So another common request is to change a text string from upper or lower case to proper case (UPPER CASE –> Proper Case). Easy, just use a dynamic text field and apply a string transform again.


Guess what? BIRT doesn’t have a proper case text transform function. Using the string transform above will cause the report to error out and not show any information in that data row. A new string transform function, in an external javascript file, will need to be created to do the text transformation requested.

You’ll find plenty of examples searching the web on ‘javascript change string to proper case‘ for a javascript example to do a proper case text string transformation. The code that I’ll use was provided by Tuan on

String.prototype.toProperCase = function () {
return this.replace(/\w\S*/g, function(txt){return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();});

Copy/paste the javascript into a text file and save it as ‘toProperCase.js’ in the Library folder of the BIRT Report Designer application. The path should similar to this:


Now open the report file that will use the javascript file in BIRT Report Designer. On the Outline tab, click on the report file name. This will bring up the general properties of the report design file.


The 6th tab under the ‘Property Editor’ tab lists ‘Resources’, click on this to open where the .js file is associated. 


Notice there is an option to add/include a JAR or javascript file. Click the ‘Add’ button for the javascript file and the ‘toProperCase.js’ file will be listed as an option. If it’s not listed, double check where the .js file was copied to from the steps above. Once attached, save your report file to update the file.

To apply the text string transformation function, just append the text transform to any value in a dynamic text field with .toProperCase(). For example:


An example of the text transform is shown below. Text in black has been left unchanged, while the text in blue has been applied the .toProperCase text transform.

The next step is to get the .js file to work with the BIRT report inside Maximo. First the .js file has to be compressed into a zip file. This zipped file will be added as part of the import process into Maximo.

Next, log into Maximo and create the report object (skip this step if you’re going to re-import an existing report). Save the new report object and then click on Select Action –> Import Report. When you import the rptdesign file, you will also import the zipped .js flle as a resource file:

Now click ‘Ok’ and generate the Request Page.

Run the report in Maximo and the extended javascript text transformation function will work on the report from inside Maximo too.


Good luck and have fun with this new option for your Maximo BIRT reports.


Quick Tip – Date formatting in Maximo BIRT

Moving from other reporting packages to BIRT, you will always find that one feature you had in your previous reporting tool that you can’t find right away in BIRT. As I’ve continued to adopt more of my company’s internal reports to BIRT, I found date formatting is something that can be a little frustrating. Our previous reporting tool could easily convert a Date/Time field to a short date of xx/xx/xx. For example, today’s date would be formatted as:

2012-05-03 15:35:17.342 = 5/3/12

This is the standard format we use for date fields in our company’s reports. However, BIRT doesn’t recognize years as a 2 digit number, it sees years as a 4 digit number. So when showing date/time fields in BIRT, as a short date, BIRT would default the conversion to:

2012-05-03 15:35:17.342 = 5/3/2012

So how do you get BIRT to show the short date format we’re used to? By concatenating parts of the date field and converting the year value to a two character string. The following code is entered as a Dynamic Text field in lieu of a Data field:

BirtDateTime.month(row["datetimefield"]) + "/" +["datetimefield"]) + "/" +
BirtStr.right((BirtDateTime.year(row["datetimefield"])).toString(), 2)

So what happens is the following:

  1. BirtDateTime.month(row["datetimefield"]) will give the numeric value of month.
  2. + ‘/’ will add the ‘/’ separator to the text string. The ‘+’ ties the two text fields together so they string together.
  3.["datetimefield"]) will give the numeric value of the day.
  4. + ‘/’ will be the other separator.
  5. BirtStr.right((BirtDateTime.year(row["datetimefield"])).toString(), 2) does three steps in one statement;
    1. The inner function BirtDateTime.year(row["datetimefield"]) works like the previous functions and returns a 4 digit year value.
    2. The string modifier .toString() converts the 4 digit Date value to a 4 character string.
    3. The outside Birt function BirtStr.right( ), 2) trims the 4 character year string to just the right 2 characters.

So now we can format any Date/Time field to a short date format of 5/3/12.

When should a new work order be needed?

A common struggle for maturing maintenance organizations is determining when a new work order should be created. Previously the organization may have only consistently created work orders for preventative or predictive activities. Any follow-up, or corrective, from the preventative work may go unrecorded. So when it’s decided that no data is worse than bad data, a standard is setup to determine when a new work order should be created.

So what’s a good line in the sand? Any job that requires parts? Any job that takes more than 15 minutes of mechanic time? 30 min? An hour? Let’s settle on that a new work order is required for any job that requires parts or takes more than 15 minutes to complete. So if a job takes less than 15 min to get done, and doesn’t require a work order, how do you enforce the exception? How do you enforce this exception from drifting to 20 minutes or 30 minutes of undocumented time? The problem with an exception like this is it contains a fatal flaw that most organizations don’t want to accept.

If you have an exception to a rule that can’t be measured, you don’t know how many times the rule will be broken.

The reason why an organization may setup an exception like this is so they aren’t "burdened with recording all the little things they have to get done each day". This is just a remnant from the reactive culture the organization has lived in for so many years. We’ve already seen the first problem with this type of exception is that it can’t be measured. The inability to measure when a work order wasn’t needed then waterfalls to break most metrics a company would want to use to measure their maintenance department with. For example:

  • Labor utilization (not all time is entered, so utilization is inaccurate)
  • PM to non-PM work ratios (don’t have all the non-PM work recorded)
  • Monthly work breakdown by type (not all non-PM was recorded)
  • Mean time between failure (not all work is documented)
  • Mean time between repairs (not all work is documented)

On top of misreporting metrics, there is also an underlying issue of mechanic supervision. If a mechanic isn’t doing the work they were directed to do, because they just spent 15 minutes doing something else, what happens to the work they were directed to do? Or worse, how often is a mechanic now doing "a quick 15 minute job" for another department that was a lower priority than the work that was scheduled to get done? The golden rule for when a work order is required should be:

If the work a mechanic is doing isn’t on the work order in their hand, then a new work order is needed.

Anything less than that puts an organization’s metrics and record keeping into jeopardy because the exception cannot be measured. Don’t agree? Submit your comments below.

First things first for Maximo KPI’s & Metrics

After getting maintenance activities completed in the plant and documented in Maximo, most organizations want to understand what they’ve got done. Going beyond summary reports – number of work orders closed, dollars spent per month, etc., most organizations look to key performance indicators (KPI’s) and metrics to help them understand what is happening in their plant or facility. Getting measurements on activities related to Maintenance can be daunting task. Do a Google search on ‘maintenance KPI and metrics‘ and you’re likely to have a melt down on all the information that is available. Like most organizations, you’re likely to want to report on the big name metrics like OEE, MTTR, and MTBF.  Before an organization tackles one of these metrics, they should make sure they can report on more fundamental metrics. The idea is similar to the old saying, ‘walk before you run’, so here are some steps on getting started.

First, take a look at some fundamental metrics to see if you have consistent data reporting occurring in Maximo. If you don’t have good data, you won’t have good measurements to rely on. Three common metrics an organization could use are:

  1. Monthly work type by hours: This metric looks at all the work orders an organization completed in a month, grouped by work order type, then summarizing the documented time spent on each work order. This metric helps understand what type of work got completed and which type was done most often. To get a complete picture of this metric, an organization would need to see if the following is occurring:
    • Do we require all work orders to have a work type?
    • Do we have work types to properly describe the work being done?
    • Do we capture all activities on a work order or only some of them?
    • Do we capture time on all work orders?
  2. Manpower utilization: This metric looks at how much of a manpower’s available time was documented on a work order, over a given period of time. This metric helps an organization understand how well manpower is being scheduled or if there are gaps in documentation. Some questions that could be raised around this metric are:
    • Do we have accurate schedules of manpower in Maximo?
    • Are we capturing all the activities being done in the plant in Maximo?
    • Do we have inaccurate recording of manpower time (e.g. man hours are documented for a mechanic on a day they weren’t scheduled)
  3. Work orders closed with costs & zero man hours: This metric is used to see if work orders are getting closed with charged parts or materials, but no manpower time was documented with the work. Depending on the volume of work orders closed, some questions that may get raised are:
    • At what point in the closure process are we allowing an informational gap to occur that allows a work order to be closed with parts or materials charged, but no man hours.
    • Are there known exceptions we should exclude from the metric?
    • Are there steps we could enforce the rule (e.g. conditional security to not allow work order closure when costs exist)?

Some good sources on examples of maintenance related KPI’s and metrics to use:

Over the next couple of posts, we’ll take a look developing these into either a dashboard KPI for the Maximo start center or reporting metrics from a BIRT report, so the information can be run understood straight from Maximo.

Got some other topic you’d like to see covered in the future, email me or send me a tweet @MyGeekDaddy.

Maintenance , Maximo & MyGeekDaddy

Talk to anyone familiar with IBM Maximo and ask them about the top four or five related topics they’d associate with the application. Go on, try it yourself. I’m betting the common answers would probably be asset management, CMMS, EAM, work orders, planning, scheduling, inventory, reporting, or purchasing. Just about anything related to what you "do" in Maximo. Me? I think of Twitter, Facebook, and blogs. (pssst…. kind of like this one)

Huh? How does knowing what someone ate for lunch or funny pictures of their pet have to do with better facility or asset management? Probably not a lot, but bear with me for a minute. Think about how much knowledge you’ve learned mastering your areas of focus in Maximo. Now think about the volume of information related to maintenance best practices and how you could apply those techniques to your maintenance organization. Wow, now we’re talking about an enormous amount of information. Wouldn’t it be great if there was a way to find someone who has gone through that same mountain of information? There is and for me it’s social media.

The idea of using social media with Maximo is about being able to easily reach out to others and share information around a common topic. The problems you and your company are facing are probably very similar to ones that other Maximo users have faced. Things like:

  • How do I get this escalation to work the way I want?
  • Is there a better way for me to create my BIRT reports?
  • How could I do a better job organizing my security groups?
  • Is PAS55 something we should be looking into?

Some of you may have recently attended IBM Pulse and came away with some great new contacts to speak to about Maximo. What if you didn’t attend? Are you just out of luck? Nope. That’s where social media, especially Twitter, can come into play. Social media isn’t just about pushing information out, but a way to find information and pull it back in. Take a half an hour doing a search on twitter for things like "IBM Maximo", "BIRT", or "Asset Management". You’ll be amazed at the new contacts you may find.