Lync CWEs – a Technical Introduction
Microsoft Lync CWEs – Conversation Window Extensions – are one of the key tools in the Lync developer’s toolkit, but when and how you can use them takes a little bit of understanding.
make sure you check out my latest CWE project: a free Information Dashboard!
What are they?
At its simplest, a CWE is just a webpage browser, part of the Lync client and displayed to the user as a extension of their chat window. There’s no chrome (no windows, buttons, menus etc.) but content is rendered the same as in Internet Explorer, and some shortcut keys, such as Alt+arrow continue to work.
You can load whatever you want in a CWE, as long as you think it will render. For instance, I could choose to show this site as a CWE:
As a user, I can open this anytime I want to using the More Options ellipses in the bottom-right corner of the chat window.
There’s two advantages CWEs have over regular webpages though, which really open up possibilities for developers:
- CWEs can be invoked from code to open on a client’s machine automatically
- CWEs can communicate with the Lync system, to read information about the Lync session, or to send information to other applications
Let’s take each of these and break them down.
CWEs can be invoked from code to open on a client’s machine automatically
As an application developer, creating applications using either the Lync Client SDK or UCMA, when your application is in conversation with a user, you can “invoke” a CWE to appear on their client. You do this by sending a special code through to the client (which the user doesn’t see), which pops open the window. This is useful if, for instance, your application is telling the user about a recent sales order – it would be useful to open a webpage showing the order and related information.
As you might imagine, there are some security prerequisites to this (wecan’t have people opening windows everywhere on other people’s machines – this isn’t the 90’s!), but if you’ve prepared the way you can create some really nice experiences for your user this way, by giving them rich additional content to support whatever other information you were providing them.
CWEs can communicate with the Lync system, to read information about the Lync session, or to send information to other applications
As well as just opening the CWEs, there’s a clever way your application can communicate with Lync, which opens up a number of exciting possibilities.
The CWE window supports the use of Silverlight. As part of the Lync Client SDK, Microsoft provide Silverlight DLLs for Lync development. This means that you can write a Silverlight application which uses the Lync DLLs and which therefore can talk to Lync.
Why would you want to do this? Well, to take the sales example from earlier, rather than just showing a webpage with sales data, you might want to write a Silverlight application which showed the data, but targeted for the user that was looking at it. You might also want to show the Lync presence of other key people involved in the sale, making it easy for the user to contact them. You can also integrate the process of contacting people deep within your application, making it more intuitive – the user doesn’t feel like they are switching over to Lync to call someone, they’re doing it from within your application.
Microsoft have released a load of Silverlight controls which you can embed into your CWE applications. There’s an example on MSDN of adding a ContactCard into a Silverlight application to display contact information. Or, if you want to write your own, just grab a reference to the Lync client in code and have a play – the Intellisense is a good way of discovering what you can do. Start with:
Other applications can also talk to your CWE, via the Context Channel. This is a like a hidden pipe through which applications can trade data. If you’ve written an application in UCMA which contacts a user and opens a CWE, then the UCMA application and the CWE application talk to each other, without the client being aware. This unlocks some pretty powerful abilities, as it makes your CWE webpage or Silverlight application “come alive” by being able to react to events. An example would be a chess game, where you play against the computer (a UCMA application). The application would open a CWE window with a Silverlight application containing a chess board. When you make a move, this is sent over the context channel to the UCMA application. When the UCMA application has worked out its next move, it sends that back over the context channel, and the CWE application updates. of course, this communication could also be between two CWE clients, or between multiple CWE clients and a UCMA application etc. There’s a really nice code sample on MSDN showing how to send and receive context. It’s written for Lync 2010, but it should work fine in 2013: Using Lync Controls to Send Contextual Data.
CWEs can perform powerful functions, such as opening on remote command, and sending data silently, so there are some tight rules about how they operate. I think this is why people find them confusing – it’s often not clear why they don’t work – but it’s usually security related! First, in order for any CWE to be opened, either by the user locally, or by an application remotely, it must be registered. This is done via a registry entry. The registry entry contains the name of the application, its URL and a unique GUID to identify it. This must be in place before you attempt to open a CWE on a user’s machine via code. The command to open a CWE doesn’t take the name, or the URL of the CWE – it takes the unique GUID. This is then sent to the client. If the client recognises it in the registry, then it opens the stored value of the URL. If it doesn’t recognise it, you see the “Context is not support” error in the Lync client. This means that the client doesn’t have a match for the GUID you’ve just sent it. The registry settings are keyed by the GUID of your application, and contain a friendly name, a size, and two URLs – for internal and external access. This allows you to specify an intranet URL if you want to serve a different version of the application to internal users (versus those that arrive via your Edge Server):
If opening a URL is all you want to do, then you don’t need to do any more work. However, if your application needs to establish communication with the Lync client (using the Silverlight DLLs) then the application also needs to be trusted. In Lync 2013, this means adding the domain the site is running at into a special registry key, the Lync Trusted Sites key. (in Lync 2010, this key didn’t exist – sites had to be trusted in Internet Explorer by placing them into the Trusted Zone). If you fail to do this, when your application first tries to use the Lync DLL, you’ll receive a Client Not Trusted Exception:
(for more on trusted sites, see blog post here.)
CWEs are a great way for developers to extend the functionality of Lync to their users. Microsoft have done a good job of providing controls and tools to allow applications to communicate with the Lync client and react to events. They can also send data to other CWEs or to applications running UCMA, which allows for a powerfully integrated solution. Because of their power, there are some fidlly security rules to work with, but once you understand these, and what you need to do to satisfy them, you can be up and running creating CWEs to extend Lync in no time!