Sharepoint Warning

I have been investigating creating custom content types in Sharepoint and basing lists off of them.
I have been working with the feature xml documents.

There is an insideous bug that you need to be aware of: the name and the guid for a custom field must both be unique.
If you reuse the name of a field when creating a custom type then when the type is activated the duplicate field will be silently dropped – no warnings or errors.  This took me a day to track down – I was wondering why the view that I built on a list was missing some columns. When I checked these were thecolumns that I had used in an earlier prototype.

There is another catch – you may need to recycle the app pool between un-registering and re-registering features.  Sharepoint seems to prefer to use the cached values rather than the newly supplied ones.

The above was exasperated by the substandard documentation supplied with the product.  While there is lots to read, it is incomplete and contains errors.

It appears that Sharepoint 2007 was realeased too soon – the internal design is not consistent (three styles of guid are required to register a content type!), the error handling is patchy – varies from excellent (exactly which field is incorrect) to vague (a field is wrong somewhere).

Perfect Storm 1.0

I have finally released the initial version of perfect storm.

This may be found here.

Tricks this has:

  • Creation of multiple outputs from a single model.
  • Custom xslt string functions to change case to Pascal, Camel, upper, lower
  • User specified “variables” may be inserted into the output.

Abuse of ConfiguationSettings (Ultimate config section).

This article gives a useful hint on how to implement your own configuration setting in a generic manner.

However I think that I have refined the technique.
What I always wanted was direct read only XML access to the config section.

The following gives exactly what I want:

    public class XmlNodeConfigSection : IConfigurationSectionHandler
    {
        public object Create(
             object parent,
             object configContext,
             System.Xml.XmlNode section)
        {
            return section;
        }
    }

When registered as follows in app.config:

section name=”mysection” type=”mynamespace.XmlNodeConfigSection, myassembly”

Allows the following to return an XmlNode:

(XmlNode)ConfigurationManager.GetSection(“mysection”);

This will be null if the requested section does not exist.

You are free to use XPath expressions (&c) to get at the data!

Sharepoint Thoughts

Sharepoint looks to be a very useful platform to develop on.

It has a large amount of internal consistency problems:

The object model uses different names for the webs of the application to the user.
Documentation is patchy – terminology that you are told to avoid is part of the object model.
Negatively named attributes.

The object model can be inconsistent: why does adding a list return a guid whilst adding a site returns the new site?

The built in web services are kind of functional but I would always recommend defining your own:

  • They will not break on upgrade (or at least the interface won’t change)
  • They have a defined interface rather than requiring large blocks of CAML

Web Service change in .NET 2

It has come to my attention (during a sharepoint course) that there has been a small change in the .NET 2.0 implementation of web services.

Async methods now come as an event hander (for the end) and a method for the start.
This is much easier to use that the .NET 1.1 version.

Sarbanes-Oxley Act : Business Prevention Act

Here is a forum for the discussion of the SOX act.

The SOX act was passed after the Enron scandal (a year before this happened I interviewed with them).
The point of it is to make the cheif executive of a company directly responsible for the correct financial reporting of everything that goes on in their company.  This act has real teeth – CEO’s are now more afraid of failing a SOX complaince audit than actually carrying out their business!

My problem is not with the act itself (it does not even mention IT in the text of the act) but with the interpriation being put upon it by the consulancies that have taken on the role of advisors and auditiors.  You have trained accountants coming fresh to an IT environment and without understanding what they are doing demanding radical changes (asking that developers be denied access to version control software!).  The senior management are so afraid of failing that audit that they take what the consultants say at face value.

Back in the early 90’s there was a scam going around the ISO 9000 audits.  ISO 9000 basically consists of having a company document their procedures and demonstrate that they are following them. The idea was that companies could use this process to understand their own business and make improvements.  However like most things it can be subverted by empire builders to increase their influence and status.

 The following text would be a complete (although effectively useless) procedure:

