Programmatic approach to changing application config on the fly

[#1]

While setting up our application config for Workday, I wanted to be able to perform a once-weekly pull of all HR records to overcome some impacts we've experienced when the HR team make changes to employee records that don't show up in the 'active' set. The means to this end is to un-check the "Don't Allow Terminated Accounts" check box in the application config, which allows the connector to pull both active and inactive records.

I considered setting up a second application configuration that was only different from the primary in that the "Don't Allow Terminated Accounts" check box was un-checked, but that would mean every employee identity cube would have two references (links) to the same Workday record.  Alternatively, I could manually uncheck the box once a week, which seemed a silly approach to automation. While chatting with one of the SailPoint ES guys, he pointed out that pretty much everything in IIQ is an object, which can be addressed programmatically. This gave me the idea to create a standalone rule to toggle the application setting when I need to.

A quick dive into the debugger to look at the underlying XML that is the Workday application config revealed the application attribute of interest is "isInactiveWorkersAllowed". Changing its value to 'true' (boolean, not string) checks the box and causes the connector to pull only inactive records. Changing its value to 'false' or null clears the check box and allows the connector to pull all records. (The logic is confusing if you pay attention to the check box name vs. the attribute name, but this is the way it works.)

Since what I want to do is to have the application pull only the active records on a daily basis, then pull all the records once a week, I decided to set the rule up to read the current application config value for "isInactiveWorkersAllowed" and toggle it from false to true or true to false, based on its current setting. This allows me to have a sequential task for the weekly full Workday aggregation where I run the toggle rule before the aggregation starts, then run it again afterward to set the application config back to its normal, day-to-day config.

The rule, as I've written it is below and works exactly as I expected, however the point is more along the lines of a reminder of the flexibility provided by the IIQ platform and the identity API to perform management of even the components of the IIQ system using just the tools available natively.

Obviously, this is NOT a SailPoint supported config. Your mileage may vary, enter at your own risk...

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Toggle WD Inactive Records">
  <Source>
  
  import sailpoint.api.ObjectUtil;
  import sailpoint.object.Application;
  import sailpoint.api.PersistenceManager;
  import sailpoint.api.SailPointContext;
  import sailpoint.tools.GeneralException;
  import sailpoint.tools.Util;
  import java.util.HashMap;
  import java.util.Map;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
  
  Log log = LogFactory.getLog("sailpoint.rule.ToggleWDInactiveOff");
  log.trace("Enter Toggle WD Inactive Records");
  log.trace("context:  " + context);
  
  Application app = context.getObjectByName(Application.class,"Workday Direct");
  String applicationName = "Workday Direct";
  log.trace("app:  " + app);
  
  try {
    Map ops = new HashMap();
    ops.put(context.LOCK_TYPE, context.LOCK_TYPE_TRANSACTION);
    appID = (Application) context.lockObjectByName(Application.class, applicationName, ops);
    log.trace("Locked appID:  " + appID);
    boolean flag = appID.getAttributeValue("isInactiveWorkersAllowed");
    log.trace("Flag:  " + flag);
    if (flag == true) {
      log.trace("flag true, setting false");
      appID.setAttribute("isInactiveWorkersAllowed",false);
    } else if (flag == false) {
      log.trace("flag false, setting true");
      appID.setAttribute("isInactiveWorkersAllowed",true);
    }
    
    context.saveObject(appID);
    context.commitTransaction();
    context.unlockObject(appID);
    log.trace("Unlocked appID:  " + appID);
    context.decache(appID);
  }
  catch (GeneralException ge) {  
		System.out.println(ge.toString());  
	}
  log.trace("Toggle successful")
  </Source>
</Rule>

[kruegja]

are you manually toggling?   otherwise, why wouldn't you just look at the day of the week and run the code based on the day of the week?

[michael_bullock]

I did it this way so I would avoid manually toggling the active-only flag on the Workday application.  The goal was to allow me to add this to a sequential task run that flips the toggle, runs the once-a-week aggregation, then flips the toggle back. 

As I said, I published it here mostly as an interesting reminder that you can programmatically manage just about everything in IIQ, as long as you understand it's XML structure.