VMware Cloud Community
harkamal
Expert
Expert
Jump to solution

Debugging workflows

I've been debugging c# code that runs local and I could create breakpoints and see what runtime objects are loaded and so on.

I wonder how to debug workflows that I develop on desktop and run against vcac remote instance. Is this possible, or I am way off. How do development team develops/debugs their vcac works?!

Thanks in anticipation.

Tags (2)
Reply
0 Kudos
1 Solution

Accepted Solutions
d-fens
Enthusiast
Enthusiast
Jump to solution

Hi harkamal, it is not quite clear to me where the exact problem is that you experience. Therefore I would detail the steps that I would take to debug the script:    

1. I split the tasks for each workflow steps into several subscripts that are called via a main (wrapper) script. (I would use some logic as described in http://d-fens.ch/2013/12/05/vcac-dynamically-execute-scripts-in-externalwfstubs-workflows-with-power...).

2. Each subscript that you want to debug (or just the main wrapper script) would have some kind of code on top that would have some kind of wait logic (a 'lock') that it would wait on. For this I use the logic as described in (http://d-fens.ch/2013/11/16/synchronisation-issues-in-vcac-workflows-and-how-to-solve-them/).

3. Now that the main workflow script is waiting you can execute whatever code you want in an asynchronous way (with or without ISE). In order to be able to process the same virtual machine that your workflow script is using you have to retrieve the name of the VM (or preferrably the guid) to the script. You then resolve and retrieve the VM object via a call like this:

PS > $Machine = $MgmtContext.VirtualMachines |? VirtualMachineID -eq '77b7bad5-65c8-4fe4-b977-24ff060e691e';

where $MgmtContext is the variable holding the vCAC management context (as described in http://d-fens.ch/2013/10/10/investigating-the-vcac-5-2-mgmtcontext/) and '77b7bad5-65c8-4fe4-b977-24ff060e691e' is the guid of the machine currently being provisioned.

To just retrieve the "newest" created machine you could execute a call like this (in a testing environment where only you provisions resources that might be easier than noting down the machine guid):

PS > $MgmtContext.VirtualMachines | Select-Object VirtualMachineID, VirtualMachineName, VMCreationDate | sort -Property VMCreationDate -Descending | Select-Object -First 1;

4. When you execute and test your script in ISE make sure you load all the assemblies again (even if they are already loaded in the PowerShell session) as it is a different process. Make sure you either run the ISE under the same account as the vcac service account or specify credentials when you connect to the vcac repository. When you loaded the script file to execute and debug (Ctrl+O) set a breakpoint within the script by either using F9 or 'Set-PSBreaktPoint' and then use the interactive Shell (Ctrl+D) to type in the script name to execute (in the same way you would execute it from the workflow). By using the breakpoint and single step you are now able to work through the script and do some verification and adjustments.

5. When finished testing and debugging you remove the 'lock' from step (2.) so the main script continues to run and the provisioning process resumes.

Keep in mind, that there is a timeout defined how long a workflow can run, so when you need more time make sure to increase that value.

So in short; the trick is to make the scripts (that are called by vCAC for a given workflow stage) wait, so you can fire up a session on your own to asynchronously execute script code yourself. However, you will not be able to "break" into a script that is run from within the vCAC workflow itself (different session, different process).

Hope that makes things a bit more clearly.

Regards, Ronald

Ronald Rink d-fens GmbH

View solution in original post

Reply
0 Kudos
5 Replies
harkamal
Expert
Expert
Jump to solution

NNobody got any idea 🙂

Reply
0 Kudos
d-fens
Enthusiast
Enthusiast
Jump to solution

Hi harkamal, you would debug workflows just as you would debug any other Windows Workflow Foundation workflow, eg using Visual Studio to attach the hosting service (http://msdn.microsoft.com/en-us/library/ee358745). However, I would recommend to use either PowerShell or vCO to create your workflow logic. With PowerShell you could use this approach (http://d-fens.ch/2013/11/16/simplify-your-life-while-testing-and-debugging-powershell-scripts-in-vca... ) to debug your code and in vCO you could use the intrinsic mechanism like breakpoints or the interactive console to debug the code (http://d-fens.ch/2013/12/17/finally-vco-interactive-shell/ ).

Regards, Ronald

Ronald Rink d-fens GmbH
harkamal
Expert
Expert
Jump to solution

Brilliant work, thank you, this is a life saver Smiley Happy

Good day!

Harkamal

Sent from my iPhone

Reply
0 Kudos
harkamal
Expert
Expert
Jump to solution

Hi Ronald, I am unable to get the script to enter debug mode using ISE, it just runs and closes, while the workflow script is still in waiting. What am I missing here !

"With your vCAC script waiting you can now either start another instance of that script in your IDE and debug it step by step getting the same results as if it executed non-interactively.
I really like vCAC for its flexibility …"



meantime, I got powershell to export objects that I analyze later (Export-CLIXml)


look forward to hear from you.

Reply
0 Kudos
d-fens
Enthusiast
Enthusiast
Jump to solution

Hi harkamal, it is not quite clear to me where the exact problem is that you experience. Therefore I would detail the steps that I would take to debug the script:    

1. I split the tasks for each workflow steps into several subscripts that are called via a main (wrapper) script. (I would use some logic as described in http://d-fens.ch/2013/12/05/vcac-dynamically-execute-scripts-in-externalwfstubs-workflows-with-power...).

2. Each subscript that you want to debug (or just the main wrapper script) would have some kind of code on top that would have some kind of wait logic (a 'lock') that it would wait on. For this I use the logic as described in (http://d-fens.ch/2013/11/16/synchronisation-issues-in-vcac-workflows-and-how-to-solve-them/).

3. Now that the main workflow script is waiting you can execute whatever code you want in an asynchronous way (with or without ISE). In order to be able to process the same virtual machine that your workflow script is using you have to retrieve the name of the VM (or preferrably the guid) to the script. You then resolve and retrieve the VM object via a call like this:

PS > $Machine = $MgmtContext.VirtualMachines |? VirtualMachineID -eq '77b7bad5-65c8-4fe4-b977-24ff060e691e';

where $MgmtContext is the variable holding the vCAC management context (as described in http://d-fens.ch/2013/10/10/investigating-the-vcac-5-2-mgmtcontext/) and '77b7bad5-65c8-4fe4-b977-24ff060e691e' is the guid of the machine currently being provisioned.

To just retrieve the "newest" created machine you could execute a call like this (in a testing environment where only you provisions resources that might be easier than noting down the machine guid):

PS > $MgmtContext.VirtualMachines | Select-Object VirtualMachineID, VirtualMachineName, VMCreationDate | sort -Property VMCreationDate -Descending | Select-Object -First 1;

4. When you execute and test your script in ISE make sure you load all the assemblies again (even if they are already loaded in the PowerShell session) as it is a different process. Make sure you either run the ISE under the same account as the vcac service account or specify credentials when you connect to the vcac repository. When you loaded the script file to execute and debug (Ctrl+O) set a breakpoint within the script by either using F9 or 'Set-PSBreaktPoint' and then use the interactive Shell (Ctrl+D) to type in the script name to execute (in the same way you would execute it from the workflow). By using the breakpoint and single step you are now able to work through the script and do some verification and adjustments.

5. When finished testing and debugging you remove the 'lock' from step (2.) so the main script continues to run and the provisioning process resumes.

Keep in mind, that there is a timeout defined how long a workflow can run, so when you need more time make sure to increase that value.

So in short; the trick is to make the scripts (that are called by vCAC for a given workflow stage) wait, so you can fire up a session on your own to asynchronously execute script code yourself. However, you will not be able to "break" into a script that is run from within the vCAC workflow itself (different session, different process).

Hope that makes things a bit more clearly.

Regards, Ronald

Ronald Rink d-fens GmbH
Reply
0 Kudos