For most of the simple integrations in which we send out data from Maximo to external systems (SAP, Oracle…legacy…Custom Applications) we do not need to filter records as most common filtering can be achieved using the “Processing Rules” available on a publish channel.

In this example we will see how the out of the box MXWOInterface is used to export or publish the Work Orders to external systems using a custom Event Filter class.

This post is about the Event Filter Class on a Publish Channel in MIF. If you are aware of Publish Channels (Integration -> Publish Channels) in MIF you would have seen the field which says Event Filter Class.

This post will unravel the mystery and usefulness of this class and what can be really achieved and when to use it.

Consider a scenario in which if the Work Order has a target start date in the past we do not want to send it to the external systems.

Ok, so now let’s start working on this scenario:

1. Write the Filter Class

I prefer using Eclipse for writing my java classes you can use any tool of your choice.

Our filter class I will name it as com.maximotimes.iface.app.wo.WOEventFilter as we intend to use it on a Work Order Publish Channel so this sounds about right.

Now, what makes a class an event filter class is it will extend psdi.iface.mic. MaximoEventFilter which is an out of the box base filter class. By base I mean just like we extend Mbo or MboSet to create a custom Mbo we will extend this class to create a custom filter class

This base Filter class has a few methods but the most important and the one which we are using in this case is:

public boolean filterEvent(MboRemote mbo) throws MXException, RemoteException

We will override this method in our class so that we can put our own business logic and based on that either filter or let the data go out of maximo to any external system.
If this method returns true, the record is filtered and not sent across by the publish channel and vice-a-versa.
This method makes available the mbo which is the record which will get either sent or skipped based on our logic. The mbo is of type Work Order in this current example.
The other useful method is:
protected boolean stopRecurrence(MboRemote mbo) throws MXException, RemoteException
This method has a specific use, in case the record which in this example is Work Order itself was created by an inbound interface we may want to stop it from going out.
Let’s say Work Orders are created by maximo and other external system (call it WORK-A).
Our goal is to keep both systems in SYNC so both should have the correct list of workorders.
Whenever, a Work Order is created in maximo our Publish Channel will send it to WORK-A using MIF.
If WORK-A creates one it will send us the same by any inbound integration. This one which we received from WORK-A we can use the stopRecurrence method to stop it from going back to WORK-A.
So, if the creator of that record is MIF this method allows us to prevent from going out.
I hope it makes sense.
Following are the two methods I wrote in my filter class:

@Override	 	 
public boolean filterEvent(MboRemote mbo) throws MXException, RemoteException {	 	 
 // TODO Auto-generated method stub	 	 
 if(mbo.isNull("targstartdate"))	 	 
 {	 	 
 return true;	 	 
 }	 	 
 else	 	 
 {	 	 
 if(mbo.getDate("targstartdate").before(new java.util.Date()))	 	 
 {	 	 
 return true;	 	 
 }else	 	 
 {	 	 
 return false;	 	 
 }	 	 
 }	 	 
}	 	 
@Override	 	 
protected boolean stopRecurrence(MboRemote mbo) throws MXException,	 	 
RemoteException {	 	 
 return true;	 	 
}

2. Attach the filter Class

As per the screen shot above we will attach the filter class to the Publish Channel
3. Test
This is a very simple scenario, this class can be extended to apply in a range of complex scenarios.
As per the code in our example filter class if the target start is null or from past it will not send this record through MIF to external system.
If the record gets filtered you can see the below message in maximo logs:
Event for WORKORDER has been filtered for Publish channel MXWOInterface