Async CPMs and Interface Configs

CX Version: 

When using async CPMs, DO NOT leverage interface configs. An async CPM may run on any of the site's interfaces, regardless of which original interface triggered the logic! Oracle states that this is "working as designed," meaning they are unlikely to fix this issue anytime in the near future. Using interface configs will cause a lot of headache during development because the correct configs may be pulled and work correctly for a time, but when the CPM switches to another utility process (unbeknownst to you), an incorrect config value from another interface will be pulled.

Workarounds

  1. Only use site configs in your async CPMs
  2. Store your configs in a custom table, and manually query the database, filtering on the interface
  3. Only use synchronous CPMs to queue up changes in a custom table: for external integrations, poll the custom table and run your asynchronous logic outside of Oracle's infrastructure

Comments

As an expanded thought to Workaround #1, you could probably specify the interface name as part of the Config Key value so that you could support different values per interface.

For example, if you interface names were bravo, charlie, delta and your config was CUSTOM_CFG_MY_CONFIG, you would define your configured values as:
- CUSTOM_CFG_MY_CONFIG_bravo
- CUSTOM_CFG_MY_CONFIG_charlie
- CUSTOM_CFG_MY_CONFIG_delta

It would be then be up to your script to get the target interface (from the incident context) and do the config lookup with a dynamic value.

Psuedo Code:

$interface_name = $this->getInterfaceName($obj);
$config_key = sprintf("CUSTOM_CFG_MY_CONFIG_%s", $interface_name);
$config = $this->getConfigForKey($config_key);

Zircon - This is a contributing Drupal Theme
Design by WeebPal.