Technical Blog Post
Maximo Anywhere Push Notifications: A Cautionary (but Successful) Tale.
Not so long ago, I agreed to start working in support for Maximo Anywhere
As part of my education (and prompted by a PMR), I decided to experiment with Push Notifications using Maximo Anywhere 22.214.171.124 and an Android device.
@Shane Howard270000C70V has posted some excellent blogs (Configuring Push Notifications for Maximo Anywhere 7.6.1 and Maximo Anywhere 7.6.1 Push Notifications - Obtaining the GCM SenderID and API Key) on the subject, so I should just be able to quickly walk through these and then impress my teenage daughter by making a tablet bleep. Not much else impresses this generation, so there was plenty of motivation.
Luckily I practised in private.
I followed the steps very carefully (honest!) and found that much of the configuration was already in place in my out-of-the-box 126.96.36.199 system.
Easy as 3.1415.....
(Seriously there is actually very little work involved)
I created a workorder of type EM and made wilson the owner (to trigger the sample notification).
The end result: I could see the notification in the Work Execution app on the device (using the Notifications view), but not a bleep. Silence. Nothing in the Status Bar. No notification has reached the device.
Hmm. Not feeling quite so smug now (and grateful that my daughter wasn't watching).
How to investigate?
I could see the notification in the app, so the database updates in Maximo are happening and the notification process is being triggered. That's a good start.
Fingers crossed that there would be something in the logs.
But which logs?
Well, the notification starts in Maximo and then travels to MobileFirst before going elsewhere.
Let's follow that path and see where it takes us.
We need to check the Maximo and MobileFirst logs and hope that the notification is recorded in the logs and that any error would result in a message.
Start with Maximo
Maximo SystemOut.log contained this
[02/03/18 11:04:55:922 GMT] 00000aaf SystemOut O 02 Mar 2018 11:04:55:922 [INFO] [MAXIMO]  got notification message from queue jms/maximo/int/queues/notf
[02/03/18 11:04:55:927 GMT] 00002f60 SystemOut O 02 Mar 2018 11:04:55:927 [INFO] [MAXIMO] [CID-UIASYNC-1059] Correlated data: BEGIN UISessionId:1 AppName:wotrack UserId:maxadmin UIClientIP:127.0.0.1 ElapsedTime:106 ms END
[02/03/18 11:04:56:032 GMT] 00000aaf SystemOut O 02 Mar 2018 11:04:56:032 [INFO] [MAXIMO]  HTTP Response from External System is sucessessful.Response Code :200. Response Message:OK
So we're off to a good start here.
1) We're hitting jms
2) We're getting an HTTP response code 200 and the message OK , so we have successfully sent a message somewhere.
All is good on the Maximo side
Next stop MobileFirst
Now things get interesting
Nothing in SystemOut.log (or any other log). Zip. Nada. Not a sausage.
What do we know?
Everything is good in Maximo, the notification message is being sent to MobileFirst, which responds OK and then nothing is written in the log.
Is this normal? Is MobileFirst working properly? Maybe there's something not right with MobileFirst despite the 200 response?
I restarted MobileFirst and tried again. Seemed like a good idea at the time,
Still no bleep.
Everything looks good, No error messages. But IT'S NOT WORKING.
This is my first time and I don't know what error I would see in Maximo if MobileFirst isn't reachable, so I stopped MobileFirst, left it down and tested again.
I checked the Maximo log
I still saw the 200 response code.
I checked everything carefully, didn't I?
So where is the response coming from? The address and port in the endpoint is correct. It defaulted to the correct values if I remember correctly.
Now there's something I haven't mentioned. A minor detail that is so normal in my environment that it never crossed my mind.
This is a test environment, so the development server was running.
The development server doesn't support notifications, so it can't be relevant, can it?
Out of a mixture of frustration and desperation and to eliminate it from my enquiries, I stopped the development server as well as the MobileFirst server and tested again.
Now things got useful.
In Maximo SystemOut.log I saw this:
[19/04/18 18:15:37:953 BST] 000018f0 SystemOut O 19 Apr 2018 18:15:37:953 [INFO] [MAXIMO]  got notification message from queue jms/maximo/int/queues/notf
[19/04/18 18:15:39:001 BST] 000018f0 SystemOut O 19 Apr 2018 18:15:38:999 [ERROR] [MAXIMO]  BMXAA1477E - The connection failed to the HTTP handler for the endpoint. Review the error and server log flies for information to indicate the cause of the issue, for example, incorrect properties in the DefaultHTTPExit.java handler class.
Connection refused: connect
psdi.util.MXSystemException: BMXAA1477E - The connection failed to the HTTP handler for the endpoint. Review the error and server log flies for information to indicate the cause of the issue, for example, incorrect properties in the DefaultHTTPExit.java handler class.
Connection refused: connect
So shutting down the development server triggers an error message.
But the host:port in the endpoint are correct.
Time to stop trusting my memory and face some facts.
There are no messages in MobileFirst to indicate that the notifictaion is being processed
Something is giving a positive response to the notification message sent by Maximo
If I shut down the MobileFirst server, something still gives a positive response to Maximo, but this can't be the MobileFirst Server.
if I shut down the Development Server, I now get an error
Despite my confidence that the endpoint is correct, I must be mistaken.
Sure enough, I had the port number in the url for the AW_WE_EM endpoint wrong (I have everything running on a single box, so I had just glanced at the hostname and not paid enough attention to the port)
Fixing up the port number solved the problem.
Message in the MobileFirst SystemOut.log
Notification received on the Android device status bar. Bleep. Touch the notification and I get taken to the Work Execution app and a pop-up where I can choose whether or not to open the work order..
Smiles all round. Happy times,
The moral of this tale
We all make silly mistakes, but (in this case at least), troubleshooting methodically found the answer.
PS: My daughter still wasn't impressed