18 March 2010

MOSS development tips

(Originally posted 19 February 2009).

Other than the classic (and largely non-technical) project concerns of scope management, configuration management etc. there are key challenges to a MOSS deployment. The process for moving the MOSS solution between environments, for example, is more complex than other .NET projects. This is due to the way MOSS separates configuration, content and code. The process is also heavily dependent upon the environments being used. Implementing changes to Production post go-live are particularly challenging as of course you need to retain content. Generally, the process is routinely underspecified. A document explains the steps involved here.

A general lack of adherence to a MOSS centric methodology other than general MSFT best practices causes developer confusion. The key MSFT document here is – “SharePoint Products and Technologies Customization Policy 2007”. This is intended to be a framework for organisations providing MOSS platforms. Organisations should also use this list as a starting point to verify the quality of solutions that are submitted for deployment. Along with providing a check after a solution has been developed, the code acceptance checklist can make a good training tool. The steps required to plan, design and deploy MOSS projects are defined here. A governance plan is recommended as a means of gaining early support from key stakeholders across organizations. It forces consensus and designates ownership for numerous key deployment considerations for governance and for information architecture. Tracing and error logging support are required reading for MOSS developers.

Reporting is generally required from MOSS applications. The method used to write them is typically C#.NET against the MOSS object model. IT departments are generally aware of SSRS and like its OOB functional abilities e.g. export to PDF/Excel, publish to MOSS, tie to workflow and non-specialist skills required. They find it difficult to understand why MOSS reporting is not so straight-forward.

MSFT wording here has been relaxed around use of SSRS against MOSS and now it may be prudent to copy relevant MOSS tables or database to a reporting database periodically and query directly against that. The decision to do this requires explicit KT and consultation with the IT department e.g. MSFT are more likely to change the DB schema than the object model therefore any reports written against the DB schema could be rendered unusable with future SPs or releases. It will generally be less problematic however than the alternative.

No comments:

Post a Comment