IBM Maximo Autoscripting Guide – Publish channel scripting

Publish Channels provide the outbound integration backbone of Maximo. They can be event-enabled such that when some MBOs get added, updated or deleted, these channels can trap those events and publish a message to the outbound JMS queues. You can also do some offline exports using the channel from the Integration External systems application or from cron jobs invoking the export API of the channel. The messages then get picked up from those queues and get pushed to their final destination (using the endpoint/handler framework). Publish channels support the following script points:

Script point	Purpose
Event Filters	Used for smart filtering of publish channel events
External Exits	Used for data transformation of outbound messages from Maximo format (`irData`) to external format `erData`
User Exit (Before External Exit)	Used for data updation without structural change to the Maximo format message (`irData`).
User Exit (After External Exit)	Used for data transformation from the output of the External Exit to target external format.

Event filters for Publish Channels

You may be required to filter the events in a way that the channel publishes the message only when a certain state condition is met. You could achieve this by writing event filter classes in Java. Maximo 7.6 allows you to use scripts. To create a Filter script, use the Script For Integration” -> “Publish Channel” -> “Event Filter option in the Automation Scripting application.

The following filter script is an example that can be used on the MXASSETInterface publish channel:

if service.getMbo().isModified("status") and service.getMbo().getString("status")=="BROKEN":
  evalresult = False
else:
  evalresult = True

The evalresult being set to False will indicate the event to be published. So effectively this script will filter all events that did not change the status to APPR for the workorder. You might wonder that this could have been done using a channel rule or channel exit class. That is definitely possible for simplistic rules, although this comes at a steep price. The rules get evaluated after the event has been serialized and then passed to the exit layer for evaluation. By that time these rules get evaluated and you already paid the price of serialization. A better alternative is to skip it.

The event filters apply to event based publish channels. Publish channels that are used to export data cannot leverage these filters.

Also there is a bug which causes the “mbo” variable to not be accessible directly here. You will have to use the service.getMbo() to get access to the event MBO here.

Exits for Publish Channels

There are three exit points for publish channels that can be scripted. The purpose is mostly for data transformation, but it is not limited to that. You can conceivably use the exit to make some direct calls to external services and then skip the rest of the Publish channel processing. The following table lists some of the implicit variables that the publish channel scripts will have:

Variable	Purpose
erData	An instance of psdi.iface.mic.StructureData used to hold the external document. The value of this variable is set to null for External Exits and Before User Exits in the channel.
irData	An instance of psdi.iface.mic.StructureData used to hold the internal (Maximo format) document.
ifaceType	The interface type name.
ifaceName	The channel name.
osName	The Object Structure name.
messageType	The message type which can have values like Sync/Publish.
extSystem	The external system name.
userInfo	The UserInfo object representing the authenticated user that invoked this service.
conn	The jdbc Connection object.

The following screenshot is of the Integration Script Wizard for Publish Channel exits.

The following script is an example that changes the description of operating assets on outbound transactions. In this scenario, the MXASSET object structure provides irData (instance of psdi.iface.mic.StructureData) to the MXASSET publish channel (MXASSETINTERFACE) for processing. An automation script is configured to run on the external exit class of the publish channel. The script checks the status of the asset in the irData element. If the asset is in operating status, the script inserts a value in the description field and prints a message to the log file. The erData element is then constructed and is forwarded to the external system. If this is done as an external exit, the name of the script would be PUBLISH.MXASSETINTERFACE.EXTEXIT.OUT.

if irData.getCurrentData("STATUS") == 'OPERATING' :
  irData.setCurrentData("DESCRIPTION","hello")
  service.log("MYASSET description change")

The following example is of a user exit before the external exit that just sets the descriptions to the irData for the job tasks in a job plan.

jobTasks = irData.getChildrenData("JOBTASK")
numberOfChildren = jobTasks.size()
for i in range(numberOfChildren):
    logger.info("Inside Loop" + str(i))
    jT = jobTasks.get(i)
    irData.setAsCurrent(jT)
    taskPrefix = "This is task number: "
    newDescription = taskPrefix + str(i)
    irData.setCurrentData("DESCRIPTION", newDescription)

This irData API usage is independent of json or xml. However, the irData.setAsCurrent(jT) API is the one that you should use so that it works for json and xml. If instead you use the irData.setAsCurrent(jobTasks, i) API, it will only work for xml and not for json.

Edit this page on GitHub

Integration Scripts: Object Structure Scripts

Integration Scripts: Enterprise Service Scripts