Options parameter in getObject method

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.4p4

Hey everyone.

I wanted to perform some additional actions on SuccessFactors aggregation and wanted to distinguish somehow the type of aggregation in Customization Rule.

I didn’t see any solution on the forum and wanted to check whether it’s possible to send some kind of flag into context through “options” of getObject method from connector?

Could i use those options and somehow get a flag in customization rule afterwards?
Or can an “instance” attribute be set somewhere and gotten afterwards in customization rule to know specifically if it’s a single or full aggregation?

FYI Single aggregation is made via rule launched in a task through a connector factory and getObject method.

2

Hello Błażej, the options Map is passed to the connector’s getObject() implementation. I don’t think it is forwarded to the Customization Rule. The instance attribute is also meant to identify a specific application instance, not whether the aggregation is single or full, so I would not use either for this.

Give this a try.

Since your single-account aggregation is running through a custom task rule, pass the flag when you manually invoke the Customization Rule after getObject(). Calling getObject() only returns the raw ResourceObject; it does not execute the Customization Rule or the remaining aggregation flow by itself.

I would use the existing state Map for the flag instead of adding a new argument to the rule signature:

Rule customizationRule = application.getCustomizationRule();

if (customizationRule != null) {
    Map customizationState = new HashMap();
    customizationState.put("singleAggregation", Boolean.TRUE);

    Map ruleArgs = new HashMap();
    ruleArgs.put("context", context);
    ruleArgs.put("log", log);
    ruleArgs.put("object", resourceObject);
    ruleArgs.put("application", application);
    ruleArgs.put("connector", connector);
    ruleArgs.put("state", customizationState);

    resourceObject = (ResourceObject) context.runRule(
        customizationRule,
        ruleArgs,
        null
    );
}

Then inside the Customization Rule:

boolean singleAgg =
    state != null &&
    Boolean.TRUE.equals(state.get("singleAggregation"));

During a normal full aggregation, that key will not be present in the state Map, so the condition returns false. This also avoids changing the standard Customization Rule signature. Also handle a null result before passing the object to Aggregator, since a Customization Rule can intentionally return null to exclude an account.

3

I see we are using sailpoint.api.Aggregator to aggregate the resource object returned by the getObject method, so we are not calling customization rule ourselves as it would be redundant since the aggregator does it for us.
Any other idea? Or is that the only way and we should focus around this?

I tried to find some detailed documentation on sailpoint.api.Aggregator but no use.

4

You are right about Aggregator. Since the Customization Rule is already being invoked in your Aggregator flow, you can try setting a temporary attribute on the ResourceObject before passing it to Aggregator.

ResourceObject rObj =
    connector.getObject("account", accountName, null);

rObj.setAttribute("_singleAggregation", Boolean.TRUE);

Aggregator agg = new Aggregator(context, argMap);
agg.aggregate(appObject, rObj);

Then in the Customization Rule:

boolean singleAgg =
    Boolean.TRUE.equals(object.getAttribute("_singleAggregation"));

if (singleAgg) {
    object.getAttributes().remove("_singleAggregation");

    // Single-account aggregation logic
}

A normal full aggregation will not have this marker, so the condition returns false. Remove it before returning the ResourceObject so it doesn’t carry into the remaining aggregation processing.

For Aggregator, the single-account aggregation article on Compass is probably the closest public reference. I couldn’t find detailed public JavaDocs for sailpoint.api.Aggregator.

5

I think I might have to do just that. Thank You!

6

Turns out connector.getObject runs customization rule by itself, then it goes back as resource object to aggregation rule and into aggregator, so unless i can pass the attribute within getObject somehow, then back to square one we go.

7

@blazejbadzio You can make use of CustomGlobal. In your rule, you can make an entry of aggregationType as SingleAccount before calling the single account aggregation code.. then in your customization rule, you can get the key from CustomGlobal. If key is available and value is SingleAccount, then you can execute your code. If key is not available, you can have a separate flow.

In your rule or in customization rule, after you execute the block, you can remove the entry from the customglobal as well. So that regular aggregation can execute its own conditional block.

8

Okay, i think that might be what I need. Thank You !