Add Google Analytics Tracking to Dynamics CRM Install - google-analytics

I'd like to add Google Analytics tracking script to all page loads in Dynamics CRM - so I can track and analyze how people work in the app and find pain-points with our processes.
I modified the tracking script to pull the userID (GUID) and entity ID (GUID) and put them into custom dimensions. I expect to use that to determine the user viewing the site, form name, entity name, etc. in my reports. I also set it up to
However, our developer says the best way to do this is to manually add the script to every entity (or something like that - but it's a manual thing done to every single entity). I feel like it's a web page... so it should be able to just have some javascript in the header like anything else.
Is there a better way? Any ideas? I don't want it to be hacky - this is for a production/enterprise system... Obviously I'm not very familiar with Dynamics in this light... Just looking for some ideas.

Assuming that the script is a piece of JavaScript you want to run on page load. Then adding the script to every page isn't just the best way to do this, but the only supported way to do this. Microsoft make available a number of ways to extend and customise CRM, unfortunately they don't just allow you to do anything you like.
So whilst CRM is just a bunch of web pages, they aren't your web pages to edit freely. Microsoft provide a number of extensible points but direct editing of the DOM isn't one of them.
I suppose a good simile here is that StackOverflow allow me to type any answer I like, but then don't allow me to change the font. Whilst this is a web page I can edit, it's not my web page.
That all said its worth bearing in mind what supported actually means. Something which is unsupported typically means:
What you want to do probably won't work easily.
If you do get it to work, the next update of CRM will probably break it.
Microsoft might not feel so obliged to help when it does break.
You may find Supported extensions for Microsoft Dynamics CRM useful.
In terms of what you do to make this work:
You could try hacking open the installed server files to find somewhere to add your script. However I would advise against this as its not supported (I advise against anything unsupported).
Your you can write the script once in a web resource, and use on every page. The only duplication required is to add the event handlers to each form, which is relatively quick for a single form.
Your users probably aren't using every page (and you can't add script to every page anyway, only forms) so just target the pages you need rather than trying to get 100% coverage.
CRM has a set of meta data web services you can use to create fields and entities. Perhaps you could use it to perform form edits and automate the process.
If you are looking to analyse system performance then perhaps adding form script isn't the best way to do it anyway. Tracking client form interactions only really scratches the surface of CRM usage anyway. What about plugins, workflows, data base, and web services which all execute server side but affect client performance?
Perhaps broaden your searches to include topics such as CRM monitoring, optimization and management. For example; Optimizing and Maintaining Client Performance for Microsoft Dynamics CRM 2011 and Microsoft Dynamics CRM Online.

Related

Can Microsoft OCS be embedded into an asp.net web page. How long should it take?

I have been told that Microsoft OCS is a bit like Windows Messenger.
Can it be added to a web page by inserting and configuring some standard code so we end up with something like this:
I know there is an OCS API but I don’t want to spend days piecing an OCS app together from this.
I was hoping there would be a component that allows me to stick the whole app on a web page and configure it to operate correctly. I presume this is something that would take less than 2 days if it is possible. Can someone advise if this is about right for an experienced developer?
I understand the web page would need to be in an Intranet with Active Directory.
Sort of a yes and no answer, this... There is no simple way to embed the entire client in a web page, but you can embed the important stuff - a list of contacts with their presence, and the Click-to-Call functionality. This approach relies on the end users having Communicator, Office and IE installed.
See my answer about NameCtrl here. There's a bit of javascript and state tracking involved if you're displaying more than one contact, so 2 days feels about right.
It's worth bearing in mind that this will work if the web page itself determines which list of contacts to show. If the contact list instead needs to be pulled from the user's Communicator, this isn't supported for web pages (some parts of the Communicator API are marked as NotScriptable for security reasons). You'll need to use the Office Communicator Automation API, and create a .net COM Interop wrapper around it. I've detailed a workaround to that here (this example discusses Silverlight, but it should be the same for javascript). I'd give this another couple of days on top of the original 2.
It's also worth bearing in mind that this approach will work with OCS, and will continue to work if the customer upgrades to Lync Server 2010. If they are already on Lync Server 2010, then the simpler approach is to use the Silverlight controls. Probably only a day for this approach.

Using Sitecore solely as a content data provider

We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.

Providing SaaS functionality to a .NET portal with DLLs

I'm not sure I'm asking the right question here, but I'm looking to provide web based functionality from one ASP.NET application to another remote 'portal-like' application. Is it possible to simply give the portal a DLL? As an example, let's say the SaaS web app has a patient-entry form that I want to be able to use from the portal application. I would like the portal app to be able to set preferences (permissions, color, style, etc), make a function call, and have that capability presented within a certain div or something. Is there any .NET technologies that provide this kind of integration?
EDIT:
Here is a link to a quick diagram I made trying to describe the scenario: http://img.ly/ESG. I know there are other ways of doing this (eg JSON-P calls), but I need to give the portal developers something they can control on their end. Also, if anything changes they'll know I will send them a new version of the DLL which will indicate to them the new functionality.
I'll give you a shopping list of things to check out:
DotNetNuke:
http://www.dotnetnuke.com/
Workflow Foundation -
http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
Microsoft SAAS platform -
http://www.microsoft.com/serviceproviders/saas/default.mspx
Depending on exactly what you're looking for, you might also research "multitenancy".
To answer your original question, yes, you can do it with DLL's, but there are easier ways to do it.

ASP.NET Application Suite Development - Gotchas

This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.
Some things we are focusing on right now:
1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account.
2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc.
3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.
I would appreciate any advice from any architects out there that have built similar systems from the ground up.
I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)
Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!
Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.
I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.
Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.
The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).
Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.
If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.
Also, they said it works with Linq2SQL and the entity fraimwork.
So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.
Here is a link to a demo (not the one I saw.)
Some general thoughts. If you'd like me to expound on any of these, let me know.
Inheriting from a custom subclass of
Page instead of Page itself is a
great way to share functionality
across your site.
Nested MasterPages are good.
Charting: I've tried DevExpress,
Syncfusion, and MSChart control and
all have their own issues.
The built-in forms authentication is
pretty good. Building a site that
allows both integrated authentication
and forms authentication is tricky
but can be done.
I've tried using cross page postbacks
and I'm still not sure if I like
them.
Localization takes a lot of time
Come up with a good structure for your App_Themes and css.
Use Elmah to track unhandled exceptions

Architecture for Reporting Web Site

I've alluded to this project before, in this question, but the scope of redesign has been slightly tightened, i.e. I can't redesign the whole thing, so I 'd like some general advice on how to structure the existing artefacts in the application as an incremental step in improving the design.
The site has two areas of functionality, v.i.z. reporting and maintenance. This is the major function of the site, not data manipulation, but just presentation. The site includes a small number of maintenance pages that use standard GridViews and FormViews for maintaining a small area of data. This is why I have decided against a rich, complex DAL in favour of the Enterprise Library DAAB and plain vanilla datasets.
Each report is an isolated page that uses results of a dynamic SQL query to explicitly render HTML table rows for the report. In order to not maintain one set of queries for both mySQL and MSSQL for each report, I will move all data access to stored procedures, removing coupling to either DB engine through the DAAB.
I am looking at reporting tools to decouple the report structure definition from the report presentation. I would prefer to not define report structure in classes, as telerik reporting does, but have yet to look at other reporting tools.
All reports share a common filter page that is presented on choosing a report from a menu, which redirects to the chosen report once the user is happy with their filter selections. Is there any guidance available for this very common scenario that I seem to have to keep reinventing?
I am looking for general advice on how to move this toward a better structured product, without actually restructuring the whole project. Simple stuff like separating maintenance pages from report pages in sub-directories, etc.
I'm not looking for others to do my work, and will in due course have implemented many improvements of my own making, but I would appreciate general opinions on how other people would handle a project like this.
For presentation of reports based upon a database of facts I would investigate one of the tools that has got all the core functionality already implemented, such as BIRT (and I am sure that there are some .NET alternatives). You might think a table of data is good enough for an intelligent person to parse, but down the line someone will ask for graphs and PDFs.
The maintenance / admin pages can be a standard website - forms and backend, using whatever framework you are comfortable with.
Architecturally wise, are you going to be running the reports against a live database, or an archive database (or the failover/replication DB)?
Are you generating aggregate data tables (fact tables) to generate reports from, or running against the more complex main schema?
I'm going to go with a management system for metadata on reports, with a simple directory structure for a page-per-report system, using the DevExpress ASPxGridView. This grid is more than capable of meeting the reporting needs of this application.
I'll be implementing maintenance and admin as standard web forms, with a shared filter form for most reports, dynamically configured based on report metadata. There will be no runtime maintenance of reports, as adding a report requires adding a page. This is acceptable as maintenance will be infrequent.

Resources