Change Detection

The initial xml data sent to IFS Planning and Scheduling Optimization (PSO) will of course be a full data load containing all the data required by the scheduling system. However it is often necessary to send incremental updates to the system when data changes within IFS Cloud. For scheduling data it is usual to send a full load once per day (usually overnight) and then further incremental changes throughout the day. For modeling data the full load will only be sent once and from that point onwards only changes are sent.

The integration model will handle the sending of full load data and changes automatically, based on the 'changedetection' component within the model. For each data fetch rule where changes are expected a changedetection model should be added which can detect changes from any combination of tables within IFS Cloud. For each table a 'trigger' is added to the changedetection model, which can use one of three distinct methods for detecting changes:

• Direct row change handling: A trigger is added to the specified table in IFS Cloud to register the rowkeys of any changed rows within the scheduling integration framework. The full select is then filtered to only return rows relating to these changed rows, and the system automatically detects the resulting changes to the scheduling data. For this option the full select statement must select the rowkey of the table as a column, and the trigger must include the 'objkey' argument to specify which returned column this is. It is possible to add a Guard Condition on the trigger to ensure the trigger is only fired on data that is to be sent to PSO for example:

    changedetection {
            trigger on FND_ROLE_TAB {
                guardcondition = 
                "FUNCTION Trigger_Guard RETURN BOOLEAN
                IS
                BEGIN
                    RETURN (INSTR(:NEW.ROLE, parameters.Company)=1);
                END;";
                objkey OBJKEY;
        }
    }

- Indirect row change handling: In this case the trigger should specify a table to watch for changes, a target table that is directly included in the select and a mapping from the watch table to the target table. Any changes to the watch table will then be recorded against the target table to be picked up via direct row handling on this table. - Full diff change handling: In some cases it may be difficult to determine how a change to a table will affect the query. In this case the 'fulldiffonchange' option can be used. This will run the full select query whenever a change is made to the table and compare this with the previous version of the data for this query to determine changes. This option can also be used to detect changes to tables that do not have a row key. Please note however that this option will be much slower compared to the other options so should only be used for queries that return a small number of rows, and against tables where changes are infrequent.

Please note that for scheduling data fetches, any change to a row will result in the entire row being updated, as is standard for scheduling data updates. For modeling and system data fetches, row updates will only update the columns that are specified in the data fetch. This is to allow data that is not specified by the data fetch to be maintained within the scheduling system. Note however that any change to the row will result in all columns specified in the data fetch being updated. Thus there should be a clear split between those tables and columns that are synchronized with IFS Cloud and those which is maintained independently within the scheduling system.

Due to the change detection process using rowkey then on installation of the scheduling model rowkey will be enabled on all tables included in the change detection automatically.

Any trigger can be marked as a "prompt update" which when fired will send the data to PSO immediately rather than waiting for the database task "Send Scheduling Optimization Dataset updates" to run to send the changes from IFS Cloud to PSO.

It's possible to exclude updates and/or deletions from being sent for a record set by defining the options "omitupdate" and "omitdelete" on the change detection rule. This can be an alternative to having a guard condition.

It's possible to record the Dataset ID up front in the Scheduling Change Log to reduce unnecessary change handling. This can be achieved by calling the method Set_Change_Dataset_Id inside the guard condition.

For an example of change detection implemented see Examples.