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!