In WebMethods, the most basic way to write a string “IN” operator is to use Branch as follows:
WebMethods: Evaluate String IN and CONTAINS operator
Troubleshoot integration issues when Maximo stops publishing data to external system.
I had to deal with this quite often. Most of the times, I got it right and able to identify the problem quickly. In a few cases, it took some time, and usually very stressful as it mostly occurs in Production. (It occurs in DEV and PRE-PROD all the time, it’s just that people usually don’t care, and it goes unnoticed)
Today I had to deal with it again and it took me some time. The cause was something I dealt with before, was told by a colleague on how to fix it (the easy way), but I forgot. This time around, under panic mode, I restarted a few JVMs before I remembered I should ask around and was reminded by my colleague again that it could be fixed with much less damage. I told myself I should write it down for the next time, so here is the sum of what I learned:
Setting up alarms for integration
When writing a piece of software, we are in total control of the quality of the product. With integration, many elements are not under our control. Network and firewall are usually managed by IT. With external systems, we usually don’t know how they work, or many times, not given access. Yet, any changes to these elements can cause our interfaces to fail.
For synchronous interfaces, the
user would receive instant feedback after each action is taken (e.g. Maximo
- GIS integration), thus, we don’t usually need to setup alarms. For
asynchronous interfaces, which usually run in the background, and don’t give instant
feedback, when failure occurs, it usually goes unnoticed. In many cases, we
only find out about failures after it has caused some major damage.
A good interface must provide adequate mechanism to handle failures, and in the case of async integration, proper alarms and reports should be setup so that failures are captured and handled proactively by IT and application administrators.
Avoiding recursion filter on Publish Channel
The standard way to send a message from Maximo to an external system is by setting up a Publish Channel and enabling Event Listener. By default, Integration Framework doesn’t re-publish a change if it comes from another inbound interface to prevent recursion on a bi-directional interface. Although I don’t agree with this logic as one-way integration is much more common, but anyway, IBM said it is easy to override that by extending the Event Filter javaclass.
The problem is, with the rise of automation script, no one wants java customization anymore. Of course, for massive systems where performance is critical, it is still the best choice. But, for
most medium-sized clients I work with, they’re all moving away from java
customization.
Anyway, an approach we can deal with this is not to use
Event Listener at all. Instead, we can trigger a publish from an Object Save
launch point from automation script using the example python code below:
from psdi.iface.mic import PublishChannelCachePublishChannelCache.getInstance().getPublishChannel("PUBLISH_CHANNEL_NAME>").publish(mbo, True)
Check Network/Firewall Status using PowerShell
$connection = New-Object System.Net.Sockets.TcpClient("google.com", 80)Write-Host $connection.Connected
If the server is accessible via the provided IP and port, the 2nd line will return the status = Connected
Common use cases for EAM mobile solutions
In some organisations, when starting a mobile project, the stakeholders may not have prior experience with mobility solutions for EAM, as such, we are sometimes asked to implement features that do not add value to the business. As consultants, it is satisfying to see something we implement being used and helps the end-users on the field. And nothing can be more frustrating than spending time building features that are not going to be used. In this post, I will list out based on my experience some commonly used and not used functions of a mobile app:
Work Execution: despite its name is Asset Management
software, 80% of activities in Maximo happen around the work management
process. It is not a surprise work execution is the number one use-case for a
mobile app. However, work management is a big process with several major stages
and many different activities. Only certain activities need to be recorded in
the field with a mobile device. Below are some common ones:
A case for EzMaxMobile
I spend a large portion of my time working with mobile solutions, but I haven’t talked much on this topic. In this post, I will give a bit of praise to EzMaxMobile.
Why should
you listen to me: I
know a bit about mobile solutions for Maximo. I’ve done several (failed) pilots
with the Maximo mobile suite (of the olden days). I’ve built a mobile app which
is pretty successful and is being used by some large Oil & Gas operators. I
have a bit of experience on a few small Anywhere projects, with Datasplice, and
a few smaller home-grown apps.
Why
shouldn’t you listen to me: the settings and the level of my involvement for each of the above
projects/deployments are vastly different, as such, my opinion on this matter
is heavily biased (toward EzMaxMobile).




