When an outbound transaction is triggered from Maximo, it has to pass through lots of checks and updates, once it has passed through all that based on the endpoint (xml, csv, http…) defined, the object is delivered to the external system or common point of contact in case of flat files or xml files.

Similar, for inbound transaction, when data is pushed into Maximo, it makes sure the data complies to its set of rules and restrictions. Once it complies, then it has to go through the set of rules defined on the MBO level (java classes, automation scripts, DB config…) and once all clear is received, it is actually inserted into Maximo database. If there is an error it goes to reprocessing queue where once the error is rectified the record can retry.

These checks and balances as we all know are very important as it maintains the integrity of Maximo database and also it makes sure only data which Maximo is prepared to receive comes in.

In this article I will explain the processing rules from outbound transaction perspective. They will apply in a similar fashion for inbound if not completely same.

Processing rules are at the Object structure level. Before MIF builds the object it checks if it meets the processing criteria and whether it really needs to build an object or skip this transaction.

For example, let’s take Work Orders, we want to send approved Work Orders to an external system. In this scenario the processing rule will be to check the status of the Work Order and if its APPR or a synonym of APPR the record is pushed out else ignored or skipped.

Similarly, processing rules can be for used to manipulate the data in the object (Work Order Object in this case) before it is sent to external system.

Of course in some highly complex scenario’s you may have to write user exit classes but many scenarios can be fulfilled using processing rules object manipulation.

Let’s take an example, in this I will show how to make sure a Work Order in an approved status can only be exported out of maximo.

Using this scenario we will expand and add more examples.

If you see the screenshot below I will be using an out of the box object structure MXWO for this example.

On this object structure we will define a publish channel as we want to export data out of maximo.

Go to Integration -> Publish Channel and click New, and create a new Publish Channel, I have named it as MTWOEXPORT and attach MXWO object structure to it.

Now we will be adding processing rules, so if a Work Order is not approved MIF will skip processing it and if its approved will export as an xml file into the directory specified in system property “mxe.int.globaldir”.

Click new row in Processing Rules for sub-record Work Order in the table below, and add a new processing rule, I have added it as “APPRWO”. In action I have selected as “SKIP” as we want the record to be skipped if it does not meet the criteria which is status=APPR.

If you select “Stop” the transaction will be stopped as soon as the first Work Order record does not meet the criteria, here we have selected Skip so records which meet the criteria are processed and rest skipped.

If you see, I have selected “Apply on Primary object update” and unchecked the rest because we only want the transaction be presented to MIF on update of a Work Order. If you requirement is on insert or delete as well you can select the other relevant boxes.

Click Add Modify Conditions so that we can enter the condition for approved work orders only.

Click New Row in Condition table and select Object field as per the screenshot below:

The way to read this is, “For any Work Order record, which has a STATUS NOT EQUALS APPR, SKIP (action we select in the screen before) the record”.

So, if the condition STATUS NOTEQUALS APPR returns true the record is skipped and not processed by MIF.

From select action we need to enable the listener so that MIF is aware that it needs to monitor the primary object of the Object Structure (which in this case is Work Order) and present any updated record to MIF so it can process it based on the processing rule defined.

The SEQOUT instance of JMSSEQCONSUMER cron task should be active so that any record written to Sequential outbound queue is processed.

Attach this Publish Channel to an external system, enable it and make sure the External system is enabled as well. For this example I have selected the xml file endpoint for the Publish Channel.

Change the log level for integration to INFO from logging application.

Now, go to any Work Order record which is not approved and edit any field and save you should see below in logs:

[INFO] [MXServer] [] Skip transaction for assignment APPRWO

[INFO] [MXServer] [] Skipping…..key values found to be: SITEID : BEDFORD, WONUM : 2009

[INFO] [MXServer] [] BMXAA1671I – Skip transaction.

This shows that the record is being skipped as it’s not approved.

If you select an Approved Work Order or Approve a Waiting for Approval Work Order, you will see the below message in logs:

got message from queue jms/maximo/int/queues/sqout

This means the record was processed by MIF and written to SEQOUT JMS queue which the cron will pick up and send to the specified endpoint which in this case is Xml file and save the xml file into the mxe.int.globaldir specified in System Properties application.

This is a basic example and it demonstrates how to interpret Processing Rules. Similarly processing rules can be applied at the Object level or even we can check if a MAXVAR has a specific value to make the GO/NO GO decision for any record presented to Maximo Integration Framework.

Series Navigation