Category: Uncategorized

Sarbanes-Oxley Act : Business Prevention Act

~ chriseyre2000 ~ Leave a comment
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

~ chriseyre2000 ~ Leave a comment
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

~ chriseyre2000 ~ Leave a comment
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!

Code Access Security and OLEDB

~ chriseyre2000 ~ Leave a comment
Microsoft have devised a very sophisticated security model for .NET applications to allow fine grained control of permissions.  In theory you can grant an application just the permissions that it needs.

OleDbPermission Class is a good example of how well this has been implemented in practice.

Quote:

This class is intended for future use when the .NET Framework Data Provider for OLE DB is enabled for partial trust scenarios. The .NET Framework Data Provider for OLE DB currently requires FullTrust permission. Currently, using the OleDbPermission class has no effect. For more information, see Code Access Security and ADO.NET.

This is the documentation for the 1.1, 2, 3 and 3.5 frameworks.
This would imply that there is no priority to getting this fixed.

This is a rather key ommision as this is the key component for accessing non-microsoft databases from, say Sharepoint.
I found this while trying to get the BDC to read data from a Sybase database via OLEDB.
At the time of writing (using Sharepoint 2007 which is the latest released version of the product) the tool support for the BDC is sadly lacking.  The tools that have been released do not cope with the OleDb option and the error results are far from impressive.  In order to prove that the problem is in the BDC and not a missing driver I have written a small web part that calls Syabase via OleDb using a connection string.  On my dev box (which I did not know was set to be permissive) this works just fine.  On a UAT environment (natuarlly locked down) the same web part fails.  It would appear that I need to give the web part full trust to allow me to call the database!

Sharepoint Documentation Speaks With A Forked Tongue

~ chriseyre2000 ~ Leave a comment
The sharepoint documentation is a trap!
There are so many errors, ommisions and inconsistencies in the Sharepoint documentation that you have to resort to direct experimentation to get even the simplest task to work.

Currently I am trying to add a simple web part to a Sharepoint site.  This should be easy.
The documentation claims that you can freely choose to use either ASP.NET web parts or Sharepoint web  parts (both randomly abbreviated to web parts).  Once you get through all of the wierd hurdles required to get a web part to install into sharepoint (Add the manifest file with the correct syntax noting that there are several flavours of manifest files).

There is a lot of cargo cult programming going on with this product (such as rename cab files to dwp before installing them – which is not required).

Once I got a classic asp.net web part installed I was kindly informed by the web page editor that my web part may not be put into a web part zone.

Sharepoint and the BDC

~ chriseyre2000 ~ Leave a comment
The expensive version of Sharepoint comes with the Business Data Catalog.
This is a means of describing sql commands, stored produres and web services in such a way that Sharepoint can call them to obtain required data.

It is advised not to attempt to use Sharepoint as a high volume transactional system.
The problem is that I need to feed Sharepoint from such a system.

Use of the BDC is ideal for real time lookups of small amounts of data via direct calls.
For static data the use of web services is ideal as you can use the webserver to cache the data that will not change intra day.
However if you have large lists of data you don’t want the transactional system to be hammered with big queries.
As a result we are using a “service” application (OK it’s a GUI – but it could be a service) to update a status table and then push the data into a sharepoint list. This list will then trigger workflows.

I would have liked to use a MSMQ for this but apparently this will not work with our multiple redundant server farm.

Sharepoint – writing to a sharepoint list.

~ chriseyre2000 ~ Leave a comment
I have started to work with Sharepoint.  This is microsofts portal/integrated search platform.

It requires W2k3 server or higher to run it (and it must be installed to allow you to code against).  This means that most devlopment is performed using virtual pc’s (which is painful).

Some of the documentation is wrong. The bold line was missing from the following:

                using (SPSite oSiteCollection = new SPSite(SiteName()))

                {

                    Debug.WriteLine(oSiteCollection.ToString());

                    using (SPWeb oWebsiteRoot = oSiteCollection.OpenWeb(CoreWebName()))

                    {

                        oWebsiteRoot.AllowUnsafeUpdates = true;

                        SPList oList = oWebsiteRoot.Lists[RawMessageList()];     // Get this from a config file

 

                        SPListItem oListItem = oList.Items.Add();

                        oListItem[“Title”] = Reference;

                        oListItem[“Created”] = DateTime.Now;

                        oListItem[“Modified”] = DateTime.Now;

                        oListItem[“Author”] = AuthorId(); 

                        oListItem[“Editor”] = AuthorId(); 

 

                        oListItem[“MsgType”] = MsgType;

                        oListItem[“Reference”] = Reference;

                        oListItem[“MsgBody”] = MsgBody;

 

                        oListItem.Update();

                    }

                }

This meant that the webservice that I was writing to populate a list was failing with

The security validation for this page is invalid.

I found this article that pointed me in the correct direction.

I am using webservices to abstract the list population so that I can have applications that are not dependent upon Sharepoint yet still can still work with sharepoint.  This will allow them to be tested on any dev machine, not just our Sharepoint farm.