Store an Attribute on WebServices Source Between Aggregations

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi all,
I have a WebServices source that requires a “lastProcessedID” parameter be passed at each aggregation. I have considered defining a connectorAttribute and setting it using an after operation rule, but after rereading the rule guidelines, I’m not confident that setting an attribute on the source from a rule is the intended purpose of a connector rule. Has anyone crossed this bridge? Practically speaking, can the webservices after operation rule set a connector attribute value? Is this outside of the realm of best practice?
Thanks

2

Hey Matt,

You can use the transientValues attribute to store data in between runs. There was actually just a presentation utilizing this feature at SailPoint’s Developer Days that might be a helpful guide. Video here

Additionally, there are some other threads about folks using this attribute if you are looking for more info

Colin also posted a snippet in this thread about getting the transientValues attribute.

Please let me know if this helps!

  • Zach
3

Thanks Zach.

I do have some experience using the transientValues, but what I have seen is that the data stored therein does not persist between aggregations, only throughout the duration of each aggregation. I have a before operation rule that checks for transientValues and pulls the data if it exists, and with each aggregation, the first run of that rule has to create the transientValues map and set it, similar to the other posts you shared.

Are you saying that the data I store in transientValues during one aggregation should then be available in the next aggregation?

Thanks,
Matt

4

That is a Negative.
Transient values survive from start-of-aggregation to end-of-aggregation.

for my presentations that were linked above, I do not trust HR not to change things… thus, I lookup data at the start of each aggregation and (temporarily) store it.

if you truly need reasonably persistent storage, have you tried setting a different application value than transientValues?
i would be curious to know if something like application.setattribute to set “last timestamp” to your value would store a new ConnectorAttribute on the source itself.

5

Thank you Stephen.

What you’re describing about transientValues is exactly what I’ve experienced. Thank you for the presentation, by the way.

Before posting, I had added a connector attribute to the source using PATCH /v3/sources/:id

[
  {
    "op": "add",
    "path": "/connectorAttributes/deltaAggConsumeCookie",
    "value": null
  }
]

The attribute was added and I now see it in the source details using a GET /v3/sources/:id

In my rule, application.setAttribute(“deltaAggConsumeCookie”, deltaAggConsumeCookie); doesn’t throw any kind or exception, but the value of the attribute in the source config is left unchanged. Based on my logging, I know that deltaAggConsumeCookie had a value of “lastProcessedID=1”. My assumption was that either I’m not supposed to be altering application attributes from within a rule, other than transientValues, or that like transientValues, my settings only persist during that current aggregation. (Unfortunately, with this particular source, I do need to supply this parameter to get a reliable delta aggregation)

I had also considered trying to call PATCH /v3/sources from within the rule, but I don’t know if that’s pushing the bounds of what is considered acceptable or best practice within a connector rule, so I have yet to implement that idea. Had hoped to get further input here before doing so.

Thanks

6

i would DEFINITELY avoid trying to call a patch from your rule.

Let me mock up a test here and see what I can see.

7

hmm. not finding anything obvious from my testing. let me reach out to one of the product teams, and see what i can find out re: “Persistent” storage from your rule

8

Thank you - much appreciated!

9

hey @MattUribe , got it!

so its not application.setAttribute like i thought.
you can set ConnectorAttributes via a response object

so: something like this:

...
processedData.put("data", returnObj);

    Map connectorStateMap = new HashMap();
    connectorStateMap.put("moop","Stephen Was Here");
    processedData.put("connectorStateMap",connectorStateMap);
;
    return processedData;

decent example here:

in my case:
im building a return object in my WebServiceAfterOperation rule
im setting my data in the data tag of my return object

i can build a DELTA map (only store what has to change) in the connectorStateMap attribute as well, and return that, and it will set a Source.connectorAttributes.moop value for me!

Screenshot 2024-04-17 at 10.08.32 AM

10

Wow, thank you @StephenHolinaty

I’ve been through that doc but somehow missed “the connectorStateMap values are updated in the application object permanently”.

Thanks again. That looks like exactly what I need.

Matt

1 Like