Author: Pranjal

While working on some code, I found myself wondering how to quickly check if things were running smoothly under the hood—if there were any database connection leaks or if the code was using too much memory. Rather than digging through the logs, I decided to use the Maximo Management Interface (MMI) APIs. I used postman to call the MMI APIs but it was very cumbersome to individually call each API endpoint so I built a lightweight dashboard to show key JVM metrics from the MMI APIs.

This dashboard is strictly for use in a development environment and is not meant for production. It works only with the “all” server bundle and displays data from five MMI endpoints: threads, thread pool, memory, database connections, and user sessions. The stats auto refreshes every 2 minutes.

You’ll need a Maximo Manage API key to make it work. The API key must be embedded directly in the HTML, and you’ll also need to update the endpoints variable in the dashboard HTML to point to your Maximo Manage environment’s URL.

The dashboard can be run directly from your desktop or hosted on a web server. If you’re running it locally, set the mxe.oslc.aclalloworigin property in Maximo Manage to *. If it’s hosted, make sure the web server’s domain is added to that same property to avoid CORS issues. Also, include apikey to the existing list of headers in the mxe.oslc.aclallowheaders system property.

Its a quick and easy solution to monitor your development environment. You can add more MMI APIs or customize the UI as needed.

Check out the dashboard code here.

This is for an old version but helpful.

e.g. –

Unix: JAVA_HOME=/usr/local/java/jdk1.8.0_13

Windows: JAVA_HOME=C:\j2sdk1.8.2_14

Update the JAVA_HOME variable to point to the location where the JDK is installed. Restart WebSphere Application Server for the changes to take effect.

reference: https://community.microstrategy.com/s/article/KB16159-How-to-change-the-location-of-the-Java-JDK-JAVA-HOME?language=en_US

Have you ever come across a situation where your development environment WebSphere is on Linus/Unix and you don’t have access to the filesystem to hot deploy your class changes for testing? Well it’s pretty common if you are working for a big company which has lot of security policies in place. But what do you do? Do you go through all the pain of building the EAR and deploying it to WebSphere only to realize that there was a small piece of code that you missed and that you have to build and deploy all over again! Isn’t that really frustrating!

What I am going to tell you is not as quick a fix as doing a hot deployment, but it does save some deployment time. With this, you won’t need to build the EAR all over again, just have to do the deployment which takes half the time of a full EAR deployment.

This functionality in WebSphere lets you deploy delta changed to an application. All you have to do is 1 – select the application you want to deploy the changes to, 2 – select the path where the file has to be placed inside the application and 3 – select the file on the local filesystem which has to be uploaded and WebSphere will deploy that file for you.

Lets take an example – I want to deploy a class – abc.class in businessobjects.jar at the this path – com\pk\cron. Under the enterprise applications section in WebSphere, there is an option called Update which will let you upload/update this file in the businessobjects.jar. With this you can upload new files or update existing files.

Follow along with the screenshots, it pretty much self explanatory. Only thing you have to be careful about is the path inside the application EAR, that should be correct or WebSphere will place the file in wrong path. If you are not sure about the path, open the EAR, navigate through to the folder where you want to deploy the file and copy that path.

In this case the path is – businessobject.jar\com\pk\cron\abc.class

businessobjects.jar BEFORE uploading the file – 

businessobjects.jar AFTER uploading the file – 

Until next time!

How does IHS load balancing work?

IHS or the IBM HTTP Server is an apache HTTP server implementation with a topping of IBM configuration. IHS is not a part of WebSphere but you can install it separately and add it to WebSphere, that way you can manage it using the WebSphere console.

In addition to all the function of a webserver, IHS can also be used to as a load balancer which means you can use IHS to spread the traffic evenly across all your JVMs and in case a JVM crashes or is otherwise down, traffic won’t be routed to that JVM.

For IHS to do the load balancing it should have the understanding of the clusters, JVMs that are there in those clusters, virtual hosts, context roots, etc. and since IHS is not a part of WebSphere there needs to be a way for it to do that, this is where the plugin comes in. The plugin is basically an xml file that has details of the clusters and it members, virtual hosts associated to the applications on the clusters and a lot of other details. By default this file is updated every minute to keep the latest configurations updated.

The plugin has to be installed separately and should be linked to the IHS. If you use the launch pad to install the plugin, it takes care of associating the plugin to the IHS, if you are installing it manually you need to make sure you link it to the IHS.

That’s it for today!

Until next time!