Pesquisar

How do I enable CPHP API suppression when Custom Process Model (CPM) customizations and/or business rules are implemented on a site?

Environment:

Process Designer, Custom Process Model (CPM), Connect for PHP API
All product versions

Resolution:

Suppression is important to prevent rules, external events and/or custom processes from running on an object save or destroy method.  There are three options for suppression methods:

• Suppress Rules - Business rules are prevented from running. Note that rules do not run on objects in a closed status type.
• Suppress External Events - External Events and CPMs are prevented from running
• Suppress All - Business rules, external events and CPMs are prevented from running.

Enabling suppression

First the option needs to be added to the save or destroy method in the Connect for PHP (including CPM customizations) code.

Examples:

$contact->destroy(RNCPHP\RNObject::SuppressRules);
$incident->save(RNCPHP\RNObject::SuppressExternalEvents);
$obj->save(RNCPHP\RNObject::SuppressAll);

After making the code change you must set the Can Suppress checkbox within the Process Designer on each object and each interface you wish to allow suppression. This is only necessary (and possible) for object types tied to CPM customizations through the Process Designer.

Open the Process Designer, expand the OracleServiceCloud or RN object, click the object type (such as Incident), and then check the Can Suppress checkbox for each interface. Save, test, save and deploy the CPMs.

Alternative method for synchronous scripts triggered on object update

This code can be used to avoid looping in synchronous scripts tied to object update (will not suppress a CPM triggered to object update after an API save in a CPM mapped to object create):

        if ($n_cycles !== 0)
            return;

This code has no effect on asynchronous CPM scripts. The preferred way to implement suppression is to suppress on API save and use the 'Can Suppress' check box.

Cause:

Suppression is required when using a CPM as an object updated method unless careful code design is implemented. When an object is saved, that object will enter an updated state and will then trigger rules (if the object is open), external events or CPMs.

Unless the second (and subsequent runs) are controlled by code logic that checks for the action type (create vs. update), a suppress option is required. Failure to enable suppression in this case will result in that object repeatedly running the CPM in a uncontrolled loop. This also holds true for CPMs that open other objects such as incidents and contacts within the code. Those saves should be handled by code logic or be suppressed. The action type in CPM code can be checked as follows:

public static function apply($run_mode, $action, $obj, $n_cycles)
{
    if (RNCPM\ActionUpdate == $action) {
    // CPM is being run on object update in this case
    } elseif (RNCPM\ActionCreate == $action) {
    // CPM is being run on object create in this case
    }
}