Hi, i’m still using an old UD Version, but i would like to switch to PSU.
I’m only using the REST Endpoints parts . ( no dashboards at all ! )
In UD i was using Scheduled Endpoint to populate some Cache variables, and fetch data in my REST endpoints.
I’m struggling to reproduce the same behavior with PSU.
if i create a basic script $cache:test = 1..1000 | get-random and the schedule it with the admin console, i’m not able to retrieve the content of $cache:test in my REST endpoint.
So maybe i’m missing something, or not understanding someething correctly
At least for newer versions… If you are looking to utilize the cache, I’d say use Set-PSUCache and Get-PSUCache. They function in a similar manner and I can confirm they work.
I don’t know if the Cache scope is tied to those functions but I have not had much luck using that scope in my personal testing.
From my understanding of the Documentation, the PSUCache is available throughout the product. But there is no reference to the $Cache: variable scope in the docs for this functionality. They may not be directly related.
The $Cache scope only works in dashboards. The *-PSUCache cmdlets work throughout the product. The difference is that the PSUCache stores items are CliXml rather than live objects like the $Cache scope.
You can create a scheduled job in PSU to set the variables and then use them in your endpoint as the cmdlets will be available in both places.
What this will do is not flush the runspace state after every execution. You will be able to store your PSSession in a global variable. The module will be automatically loaded into each runspace and you will have access to the Get-EOSession function so you can retrieve your session in your endpoints.
I actually just realized how useful this is for Azure as well. I hadn’t really considered it (I have a script that runs every so often to maintain the connection, since it seems to persist across the system regardless) but this seems like it could be very useful
ok @adam i tried you solution and it kinds of work ^^
i’m saying this, because it’s not totaly what i was looking for …
when i mentionned that i had a cache variable holding pssession i meant more than one Exo session.
And even with one session i dont think i can use your example, because, when the session dies, i will be forced to recreate the session, when a user makes a call to the endpoint, by calling the function.
This will crumble the performance of the endpoint as i have to wait for the creation of the session.
(dunno if i’m clear … )
What i’m doing right now with UD (old version … ): I have a schedule route, that will manage the
Exo sessions for me … when a session dies, it will recreate a new one, and the user experience will be intact.
I had the same mechanism for refreshing some cache variable imported from big csv ( the csv were also generated using some scheduled endpoints.). For this, i think i can use the PSUCache cmdlet and a PSU Schedule + PSU Script. Or maybe switch to a real Database + a PSU Schedule.
If i’m not very clear (sorry english is not my primary language) i can show you some code sample of how i managing it with my old UD.
the question is: can we hope for a cache variable scope that is available through the whole product ? or maybe available for the Rest api part ??
the question is: can we hope for a cache variable scope that is available through the whole product ? or maybe available for the Rest api part ??
No because everything is in a separate process. The server-wide cache works by serializing everything across the process boundaries.
What you could do is store the sessions in global scope in your module. Then create an endpoint that is responsible for refreshing that cached global scope sessions. Then call that endpoint on a schedule.
@adam we made a few tests
we really struggle with pssession and api endpoints …
i tried your solution to create a function to handle pssession (or exchange session). To make thinks easier, instead of using exchange online, i tried with a simple pssession to a remote server.
i have the following function that’s loaded in a persistend env:
function newsession {
if ( $null -eq $global:session ) {
return New-PSSession -HostName demoserver -UserName someusername
}
}
i created a simple api endpoint wich does the following:
If i run the test endpoint and then run the getsession endpoint, it return ‘no session’ !
What i did next : I put a wait-debugger in the getsession endpoint.
I connect to the psu process, and do a get-runspace. I find my waiting runspace. And the remove PSSession to my server !!!
but if i enter in the runspace for the getsession endpoint ( i’ve put the wait-debugger at the first line) and fetch the $global:session variable… it is empty… !
i could do a Get-Pssession, but it find it strange that the global var is empty … ! is this normal ???
I know you sent me a video that I still need to look at but it is normal in that we use a runspace pool so that global variable may not be shared between those runspaces. You make more API requests it will open up more sessions and runspaces. Each runspace would then have a PSSession but the PSSessions would not be shared between the runspaces. Once you make a certain amount of requests, it will stop creating new runspaces and will start reusing the runspaces that were already created.
With PSU v2, you can now use the $Cache scope in all places. If you use the integrated environment, you can share cache variables across APIs, Scripts and Dashboards: Cache - PowerShell Universal
