2016-08-01 08:26 AM
When debugging sequences of code within a WFA command I will move the snippet of code to PowerShell ISE to troubleshoot.
A regular problem I encounter is Get-WfaLogger cmdlets embedded in the code sequence. Doing an import-module of the WFA modules resolves the missing Get-WfaLogger cmdlet problem but the output goes in either the bit-bucket or someplace else. So I swap the the Get-WfaLogger calls with a 'write-output' statement to conduct the testing and undo those changes before moving the snippet back into WFA.
Has anyone come up with a better less error-prone way to handle this. Like a PoSH function with same name that outputs to sysout or such?
I'm re-working a custom WFA command where seeing the output of each individual Get-WfaLogger is essentual to the effort.
Solved! SEE THE SOLUTION
2016-08-01 08:38 AM
Would something like a function that takes a string input and executes Get-WfaLogger or Write-Host commands based on a variable in the code ($test = true/false), server hostname, etc. work for you? It would certainly prevent issues like commenting out the wrong line(s) or other manual work of that nature between testing/prod.
2016-08-02 04:33 AM
Would something like a function that takes a string input and executes Get-WfaLogger or Write-Host commands based on a variable in the code ($test = true/false), server hostname, etc. work for you?
Good suggestion. Knowing that a command within WFA will always be running in Non Inetractive Mode, I can let the fuction do self toggle between write-output & Get-WfaLogger based on the boolean value of environment variable [Environment]::UserInteractive.
This value will always be True on your Powershell ISE console or Script, and always False in a WFA command execution. So you would never need to do any kind of code change running the code inside or outside of WFA and would get the output too.
Write-Output "Outside WFA"
Get-WfaLogger -Info -Message "Inside WFA"
2016-08-02 06:46 AM
Yes, those are good ideas. However, to me it is important for testing existing code, pulled right out of an existing WFA command itself ... and so creating another named function or cmdlet requires global cut/paste is what I'm trying to avoid. I admit to not fully understanding if what I'm looking for can be built as a PoSH function that behaves as a cmdlet or a cmdlet (if they are different, I'm a little fuzzy on that topic. ).
In reality, moving code from WFA into ISE that would similarily need things like Connect-WfaCluster, Get-WfaWorkflowParam, etc ... but those are less important because those are usually constrained to being near the beginning of the code and easily substituted without rocking the debug-boat too much. But a Get-WfaLogger (function or cmdlet) that fully supports -info, -warn, -error and -message would be a big help.
Something that is a new function or cmdlet to start using in new WFA code is another topic to me.
2016-08-03 02:12 AM
I think I understand what are you looking for. Do the following.
1. Open Powershell ISE
2. Copy paste the below Code and execute it. Or save it in a file and execute it. Its a LOCAL definition of Get-WfaLogger. The Other definition present in the module WFA will NOT be used in Powershell ISE and this local one which calls write-output will be used.
3. Now you can copy-paste the Command Code directly from a WFA command into Powershell ISE and execute. No modification needed of any kind. The Get-WfaLogger present in the command code will call the local function definition and start printing the output on your Powershell console.
When inside the WFA command, the code will call the Get-WfaLogger definition present in the WFA module and does what its doing currently.
The same code works seamlessly in and out of WFA.
[parameter(Mandatory=$true, HelpMessage="Message to print")]
2016-08-03 02:19 AM
Now as I see, you can have your local definitions for all the other WFA cmdlets like Connect-WfaCluster, Get-WfaWorkflowParameter. Since you understand what each of these WFA dmlets are doing, you can get them to do the similar task for the code to proceed. Once you have that, the same code can be used in and out of WFA without breaking anything.
Test on your Powershell ISE. then copy-pase and save on your WFA command. No change needed anywhere.
2016-08-03 06:56 AM - edited 2016-08-03 08:00 AM
Sinhaa, thank you for your time and effort !!
I think that is exactly what I need. Several months back I think attempted something similar but was thrown off course by the need for [switch] style parameters ... as I didn't know how to define such a parameter type ... I was stuck thinking everything was either int, string or bool.
Your time is appreciated.