Integration Framework - Processing Rules and Controls

Body

Do you prefer to not to include custom Java code in your integration implementation?  Don’t have available personnel with the appropriate Java skills?  There are capabilities in the integration framework to implement processing functionality by using integration processing rules and control where Java code is not needed.

Processing rules can be configured on any Publish Channel or Enterprise Service in order to filter transactions or set field values.  Integration Controls can be used as part of a processing rule to allow for configurability of the processing, which can be beneficial when integrating the same data with multiple external systems.

The most common use of a processing rule is to Skip (not send) a message in a publish channel (outbound) when the status of object is not a certain value.  For example your Purchase Requisition publish channel is configured to listen for events (updates) on the PR object and you only want to send the PR to an external application when the PR is Approved (APPR).  This type of rule can use a ‘Value’ integration control to hold the value of APPR (or a synonym value) or it can use a ‘List’ control that can hold multiple values such as APPR and COMPLETE.  A benefit of using an integration control is that if you are sending the same data to 2 (or more systems), each system can provide their own values for the integration control.  So you define one rule with one control and one system sets the value to APPR while the other sets it to WAPPR.  The result is both systems use the same publish channel with the same rule and control but get different processing behaviors based on the values they provide for the control.

• Processing rules can do much more than just skip a message base on a single field value.  A processing rule can be configured to do any of the following:
  Send message only when object is inserted (not updates or deletes)
• Send message based on multiple conditions (2 or more) such as status = OPERATING and Location =‘ABC’
• Similar to above, except you want the two conditions separated by ‘OR’ rather than ‘AND’
• Send message based on a specific field in the object being ‘changed’, such as send an asset message only when its location changes (likewise you can do the opposite using ‘not changed’)
• You can access data from an object that is not part of your integration message and use that data in a     processing, for example, send an asset message only when the asset’s location record has a status of      ‘OPERATING’.
• You can also compare a message field with another field in the message or with a system MAXVAR value
• You can check for the existence of a related object to determine if the message should be sent out, for   example, you only want to send assets out when that asset has at least 1 meter associated to it. Likewise     you could do the opposite and send an asset only when it does not have at least 1 meter associated to it. Keep in mind this type of processing that retrieves other objects uses predefined object relationships.  So   this check could be enhanced by having the relationship include a check for meters that are marked as    ‘Active’ as part of the relationship definition
• You can choose to Skip some portion of the message rather than the entire message.  If your integration    message contained a PR with PR Lines you could use a processing rule to skip all PR Lines (just send the PR data) or it could skip an individual PR Line based on some condition such as the Item type of the item on  the PR line
• You can implement a Stop rule that would prevent a message from being sent out and would raise an exception to the user whose update initiated the transaction.  For instance the approval of the PR initiated an outbound message but a Stop rule was implemented to stop the message because the user did not populate a field that is required by the integration processing.  In this case the user’s save of the record did not complete and they are forced to enter that value before the message can be saved and sent to the external application(s)

The above is not an exhaustive list of processing capabilities rather it is intended to show you some of the various ways you can affect processing of integration messages without having to implement Java code.  The rules above were described primarily for outbound message (publish channel) processing, but these same type of rules could be used for inbound message (enterprise service) processing as well.

In addition to the rules described above around controlling the sending of messages, processing rules can be used to set values of fields in the integration message. A processing rule can be configured to do any of the following:

• Set a default value for a field coming into Maximo, such as set the Site field to ‘ABC’.
• Two field values in an outbound message can be combined into field value for the external system to    consume.
• One field from an external system can be split into two so they are saved in separate fields in Maximo.
• One field can be evaluated for a specific value and when there’s a match the field can be set to another    value.  This also can be done using a cross reference integration control where you have a standard    conversion of a Maximo site id to a corresponding value of the external system.  This control could be used    for outbound processing to convert the Maximo site value to an external value and likewise on inbound     processing converting the external value back to the Maximo site value.

When setting values, as described above, these can be combined with conditions of a rule such that you set a value but only when a specific condition exists, such as set a field value only when the status = APPR.

Keep in mind, all of the processing rules described can be executed against custom objects and/or attributes provided they were defined using the standard database configuration application.

Don’t let Java custom code be a roadblock in your integration implementation.