Looking for a way to cache an auth token in vRO

[Koru85]

Hello All,

I am working with a number of RESTHost end-points which return an authentication token that is valid for 90 seconds. This is causing me to write a custom authentication process rather than using the HTTP-REST plugin's auth mechanism.

Almost all of our blueprints will rely on dynamic properties that will be querying the REST hosts on demand. From what I can tell that will require a number of actions to be built, each of which will have to connect to a REST host and grab some data. In most cases there will be a number of actions called to get all the necessary data, one right after the other.

It would be ideal if I could cache the auth token somewhere and have the individual actions look there first, before going through the login process themselves.

I have not found any mechanism in vRO to accomplish this. Does anybody have any ideas?

Thanks.

[iiliev]

Hi,

There is no direct caching support. Some of the plug-ins have their own simple cache, like DynamicTypes' DynamicTypesManager#getFromCache/putInCache scripting methods.

One option that I haven't tried yet but that should work is this plug-in - GitHub - dimitrovvlado/o11n-plugin-cache: Cache plug-in for vRealize Orchestrator

[Koru85]

I was afraid that the answer would be there is no direct caching support. I hadn't considered searching github. Looks promising. I will check it out and let you know if it works well.

Thanks

[filosmith]

Have you tried storing it in a Configuration Element?

[CuttingRoomFloo]

You could use a Resource Element to store this in, I've done the same thing various times. My basic premise looks like this:

01) Create Workflow with Locking that first checks Resource Element and examines expiry time of token

02) If token has expired, it fetches a new one and updates Resource Element. If not, it retrieves the stored one

03) Wfl is unlocked at the end (and also unlocked in default error handling)

04) (everything can use the same wfl to fetch a token for that API as the locking should prevent token clashes)

Make sure you use locking because you don't want the same wfl hit by 2 instances or you'll probably get token clash. By the same respect, be sure to allow unlocking on error. I prefer storing the entire token but my wfl has 2 outputs, the full token and just the 'token' part of it so I can null out the one I don't want. Also, depending on the token, watch out for things like 'token lifetime' vs 'token refresh' as some systems will have a valid time of e.g. 24hrs but that's only valid if you keep refreshing the thing (it seemed fairly redundant and a little insecure to me keeping a token valid just in case it might be required).

[qc4vmware]

Anyone have any comments on the speed of using dynamic types caching vs a config element vs a resource element?  I've mainly used configuration elements in the past  but I'm getting ready to write a few workflows that might be pretty read intensive.  I dunno if whatever caching vRO does on its own would keep things snappy and I should just stick with that or is reading from the config an expensive type of read.

[qc4vmware]

Well I just wrote a little test and on 10,000 reads the DynamicTypes cache took less than one second, configuration element took around 5 seconds.  At 1000 reads they were both sub second so the config element is still pretty fast.  Definitely fast enough for my needs.

[iiliev]

DynamicTypes cache is a simple in-memory hash map. On the other hand, using resource elements and configuration elements could involve database operations.

Usually, access to the database is slower (sometimes, much slower) than access to the memory, so the performance difference you are observing is kind of expected.

[eservent]

Hello,

I use the DynamicType Cache, it works fast, it's simple and it's built-in.

I store 1000 values and there is no problem (latency, stability, reliability...).

I wrote a sample of an action to manage cache value inside DynamicType cache : Easy Cache Manager for any actions results - Samples - VMware {code}

Emmanuel.