 |
| Clocks by renbostelaar |
"Disable" Steps in a Task or State
Have something you're working on but want to continue testing your process? Just put it after the End Task step in your Task or after an End Process in a State. IPA will put a nice gray shade over the step(s) with the word "Unreachable" on them. If Disable is something you think should be an option or attribute for steps, feel free to up-vote and comment on idea D1064 IPA deactivate/activate Step(s) in PAD.Get Your Database Complex Types to Auto-Gen Ahead of Use
The Database Tools because available as of 4.0 SU2 and they rock! What took a minimum of 5 steps in a Handler, and many more if you're doing anything of use, to select a row now only takes 1 step in IPA. Yep, it's that simple. One of the many useful features of the IPA database tools is they will inspect your table and auto-magically create a complex collection type for database results. Usually you'll get to this point when you need to use your first Select Row(s) step for the table.But what if you already have the database designed before your process and need the var before your first query? Just like we talked about in the previous hack, Drop a Select Row(s) step after an End Task step and assign the results to a local collection instance. Even though the step is Unreachable, the auto-gen executes.
When or why might I do this? Sometimes the Tables I'm going to use in a process are pre-existing. When this happens, most likely I'm doing stuff at the Work Item level, implementing a Page and need a "display instance" of the variable before I'm using Select Row(s) to fetch data from the database. You don't get the Complex Type defined for Database Results until you do a Select Row(s), so just drop one in at an innocuous spot and voila.
You can go back to the Task where you stashed the Select Row step later and delete it once you've reached the point in your process when you've done your first real Select Row(s).
Set a "Poor Man's Breakpoint"
Yeah we all know debug in IPA isn't, so first please take a minute to go up-vote idea D858 Debug in PAD, and then read on. To set a "poor man's breakpoint," simply perform an operation on a variable that is NOT_SET and you'll stop your process RightDamnNow. Guaranteed. Have a process level string var called Breakpoint and make the initial value NOT_SET. Anywhere in your process where you want it to stop, do an Update Variables with something like If(Breakpoint == "boom", "boom", "huh, guess it's gonna continue 'cos it's set."). Since Breakpoint is NOT_SET, this one's gonna go boom with an error performing an operation on a variable that is NOT_SET. Of course the Waiting Process is a gentler approach if you want to be able to continue instead of a hard stop."Bookmark" Your Process to Easily Pick Up Where You Left Off
When you reach a stopping point, drop in an Update Variables step. Use the Notes tab to remind yourself what's next on the to do list. Don't make any assignments in the Update Variables, which will result in a Yellow "Caution" flag for this step. This is harmless because the Process will still run in Test mode and can still be published. Nice thing is, next time you're back in ICSM you can follow the process tree down to the caution step to the exact spot where you left off. The bigger your process, the easier this will make finding where to continue. Oh, and of course don't forget to delete that step or cut out your Notes and start using the Update Variables to do some work.Please feel free to share any timesavers you've discovered while working with IPA!
And Happy Processing!
