Mess around with Azure: Migrate Maximo to Cloud

Last week, while attending a call to discuss an integration interface between Maximo and an Azure SQL database, the other consultant mentioned a few Azure terms like “blob storage”; I realized I didn’t know anything about Azure despite the fact that the cloud platform has been adopted by the large number of the clients I work with. So today, I decided I should play around a bit with it by trying to migrate a Maximo instance from my local VM to Azure.

Before I go into the technical details, for those of you non-technical readers, I like to sum up the whole experience I had with this platform in one word: magical. That’s it, I went to the website, signed up for a trial account, followed some wizards or clicked on a few buttons or menus that I think were features I need, and boom, I got a running Maximo instance on the cloud in just a few hours. No training, no muss, no fuss, everything just works. Not much else to say. I’m in love now. I think will spend the next couple of weeks, months or even years to learn more about Microsoft stuff.

Convert Australian GDA94 Easting/Northing values to Latitude/Longitude in SQL Server

As I play around with the Cognos Analytics map controls, it appears to me it only understands Latitude/Longitude values, but the sample dataset I have is in UTM format. So, I have to find ways to convert Easting/Northing values to Lat/Long. Since I use SQL Server, attempting to create a column in "Geometry" data type from Easting/Northing value, then convert it to a "Geography" data type (Lat/Long) does not seem to work for me.

After some scrambling on the web, the below SQL Functions seem to work for me to convert Easting/Northing values (on the Australian GDA94, Zone 56 standard). The key to get it to work is setting the correct datum details in the constant section. A quick test of this function does seem to give me the correct Lat/Long coordinates of Sydney Habour Bridge:

A sample point from latlong.net

My top 3 beginner gotchas with Cognos 11

Working with Maximo, perhaps we all have the same frustration with the constant changes by IBM marketing team who work hard and are very successfully in their attempt to confuse us. The most visible problem is the continuous changes to their website which essentially breaks any links from external sources pointing to their KB pages which are more than a few years old. When I started with Cognos, I realized they have brought it (the confusion part) to the next level with this product. Below are the top 3 gotchas that I had to learn the hard way when I started with this product:

Gotcha #1: Cognos Business Intelligence vs Cognos Analytics

From Version 11, IBM started calling it Cognos Analytics. Previous versions were called Cognos Business Intelligence. This does not seem like a big problem when scratching the surface. But as a beginner, I was totally lost when searching for technical information from the web. Initially, when I read something that mentions Cognos BI or Cognos Analytics, to me it meant the same thing “Cognos”. In many cases, I didn’t realize, when talking about changing behaviors or different functionalities, if people mentioned something is available in Cognos Analytics or something is not possible in Cognos BI, they were talking about different versions. I learned this the hard way and thought how much trouble it could have saved me if I knew about this sooner.

BMXAA4017E Error when running custom code

I went in to help this client fixing a few issues in Maximo. There were some pieces of buggy Java code, so I took the opportunities to remove those Java customization and rewrite them with autoscript. One piece of code worked well in DEV but when rolled out to PROD, it did not seem to work. It is triggered by user’s Save event, but executed at "post commit", thus does not give any error on UI. In the log file, it shows error BMXAA4017E “object cannot be saved with the data that was provided” from the mbo.checkQualifiedRestriction method: