Project Description
CRM 4 Queue Manager written in C#.
Based on the original VB.Net CRM Queue Manager with some changes, additions and feature changes.
Converts emails to CRM cases by querying Exchange directly instead of relying on the Exchange Router component.

Introduction
This project is basically a rip-off of the original CRM Queue Manager, but luckily that project was licensed under the GPL, so it's all good :)

What does this application do?
The application runs as a service and queries one or more Exchange mailboxes for new emails. When a new email is found, a new email entity is created in CRM based on the received email, assigns the email to a specific queue in CRM and marks the email as read.

The email is then converted into an incident in CRM and, depending on settings, sends the original sender of the email a confirmation as well as a ticket number and notifies the relevant people that a new incident has been created.

If a contact with the same email address as the sender exists in CRM, the incident is associated with the contact. If a contact does not exist, a new contact is created.

Additionally, if an email is received that contains a reference to an existing incident, the email is automatically associated with the existing incident and an update is sent to the owner of the incident.

Why?
Why not use the standard CRM Email Router?

We had a few unique requirements that were not catered for in the standard router. The main problem we had was that emails from multiple addresses had to end up in the same queue, i.e. support@company.com and helpme@company.com both had to end up in the same queue. We couldn't find an elegant/easy way of accomplishing this with the standard router.

Secondly, a few of the mailboxes from which incidents have to be created are "open" mailboxes, meaning that there are no spam filters on the mailboxes. I won't go into the reasons for this, but suffice to say that in order to cut down on the amount of unnecessary emails and cases that get created by the standard router, we had to stop those emails from getting into the system by filtering them out before they got created.

Lastly, we needed more information from the emails which was not being provided by the standard router. Specifically, we needed to get the headers of an email as well as some routing information on the email itself. This was, once again, not available on the standard router.

The application has been written in such a way that, if you want to continue using the standard router, all you need to do is flip a config entry from true to false and the entire Exchange functionality won't execute. The conversion functionality will then still be able to pick up emails in queues and convert them to incidents.

Some history and an explanation of available features
The reason why the project was rewritten in C# had to do with an internal (company) requirement that all supported software had to be written in C#. Additionally there were a few superfluous pieces of code in the existing project, requirements that were not catered for and some refactoring that needed to be done on the original project.

These requirements resulted in the extension of the Queue Manager by writing a custom email router to poll Exchange mailboxes for specific queues. Sending of mail from CRM is still accomplished via the standard email router, but all incoming mail is handled by the Queue Manager.

The environment in which this project was deployed has very high throughput with more than 30 configured queues, which meant that a few optimizations had to be made. This resulted a lot of pre-loading of Exchange objects as well as CRM entities and various attempts to streamline the existing code.

The high load on the environment caused all sorts of issues, chief of which was the fact that we often experienced deadlocks on the database. What this meant for the Queue Manager was that when specific errors were reported by the CRM web service, it had to retry the specific action a specified number of times. The error handling and committing of transactions to CRM was accordingly centralized and measures put in place to try to handle as many of the errors as could reasonably be expected.

Due to the nature of the deployment, extra measures had to be put in place to cater for spam and to allow administrators to update spam filters at runtime. To this end, globally applicable files were created that contain email addresses to be ignored as well as words in the subject of emails that have to be ignored. An upcoming enhancement not included in this release is an administrative tool which allows users to make these changes without having to edit files.

Users also requested the ability to download all attachments as a single zip file, so a zip containing all the attachments is also created when the email is created in CRM.

This installation also had to cater for multiple support agents, which meant that follow-up emails from customers needed to be brought to a specific agent’s attention. Thus the option to notify the owner of an incident when an update arrives was added.

Lastly, the logging of the project was updated quite extensively due to the need for traceability of incoming mail and stability. The Microsoft Enterprise Library was used to provide logging, which means that the logging is very customizable for administrators.

Not included with the initial release are the unit tests written for the project, mainly due to the fact that they’re not 100% complete and are environment specific. This should be rectified in a later release.

Some of the features that were removed from the original Queue Manager include:
*Parent Account Matching
*Website that provided for validation/verification of customers
*Online Support
*Temporary Queue support – emails are ignored rather than moved to a temp queue due to volumes

There are still some sections of code which haven't been optimized properly after the VB.Net to C# conversion and some sections that need to be refactored, but overall the code seems to hang together nicely.

Installation
A MSI package has been created that should install everything you need to run the application.
The QueueManagerService.exe.config file needs to be updated with valid entries before starting the service.
Logging by default is written to the ~installation directory~\logs and is by default set to be quite verbose. You're welcome to change this, but it does provide a good overview of exactly what the service is doing if you don't feel like looking at the code.
The templates in ~installation directory~\templates should be updated in whatever fashion you feel as they're pretty drab at the moment.
The service can run anywhere, as long as it has access to the CRM and Exchange web services specified in the config.

For developers
The project compiles the CRM web service into DLLs (using csc.exe and sgen.exe). This is done to speed up instantiation of the CRM Web service (see this excellent article: url:http://uwekaessner.spaces.live.com/blog/cns!21916E8556D908E!175.entry ). The post build events of the various projects create the necessary DLLs. There is thus no reference to a specific CRM web service in the projects. This means that if you have customized CRM and need to access custom properties you created or custom entities, you would have to update the Service.cs files in the relevant projects by ripping out the code in the autogenerated Reference.cs when adding a web reference and replace the code in the Service.cs files according to the instructions in the above article.

Finally
Even though this project is, to a large extent, based on the ideas of the original Queue Manager, it is very different on both a code as well as an architectural level. My apologies if you feel that the project diverges too sharply from the original or don't like the fact that certain features were cut. At least in this way you can add them yourself in C# :)

Last edited May 17, 2010 at 12:08 PM by sluiper, version 8