So What Can I Do With An Interaction Client Add-In?

Before we dig too deep into Add-Ins for the Interaction Client, it would be useful to cover the functionality that Add-Ins expose. Leave a comment and let me know which of these you’d like me to explore first in a future post. Each topic is followed by a list of relevant classes or interfaces, to help if you want to explore on your own.

  • Tracing (ITraceContext)
    • Write messages out to the InteractionClient log file for post-mortem debugging.
  • Desktop Alerts, or “toast windows” (INotificationService)
    • Display a custom message in an alert window
  • Making Calls (ICallService)
    • Create a new outbound call interaction
  • Watch* an interaction (IInteractionService, IWatchedInteraction)
    • Example: make a call using ICallService and then watch the resulting interaction for updates, or set attributes, etc.
  • Watch* the My Interactions queue (QueueMonitor, IQueueService, IQueue, IInteraction)
    • Get notified about all the interactions on the current user’s “My Interactions” queue.
  • Implement a custom screen pop (ScreenPop, IScreenPop, IScreenPopService)
    • When configured in Interaction Administrator (and/or Interaction Attendant) this custom code will be loaded and executed at just the right moment.
  • Add a custom tab (“window”) to the client UI (AddInWindow, IWindow, IWindowManager)

    * “Watching” something means that you can query information about the item and be notified about events occurring for that item.

    I also wanted to go over a few “Add-In Best Practices.” So since I have to have a heading for everything…

    Add-In Best Practices

    Use the built-in helper classes if at all possible.

    The Add-In API was designed to afford a great deal of flexibility. The base interface, IAddIn, is the entry point to the rest of the supported Add-In functionality. But for many common scenarios, it can be annoying to set everything up just so you can start working on the parts you care about. For that reason, we’ve focused on a few common scenarios and introduced abstract base classes that help take away the “goo” you have to write and let you focus on the tasks you want to accomplish. At the time of this writing, these include AddInWindow, QueueMonitor, and ScreenPop. (With an honorable mention to NotificationServiceUtility which provides handy default values when using the INotificationService interface.)

    Be mindful of the “UI” thread

    Windows applications that show a user interface follow a simple (yet seemingly difficult) pattern: only access controls from the same thread they were created on. (Get more information about that here.) Typically (though not exclusively) there is only one thread in an application that creates controls. The Interaction Client is a typical application in this regard. Add-Ins are purposefully instantiated on the “UI” thread to provide an opportunity to capture the SynchronizationContext. If you’re doing processor-, network-, or disk-intensive operations you should capture the original SynchronizationContext and then delegate those expensive operations to a background thread using the .NET Framework’s built-in thread pool, using the captured SynchronizationContext to marshal execution back to the UI thread when finished, if necessary.

    The danger is that your custom Add-In can have negative side effects on the start-up time of the Interaction Client, or worse, it could hang or crash depending on what your code is doing.

    Beware of Modal Dialogs

    An application like the Interaction Client has to be careful in it’s design. If a modal dialog is shown above the main interface, it can make it impossible (or annoying, or difficult) to pick up the call or interaction without first closing the dialog. This can involve lost work, etc, and should be avoided. If you display a custom pop-up window with your Add-In, work hard to make it modeless. (Modeless means that you can interact with other windows in the application without closing the primary one.) This takes more effort in development, but it is well worth it to end users.

    That’s it for best practices for now, I’ll be sure to point out more as we go along. Remember to leave a comment with what you’d like to see covered next!

    Cheers.