This company does whatever is needed and requires no records to be kept (other than required by external requirements).

The ISO 9000 scam was how do you deal with the ISO 9000 complaince of your suppliers.  All you really needed was some process for checking what had been supplied.  Several consulatancies twisted this into that all suppliers in the supply chain must alkso be ISO 9000 accredited.  This meant that all of your business partners also needed consulatants creating more work for the ISO 9000 industry.

Sox and IT

The basic idea of the sox compliance is that “sox compliant applications” (to qualify you must handle money or equivalent) must have certain controls in place:

  • Any change to the system must be authorised by a business user.
  • Developers of a system must not have access to the production system (the part missed is if they do they must fully log all changes made so that they can be approved by a manager).
  • All data changes to the production system must be audited.

In theory these are sound principles and could be implemented at a sufficiently large company.
You could have distinct teams of development, implementation and support.

The problem is that the auditors are applying this as a one size fits all solution to all sox applications.

Large companies can afford to do this.

What happens when you have a small team that both develops and supports an application.
The auditors are insisting that all developers be denied even read access to production databases.
This means in the case of a data fix (which will happen from time to time) a developer will have to create a script and then pass it to someone (who has no special knowledge of the system) to run.  The developer would have to create this without any possible testing!  How is this possibly in the best interests of the company.  For systems that operate 24×6 the poor guys with database access (who will be shared across multiple applications) will be on call at any time of the day to run scripts that developers will supply them.  The room for errors is huge.  What if the problem crosses multiple systems.  The poor support engineer will have scripts being sent from each system and is having to run the correct (posibly untested) script on each system.  This is just asking for trouble.

The SOX act is being used to comprimise the effectiveness of in house development teams!

Web Service Limitations

For the first time in a while I have started to write a web service for a real world problem.
Effectively I have some data that I need to write to a remote database that I don’t want to grant direct access to.
(The “database” is actually a Sharepoint list).

I found that out of the box web services allow you to define the call interface in a simple manner.
This is easy – one parameter per field. It even accepts nullable types.

The problem comes when you getr to strings. There does not seem to be a sensible way of declaring the maximum expected length of the string. This does make ensuring that the caller is passing the correct values difficult. For now I resulted to comments.

This
is an article on adding (limited) validation to an ASP.NET web service.

Someone needs to explain to people that business rules are more than attribute level validation!

Buisness Rules include:

  • Field level validation
  • Entity level validation (including compound entities)
  • Defaults
  • Calculations
  • Creation and updating of Business entities (for example routing rules to create delivery instructions)

Business rules can be context specific – the rules that apply to one object in one state may not apply to another.

For example given a User object and rules around change password you may have several sets of rules.

However the rules for an administrator to change a password are different to those for the current user.
The administrator should not know the prior password, where as the user in question should.
This means that if you want to use the same user object for both scenarios you cannot simply use C# attributes to mark up the fields as mandatory!  Rules must exist externally to the object and be applied.

Sharepoint Articles

I have been rearching sharepoint recently and have found a large number of useful articles.

This covers writing custom editors for sharepoint webparts.

This covers connectable ASP.NET web parts.

This is a MSDN article on customising Sharepoint.

This is a MSDN article on Sharepoint and Code Access Security.

This is an article on Web Part security and access to the Sharepoint Object model.

This is a MSDN article on Code Access Security and ASP.NET.

This is a suite of third party controls that should work in Sharepart Web Parts.  $1000 per dev per year.

This is a MSDN Article on writing Web Parts for Sharepoint.

This is a MSDN article on A Developer’s Introduction to Web Parts. Note it may be a little dated as it was written for Sharepoint 2007.

This is a link to sharepoint web part templates for Visual Studio.NET.  This requires sharepoint to be installed.  However as Sharepoint 2007 prefers you to use Sharepoint Web Parts rather than ASP.NET web parts this is not a problem.

This is an article that compares and contrasts the two types of Web Part.

Hopefully some of these will be of use!