IPA Time Saving Hacks Part 1

Clocks by renbostelaar

Wanna save some time when developing a Process with Interaction Process Automation? Me too, so I'll just jump right into five quick little hacks for IPA that I've come up with over time.

"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!

Debugging Made Easier with a Waiting Process

UPDATED June 16, 2013 12:15 PM EST:

The "Waiting Process" trick was taking advantage of unintended functionality. Processes will no longer be able to launch with "Wait to Complete" in a Work Item as of SU5, but of course "Wait to Complete" will still be available as an option at the Task level.


Hey There Process-meisters! This is no earth-shattering discovery, and hopefully some of you already figured it out. As I had my debug-on this evening (yes, it's all pretty much DIY debug with IPA today) I needed a way to look at some variables mid-process while in a Work Item.

Ye Olde Elder Box Bug
Image Credit: Orkin.com

Unfortunately we don't have a Breakpoint tool (yet, fingers crossed) in Interaction Process Automation and the Wait tool doesn't exist at the Work Item level, but guess what? Run Process does, so....

1. Make a New Process.
2. Initial State - call a Task, which I naturally called WAITING.
3. Within that Task, set a Wait for 1 minute.

I wouldn't recommend going higher than a minute on the Wait, just in case you forget to remove one before putting your process into production.

Call this process from your main process for debugging purposes with the Wait To Complete radio button selected. Don't forget to take them out. I tend to set the Notes of my steps with something like ZZZ or DEBUG that's easy to find using the IPA search capabilities.

Since I wanted to look at some Work Item variables, from Process Automation Monitor, I made new Process-level variables that start with TEMP. I do this so I remember to delete them before production to use less resources with the process.

The nice thing is, after you've had a chance to inspect your process-level variables in PAM, you can Cancel the Waiting process and your other process will continue on it's merry way.

It ain't rocket science, and you might argue it's barely computer science, but hey, it works for me, at least until SU5.

Got any debugging or troubleshooting tips and tricks? Please share in the comments. PLEASE! Pretty please...?

As always,

Happy Processing!