Thursday, December 20, 2012

IPA Best Practices from a Recent Internal Session at ININ

I had the good fortune recently to present a topic during an internal session at ININ on Interaction Process Automation. These aren't the best formatted notes you'll ever see, but if you've built a process in IPA, or at least seen the Process Automation Designer, I figured I'd just get'em out there as food for thought.

Suffice to say this little event was the largest gathering to date of folks who have IPA implementation experience. There's already a few who have more than a year or two experience, which ain't bad considering the product's initial release was in 2009. Some great ideas and best practices were shared.

My topic was the Work Items Sprint, and in an upcoming post, I'll expand on that concept into the design and implementation phase, tying everything together using complex data types that are auto-generated by IPA if you use the database tools (40SU2 and later). I've done this with the latest process I'm developing and find it extremely effective and efficient.

Configuration and Implementation

Consider storing IC-server specific information in an external configuration location, such as an IC Server Parameter, and use variables in your IPA process to reference the data. A perfect example is a workgroup name. If you hardcode your workgroup name into your process and import that process into another IC server, if that workgroup hasn't already been created in IA on that server, your process will go into error immediately, plus you'll have to change every occurrence of the workgroup name. Structured Parameters in IA can be exported and imported, making this process easy and efficient, plus you can later change the workgroup name in IA and not have to touch your process. This is especially important for people considering building Templates for the MarketPlace.

Work Items Sprint

After As-Is, To-Be and the Work Items mock ups have been signed off, go build the work items immediately and then demo them for the customer. Sprint is an agile concept and is described in more detail in the Benefits of a Work Items Sprint with IPA post. No logic is needed and just use process-level variables (preface them with something like TEMP so you can clean up and push them down into work items later). Sprint is an agile concept and is described in more detail in the Benefits of a Work Items Sprint with IPA post.

Troubleshooting

Consider adding an "i" icon button for information to each page of your work items. Keep track of a process-level string that is constantly updating what has happened in the process. Think of this as Process History, the IPA version of Call Details when you right-click on a call in the Interaction Client. This way you don't have to jump into PAM to look at stuff or start with logs. If you're keeping good track of Process History, you can simply click on the information button in your process and see how you got there. Use a var to keep track of where you came from when you press the "i" button and Destination conditions for each page and the "i" page so you can reuse the page on each work item.

Error handling for Web Services and to a lesser extent for Handlers

Instead of simply letting the process crap out and have to jump to PAM to start troubleshooting, handle them in the process flow. By default for the Call Web Services Operation and Run Handler tools, the Errors and Timeouts tab will have Stop the process (refer to Process Monitor) selected. Change these to Handle the timeout/error in the process flow. This presupposes you will also have return values in your handlers and web services that indicate whether or not the operation succeeded, because you'll have to add process logic to evaluate those return codes. If you get an error, do a Parallel Split - keep the work item with the user encountering the error and launch a separate error handling process. Once you've determined if you can restart the process or retry the process, then the user can continue.

Many thanks to Geoff Calhoun, the new product manager for IPA and content management at ININ. We'll see about getting a few words from him at some point in the future as well.

In the meantime...

Happy Holidays and Happy Processing!

Friday, December 7, 2012

When Not to Put a Business Rule in IPA


Oh Great Masses (well, soon to be masses) of Interaction Process Automators, Beware of Ye Olde Scope Creep! Interaction Process Automation is great for providing workflow between multiple applications. In order to try to deploy rapidly and start getting ROI, try to resist tailoring your process for every single use and error case that can occur.

Example: A process I'm working on currently will pull data from a 3rd party CRM system that houses customer information via web services. IPA isn't a CRM (more on that another time) and it isn't replacing the CRM solution. IPA will automate a process for annotating some customer survey data and collecting internal feedback between various departments in the company.

The business analyst with the customer made an astute decision that data would need to be more or less cleaned up in the CRM before launching the process. Could IPA have been made to provide additional functionality to reclassify and update the data while the process was mid-flight? Sure. Did it make sense to do it here? Not no, but hell no! The goal is to get the process published and get some ROI to the business, not stay in perpetual development.

And that's the challenge. IPA and CIC in general have an expansive set of tools to build a multitude of functionality but you must resist the urge to cover all of those use cases and errors that could possibly occur. Outlier cases can stay on the fringe.

In the above example, we're replacing a manual process that uses, you guessed it, spreadsheets and emails, one of the perfect business cases for IPA. The customer is going to get significant value from the process, even though we're not including a business rule to allow them to update all of their data.

Have any other suggestions of what not to include? Feel free to drop a comment or contact me.

Happy Processing!