Lars Fløe Nielsen

Today I ran into a really strange problem. In fact it’s related to my post yesterday where I explained about problems you may run into when training developers. They tend to have very different configurations as well as different security settings.

Today I figured out what was wrong with one of the users. The symptoms were, - in her case:

1. Sitecore tree list field type did not do a drop down.
2. The XHTML editor did not perform. You could open it, but only sometimes view markup source, and never edit or submit the content.

In the HTML editor, sometimes I could navigate to the markup of the HTML field, and whenever this succeeded, I noticed that it contained some JavaScript code, which our application does not pass in the AJAX stream. Looking into the Script, I could see that all variables was prefixed with SYM. Immediately intrigued, I had to suspect Norton Internet Security as the culprit. I turned it off, and everything worked like a charm.

So, Googleing the topic “HttpRequest and Norton” I found that Norton interacts with XmlHttpRequests by inserting script that supposedly should secure your web page. But in this case, it’s not blocking anything malicious.

This is not the first time, this problem appears. According to the search requests it happens often for Norton Internet Security.

Unfortunately I have left the client now as I move to Bangkok tomorrow for another two days of meetings, but I did find a potential set of instructions for a potential fix. Read this set of instructions for removing Norton Internet Security’s ability to block XmlHttpRequests and try it. Comments are welcome.

Well, clock’s set to ring 5 tomorrow morning. No rest for the wicked.

 

Let’s recapitulate the challenge from my last post

We wanted to build a web based application for Sitecore that uses AJAX for emoting something between the task manager and the performance monitor; a customizable task manager.

The reason for creating a task manager / performance manager is two-fold: 

1. Sitecore allows asynchron processes to be executed as background threads. Indexing, publishing, reporting and other time consuming processes which runs at low priority. For this purpose, Sitecore leverages the access to these threads by a Job manager. The task manager should visually display the jobs being executed, and the status of these.
2. Solutions can be hosted or devoted or secure servers where access is limited. System administrators may want to use the web based interface to investigate performance monitors from their local machine through the web based interface.

Now, from an architectural point of view, how did I put together this piece of software?

First I thought it would be fairly easy; simply create an AJAX or native .NET application, then let it execute an update every, - say 3 seconds. It should request new tasks as well as getting the basic CPU usage.

But hey; we don’t want to update the entire grid of jobs on every single request. Also, why not make it possible for the user to add their customized performance counters to the usage load display. And then, why not at the same time, display it as a graph.

So, now I was down to a number of features that should be created:

A web based application that would, every X second through XJAX execute some code behind. The code behind would:

1. Read the Sitecore jobs and update a grid.
2. Process specific performance counters and
3. 1. Build an image.
   2. Return image.

Well, it wasn’t really that simple. First of all, I would need to build another AJAX application that allows users to select performance counters and return it to the first form to update another grid.

Allow user to select a performance counter on the grid and change the scale of the graph. Also, when selecting an item, it should be possible to se average value, last value, max value and min value of the selected counter.

So:

1. Build two applications: “Monitor” and “Select performance counter”.
2. Build job processor class
3. Build a task manager class that can read selected performance counters and update them as well as return specific stats.
4. Build a graph class that can receive data sets, and draw a line graph.

Well, I soon found out that by calling the task class every 3 second would result in two challenges which were mutually damaging:

1. First, a call every 3 second, and then a performance counter number would result in a rough graph with 3 seconds intervals.
2. Second, drawing a graph every 3 seconds would result in server load as drawing and file operations. This would be equivalent to having a performance counter affecting performance counts.

Above raises a major challenge with the current architecture. I cannot increase the number of requests to give a better, smoother graph as this would increase the number of graph paints and server load, and in the other hand I cannot decrease the server load.

But, as always, this can be solved. I did it by creating a performance counter collecting Sitecore job which would run as a background thread. It will be kept alive by a ping from the main monitor application every time I request a new graph. The job collects counters every second. Then every 5 second, I request a graph based on the data collected.

So, as simple as that:

• Create a background thread that can be configured from an application. Thread collects performance counters.
• Two XAML applications (that are compiled into .NET forms) which are AJAX based:
• • Monitor application
  • Get new counter application
• Graph class that can draw a class.

Interesting links:

• Sitecore images
• Task manager images

 

As most of you know, Sitecore is much more than just a CMS. In fact, it’s a framework for applications that supplies XAML, AJAX etc. either for customizations in Sitecore or for the web site you are building (same architecture, as Sitecore is built using Sitecore).

Now, why did we want to do this? Well, as everybody in the CMS world also knows, CMS is much more than just content contribution. You assign work flow, work with your file repository, use search, taxonomies, reporting etc. etc.

All of these could actually be considered separate applications, and this is why we did build a framework that gives content contributors as much recognition as possible. Most editors’ work with a windows based system, and we decided to build our framework so it resembles any windows based application (Linux shells or windows). We, for a start decided to skin our framework like Windows Vista. But it’s running in a Browser (IE OR Firefox).

Applications, in our framework, has the design of Microsoft Office 2007; again, because of the user interface experience, as well as because we wanted to show our very close integration to the entire MS Office 2007 package.

So what are we up with now?

A AJAX browser based (pure browser, no ActiveX or Java) application framework looking like Windows Vista, and applications (such as the Content Editor, - part of the CMS package), looking like Office 2007.

More Sitecore pictures on this link.

Our internal architecture is, I believe even more impressive. Everything in Sitecore is 100% event driven and most actions are even executing pipe lines. This means you can hook into either events, - cancel them or hook into pipe lines modifying the basic architecture of the software.

As Sitecore is built using Sitecore, you can also modify it.

Our workflow engine is really a state engine, which is 100% pluggable. Its architecture is just like Microsoft Windows Foundation, even though we did release ours years ago. This means that we can, if we wish, plug WWF right in!

We’ve even built a job engine where you can hook in your own jobs (or see the standard Sitecore jobs). For example, as Sitecore publishing (moving data from server to server) is running in a background thread as a Job.

So, what is crazy? I simply decided to build a task manager around our job engine, which also resembles any standard task manager. But on top of that, I also decided to build a full working performance monitor into our AJAX based web application.

More task manager pictures here on this link.

Remember… This is 100% AJAX driven web application. No ActiveX, no nothing…