My failed attempt to get Maximo to work with Azure SQL database

Recently, I started playing with Azure by attempting to migrate a Maximo instance from my local VM to Azure platform. Although the attempt was a success. I didn’t realize SQL Server and Azure SQL are different databases (or more correctly, two different versions). There were a few issues during the process, but I figured out how to work around them and got Maximo running on Azure VM and Azure SQL. After sharing the result on LinkedIn, there were some comments that Maximo couldn’t be installed on Azure SQL and IBM doesn’t support it, so I spent a bit more time digging and thought I should share the details and some of my opinions on this matter.

First, let us be clear, Azure is a big cloud platform which offers many different services. I’m not a cloud expert, but from what I understand, we are talking about two main services:

Framework Manager crashes when creating Project

I tried to create a new Framework Manager project to build a package which I will join some big Maximo tables (Assets, Workorder etc.) with some general geo/demographical data I pulled from the Web. Framework Manager kept crashing with this annoying error. After some quick search on the web, I realized the issue with FM crashing is not uncommon, and there can be a thousand reasons for that. To be honest, from the perspective of a software developer, most of these are simple and stupid exceptions which should be caught or fixed easily by the Cognos R&D team. Good software should give the end-users useful error messages about what they did wrong. But anyway, this is not another post to complain, just a quick note on another crash scenario so you can avoid:

Display password stored in System Properties

I had to look at an existing interface in production which sends data to an external system. The interface is working well but we don’t have any documentation. I like to use POSTMAN to send some test requests to figure out how the API works. Unfortunately, the API password is kept in a System Properties and is masked and encrypted.

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: