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 PublishChannelCache

PublishChannelCache.getInstance().getPublishChannel("PUBLISH_CHANNEL_NAME>").publish(mbo, True)

 

 Happy coding!

Check Network/Firewall Status using PowerShell

Working with Maximo, we have to deal with network/firewall all the time. I can spend a whole day telling you fun stories (or extremely frustrating experience) I had with IT/Network guys. But that's not the point. If you end up here, I guess you're having an issue with firewall. So below is a quick recap of my tricks:

- Ping: the first thing we try when we want to see if a server is accessible from our current machine. But don't jump to a conclusion too early if it shows the server is unreachable. Sometimes, the Network Admin has disabled ping response to enhance security. 

- Telnet: to check if a port is opened, we can use telnet from Windows Command console (e.g. telnet google.com 80). If it can be connected, means the target server is accessible on the specified port. But if it doesn't, first, make sure the server is listening on that port, before jumping to a conclusion that it's a Firewall issue. I made this mistake a few times, blaming the network, then it turned out it's Websphere/Maximo service is not running on the port that I assumed it should be running on

- PowerShell: in many cases, the server is not connected to the Internet, and Telnet is not installed, (and yes, you don't have permission to install new software either). We can use PowerShell to check network connectivity using the two commands below:

$connection = New-Object System.Net.Sockets.TcpClient("google.com", 80)

Write-Host $connection.Connected

The first line will return some errors if it cannot connect to the server, like the screenshot below: 

 If the server is accessible via the provided IP and port, the 2nd line will return the status = Connected