Customer Care Framework 2009 sp1 QFE is released!
The CCF 2009 sp1 QFE was officially released and posted up on MSDN for folks that can download from there.
Their a number of updates in the QFE, You can read the summary here : https://blogs.msdn.com/ypitsch/archive/2009/08/25/ccf-2009-sp1-qfe.aspx
One of the most exciting bits in this release ( at least to me ) is the rollout of the Shell SDK for CCF. This SDK substantially simplifies the development and upkeep of applications developed for CCF, including allowing for the development of full WPF agent desktops.
Getting started with the Shell SDK in CCF is pretty simple, as part of the QFE package, 2 new sample implementations were provided that show a windows form desktop and a WFP desktop in use. They are a great place to start getting familiar with the new Shell SDK.
Folks that have built CCF desktops , or worked with them in the past you will notice a big difference between the Shell SDK and using the Core AIF API, I'm going to run though several of the key points here.
1) Core Desktop-
When building CCF desktops in the past, you have had to concern yourself with all sorts of things related to the CCF core support. Things like creating sessions, managing customer data in the context , CTI (computer telephony integration) manipulation and such. All of that work had to be done for each custom project because the business logic as interwoven to a degree with the way CCF rendered the desktop and worked with the components and hosted applications. Now, that capability didn't go away, in fact in some situations you need exactly that level of control to get the job done. You need a good deal of understanding of how the CCF desktop works in order to be effective here.
The Shell SDK changes this model, The Shell SDK is a layered SDK, built on AIF, that simplifies most of this work.. in comparison terms.. the Reference implementation of CCF 2009 sp1 ( including its support class’s ) have over 5K lines of code. Where as the sample implementation of the Windows Forms Desktop as part of the QFE samples has just over 750 lines of code, total and the WPF sample desktop has right around 420 lines of code.
You can see just from the line counts that something really changed, Where did all the extra stuff go?
That's where the Shell SDK comes in. The Shell SDK was built by fully separating the User Interface logic, the Rendering logic , and the plumbing of CCF from each other. This allows the Shell SDK to provide a unified support SDK to both windows forms and WPF based desktops… which means that if you learn the use of the Shell SDK, you can use it in a windows forms desktop or a WPF desktop without having to relearn the SDK.
Session Creation, Context Management, Customer Search, CTI management have all been moved into a compartmentalized model that allows you to manage them as host able elements of CCF rather than things that need to be thought about as you design the Desktop.
Another major feature here is that the Shell SDK provides a means to extend the desktop and add in your own specialized control interface to the CCF environment. For example, in working with Dynamics CRM, say you wanted one control to initialize the connection to the CRM API, then hand it to any other Hosted Control that needs to consume that connection, the Shell SDK makes that task simple and easy to do.
2) Sessions, Context and Search..
Context management and how Sessions are created was moved into a set of known interfaces that allow you to setup a search provider and a context manager and use them independently or pair them together. What does that really mean? well first off it means you can have multiple search providers running concurrently in the desktop shell. Second it means that you can associate each search provider to its own Context generator, So you can have 2 completely different entry points for create the initial session context.
How Sessions are created in the environment is also new, You no longer have direct access to the “AddSession” methods from the original CCF desktop code, however now you have an Interface that is used to identify a “Search Control”, that interface in turn allows you to raise a event called “CustomerSearchResult”. That event triggers the creation of a session in CCF.
Defining a customer, or data that describes what the session is all about has also changed. In the base AIF API, a Session is strongly typed customer object, in the Shell SDK the customer object is contained in a new class called “CcfCustomer”. The CcfCustomer class stores the customer data in a “object”, which can be consumed and cast into the correct customer data by a control that needs it. it also contains information regarding the search control that created it and the context object that is used to process it. The net of this is that we have a container to store customer data that can be used by controls that care, and ignored by controls that don't care.
You can take advantage of this a few different ways, let me outline one for you here..
Say you wanted to prepackage a search provider and lookup control set for your CRM solution ( in our case Dynamics CRM ). You can also package in the Context provider for that system, which means your prospective developer does not have to concern themselves with “how” the context is built. All they need to do is configure your controls into the CCF administration system and it “just works”.
Now, Say you also want to provide a custom search UI for another system, again you package all the bits together that you need, Configure it in CCF administration and it will appear, assuming you allow multiple search controls, in the desktop. When your end user uses the system, Searches that originate from a search control will go to the corresponding Context manager for processing.
Check out the Search Control example in the QFE Samples to see this in action.
3) CTI
The CTI system was pretty much completely rewritten for the QFE. Originally CTI was tightly bound to the Session logic and a known way of creating sessions, as well as specialized constructors for CTI adapters that wanted to process additional data.
In the Shell SDK, Much like the Search and Context Interfaces, A set of interfaces and prebuilt logic has been created to support CTI. There are a few key points to understand about the CTI System… First the term “CTI” in CCF applies to all types of channels. That means Voice, Chat, email, Video , SMS, whatever. Second, the CTI subsystem as all about call control for most call types, and includes media for things like Chat.
If your creating a CTI adapter, you now have a base class to support the “connector” which is what plugs into the CTI system itself. Business logic associated with the CTI system is implemented in a “desktop manager” that is paired up with the CTI solution. You also will extend a specific call state ( Call control ) manager and a Agent State Manager for the technology your using. The Core CTI system in CCF supports and encourages the idea that the connector layer should be separated from the BizLogic layer in the desktop. IE: if your using CTIVenderX version 4.0 and they update to version 5.1.2.333 then the only thing you need to touch ( most of the time :) ) is the connector.
Both the connector and the DesktopManager are also Hosted controls… so you can leverage the CCF System’s Role layer to allow you to load the appropriate CTI solution for whatever your agent needs Without having to change the code of the desktop or other components of the CCF desktop solution..
If your just writing a control to consume or visualize data from the CTI system, its as simple as consuming the CCF onboard CTI Consumer Interfaces, there are 2, one for call state and one for agent state, and then doing whatever you want. If you use the base types to build your component it will work across CTI vendors, or you can up cast the types to the Vendor specific ones and take advantage of any additional functionality you have added.
That's the Shell SDK in a nutshell :)
Lot of new and exciting stuff in there, plus a great way to start building out reusable components that can be “plugged In” to the Agent Desktop.