The remaining functions are Get and Set functions that basically build a URL and JSON parameters and call the Invoke-ForceRest. The current way I have written it is you create a session and then pass the session to each respective Get and Set with a session parameter.
$session = New-ForceSession -User me@company.com -Password "blu3b!rd"
Everything works great. I just don't like having to pass the session information from my Get-Something that calls Invoke-ForceRest which actually needs the session information. If I call New-ForceSession in Invoke-ForceREST, I need to get it the username, password, etc. and I'll be calling it over and over again for each respective Get\Set call I make.
New-ForceSession -User me@company.com -Password "blu3b!rd"
Just looking for best practice recommendations. As I said, the current code works great, it just drives me a little crazy that I have to pass the same thing over and over.
Well, you don't want it globally per se, you want it module-lar-ly.
What I typically do is establish and export a module-level preference variable, like $DonErrorLogPath (the "Don" namespaces it to avoid overlap). I set that to some default value.
Then, all my functions expose an -ErrorLogPath parameter which is non-mandatory, and which defaults to $DonErrorLogPath.
Which is a native pattern PowerShell tends to use a lot.
Now... this still requires Get-Something to internally pass the session object to Invoke-ForceRest. But that's the "right" way to do it. I suppose the only other way would be to omit a -ForceSession parameter from Get-Something, and just call Invoke-ForceRest with $RobForceSession. But that's a little... invisible for me. It becomes less clear where data is coming from, and the priority should be making things clear for the USER, not the programmer.
Keep a serialized (pick your poison) copy of data that can be serialized.
Initialize that file, or read it in on module load. Just a normal variable. This will be available to other functions in the module.
Ideally, write Get- and Set-SomeConfig functions to retrieve or write this information, respectively. Consider whether you want to update both the live variable and serialized copy in one shot.
See the Infoblox.psm1 file, Get-IBConfig.ps1, and Set-IBConfig.ps1 files for examples.
Thanks for the assistance. Reviewing the code that Warren posted, it appears to store the session information as a cookie (#RamblingCookieMonster) and then in leveraged as a global variable in the code. I also liked the idea of using -PassThru to store it as a variable as an option to maintain the way it's currently passing the data manually as a session.
One thing that is annoying is that Force.com doesn't seem to actually provide in it's response is a timeout date\time. Basically, I'd need to add logic in the catch if there is a unauthorized message to refer to New-ForceSession.
Overall, I really like your approach in the InfoBlox code. It made me rethink a couple of things like maintaining a couple thousand lines of code in the PSM1 versus creating files and dot sourcing them. Thank you for sharing and the guidance.
The topic ‘Powershell Module: Maintain Session Information Globally’ is closed to new replies.