Awhile back, I ran into a client who had three environments co-located. It was a classic “all eggs in one basket” scenario – but in this case they had all the virtual machines in one server.
The three environments served development, testing, and production, respectively. Their names were Maximo in all three cases. But, the last character of the port number varied between zero, one and two.
At this customer’s site, a typical server name has nine to 12 characters, four characters for the port, and five or six for the application name. So, out of those 18-22 characters, just one character made the distinction between their development, testing, and production environments.
Put yourself in the shoes of a user who has less configuration knowledge; they just use what you point them to. It’s hard to figure out where you are or where you’re going to when one seemingly random character makes all the difference! Needless to say, all too often, I’d received phone calls with people asking, “Where’s my newly submitted work order?” only to realize the user was trying to find a new work order in the development environment, which had two-month old data.
To clear up the confusion, they wanted a simple way to individualize the content of the URL without jumping through hoops.
Let’s start with a simple explanation of URLs:
A universal resource locator (URL) is made up of several components:
The context is the web shared location on the server where the web files are located. In the case of this Maximo implementation, the URLs looked like this:
As you can see, the context is always “Maximo”.
Sometimes, it’s desirable to change the context of the application to something end users are more likely to recognize. For example, systems that have multiple instances of an application on the same server – like development, testing, and production. It may be helpful to name the contexts “maxdev”, “maxtest”, and “maxprod”.
What this customer wanted was to have URLs that looked like this:
They wanted to perform this with as little disruption and the shortest amount of downtime possible. So, by following the steps below, we achieved that goal.
The context is configured in the “deployment-application.xml” file of the Maximo application.
In a “standard” deployment, you can find the XML file in the following path:
To change the context, first locate the web tags section as shown below:
Then, change the word “maximo” to the new_context required for your application.
Save the file, rebuild the EAR file and re-deploy the application.
The new URL will be “protocol//servername:port/new_context”.
We succeeded in individualizing the client's URLs. Now, their users can clearly see “where” they’re going – no more looking for new WOs in the development environment, and no more phone calls (on this issue) for me!
Elliot Bonilla's expertise extends to over 12 years in system analysis, product development, and engineering roles. Elliot draws from his considerable experience in various sectors like Pharma, DOD, DOE, NASA, and Enterprise projects to ensure customer success.
His extensive knowledge of IBM Maximo CMMS allows our customers to leverage the vast features of Prometheus Routine Maintenance. Working alongside the Sales, Client Services, and Development teams, Elliot ensures that every implementation, upgrade, and support call is handled with care and due diligence.
Originally from Puerto Rico, Elliot now lives in Florida. In his spare time, he enjoys working on Maker/DIY projects and spending time with his family.