In this blog I would explain about how to create a publishing template in MOSS 2007.
Basically a sharepoint page layout comprises content fields and site columns which forms a page layout. First create the content types and then the site columns.
With the help of SPD 2007 open the site and start customizing the aspx page. The layout page is uploaded in the Master Gallery and Page Layouts in sharepoint.
Customize the page using SPD 2007 and then publish the page. Use the site columns created in the SPD for placing the controls as per the requirement. Drag and drop the controls accordingly in the page. Make sure that you give proper name to your page and the content type from which it should be inherited is mapped correctly. Once the page layout is designed completely,publish it.Fill up the details in the page and submit...See your new page layout....I will attach the snapshots as well in the later posts...
Monday, November 2, 2009
Monday, August 31, 2009
Blob Caching mechanism in MOSS 2007
I came across a blog by Steven Gobner where he mentioned about the blob caching mechanism in MOSS 2007. Just check the web.config file for entry
Blob caching allows caching of binary objects like images, style sheets and documents on the MOSS front end server machine which heavily reduces the traffic to the SQL backend server as each file has to be downloaded only once to the blob cache per frontend server.
The benefit is that although the items are now retrieved from the MOSS 2007 frontend server the same security and versioning capabilities exist as if the file would only live in the SQL backend database. The blob cache mechanism also ensures that an item in the cache is invalided as soon as the file changes in the backend database. So that is different from other file caches like proxy servers and browser caches.
To enable blob caching you need to modify only one line in the web.config file:
Just change the false in the enabled attribute to true and update the location attribute to point to a location where sufficient disk space is available. For best performance ensure to set the maxSize attribute to a value that is at least as big as all binary objects in your Web Application.
You can control which file types are cached by modifying the file extension list in the path attribute.
Responsible for the processing of the disk caching logic is the following entry in HttpModules section of the web.config file:
This HttpModule implements the required logic that decides whether a file can be served from the disk cache or if it has to be retrieved from the backend database.
Important to know is that even that this HttpModule is located in the WCM Publishing namespace you its functionality is not limited to publishing sites. Other site collection types like team sites can also use this functionality.
Limitations of Blob Caching
1) Blob caching does not support web gardening
One major limitation is that blob caching should not be used with web gardening. The reason is that each process requires exclusive access to it's instance of the blob cache. That means that only one worker process can access a single instance of the blob cache. Web Gardening means that multiple worker processes serve content for the same application pool. Only the first process of a web garden will then benefit from blob caching which would mean that web gardening would cause negative impact on the overall performance.
2) Blob caching cannot be used with host named site collections
The blob caching engine uses the server relative path to decide if an item in the cache belongs to a URL or not. With host named site collections an additional criteria come into play: the "host" http header. The blob cache engine on the other hand is not aware about host named site collections. That means if you have two site collections with items that have the same server relative URL (e.g. items in the style library) but are different the item that was first hit gets cached and served for all other host named site collections as well.
3) A cached item is only available in one frontend server
The blob cache is a per server cache. That means if an item has been cached on server 1 and the next request for the same item hits server 2 then the item has to downloaded again to the second frontend server. That means the load on a SQL backend server can be higher in the startup phase if multiple frontend servers exist as the same item might have to be downloaded multiple times to the different frontend servers.
I found this blog interesting and thought of sharing to you all.
Blob caching allows caching of binary objects like images, style sheets and documents on the MOSS front end server machine which heavily reduces the traffic to the SQL backend server as each file has to be downloaded only once to the blob cache per frontend server.
The benefit is that although the items are now retrieved from the MOSS 2007 frontend server the same security and versioning capabilities exist as if the file would only live in the SQL backend database. The blob cache mechanism also ensures that an item in the cache is invalided as soon as the file changes in the backend database. So that is different from other file caches like proxy servers and browser caches.
To enable blob caching you need to modify only one line in the web.config file:
Just change the false in the enabled attribute to true and update the location attribute to point to a location where sufficient disk space is available. For best performance ensure to set the maxSize attribute to a value that is at least as big as all binary objects in your Web Application.
You can control which file types are cached by modifying the file extension list in the path attribute.
Responsible for the processing of the disk caching logic is the following entry in HttpModules section of the web.config file:
This HttpModule implements the required logic that decides whether a file can be served from the disk cache or if it has to be retrieved from the backend database.
Important to know is that even that this HttpModule is located in the WCM Publishing namespace you its functionality is not limited to publishing sites. Other site collection types like team sites can also use this functionality.
Limitations of Blob Caching
1) Blob caching does not support web gardening
One major limitation is that blob caching should not be used with web gardening. The reason is that each process requires exclusive access to it's instance of the blob cache. That means that only one worker process can access a single instance of the blob cache. Web Gardening means that multiple worker processes serve content for the same application pool. Only the first process of a web garden will then benefit from blob caching which would mean that web gardening would cause negative impact on the overall performance.
2) Blob caching cannot be used with host named site collections
The blob caching engine uses the server relative path to decide if an item in the cache belongs to a URL or not. With host named site collections an additional criteria come into play: the "host" http header. The blob cache engine on the other hand is not aware about host named site collections. That means if you have two site collections with items that have the same server relative URL (e.g. items in the style library) but are different the item that was first hit gets cached and served for all other host named site collections as well.
3) A cached item is only available in one frontend server
The blob cache is a per server cache. That means if an item has been cached on server 1 and the next request for the same item hits server 2 then the item has to downloaded again to the second frontend server. That means the load on a SQL backend server can be higher in the startup phase if multiple frontend servers exist as the same item might have to be downloaded multiple times to the different frontend servers.
I found this blog interesting and thought of sharing to you all.
Friday, August 21, 2009
Features--- a component for deployment
Let me talk something on features... playing a very good role in Microsoft Office Sharepoint Server. It is a building block for creating sharepoint solutions. Its a unit of design,implementation and deployment. It mainly contains two xml files such as
1.Features.xml
2.Elements.xml
Feature are activated\deactivated at different levels such as
Farm level
Web application level
Site Collection level
Site level
1.Features.xml
2.Elements.xml
Feature are activated\deactivated at different levels such as
Farm level
Web application level
Site Collection level
Site level
Thursday, August 20, 2009
In MOSS 2007 we have two main things and they are
1.Administrative part
2.WSS object model for customizing the sharepoint pages
With administrative previleges one can create(delete) and many more operations. Specially for the customization of sharepoint pages we use Windows Sharepoint Services 3.0 object model.
In the front end web server we have virtual directory which has different folders created under the path as c:\program files\common files\microsoft shared\web server extensions\12\bin known as system directory. Under the system directory inside the bin folder we have stsadm.exe which is a command line utility for creating new site collections and used for activating and deactivating the features. Features provide a mechanism for defining site elements and adding them to a target site or site collection through a process known as "feature activation".
1.Administrative part
2.WSS object model for customizing the sharepoint pages
With administrative previleges one can create(delete) and many more operations. Specially for the customization of sharepoint pages we use Windows Sharepoint Services 3.0 object model.
In the front end web server we have virtual directory which has different folders created under the path as c:\program files\common files\microsoft shared\web server extensions\12\bin known as system directory. Under the system directory inside the bin folder we have stsadm.exe which is a command line utility for creating new site collections and used for activating and deactivating the features. Features provide a mechanism for defining site elements and adding them to a target site or site collection through a process known as "feature activation".
Wednesday, August 19, 2009
Shared Service Provider and Search Database
We have one SSP per farm. SSP is a repository for the data store such as
People Profile
Audience Data
Business Application Data(such as SAP,Siebel etc)
BI Methods
Site Usage data
Infopath Form Services Session state information
Search Database: Each SSP will enable search services per farm.
one search database is created for each SSP
This database doesn't need to be backed up
The Search DB serves as the data store for the following
History Log
Search Data
Search Log
People Profile
Audience Data
Business Application Data(such as SAP,Siebel etc)
BI Methods
Site Usage data
Infopath Form Services Session state information
Search Database: Each SSP will enable search services per farm.
one search database is created for each SSP
This database doesn't need to be backed up
The Search DB serves as the data store for the following
History Log
Search Data
Search Log
About MOSS 2007 Database Administration
Where the data lives??
There are two db's which are associated here:
1.Configuration Database
2.Content Database
Configuration Database:MOSS creates the configuration database during the installation itself.
The configDB servers as a data store for the following:
There are two db's which are associated here:
1.Configuration Database
2.Content Database
Configuration Database:MOSS creates the configuration database during the installation itself.
The configDB servers as a data store for the following:
- Sites
- Databases
- Servers
- Virtual Servers
Content Database: Content DB serves as a central repository for storing all the contents specific to a site.It stores the data related to the Site Collection such as
site details
site structure
User Content
Files
Security Information
Used in WSS 3.0
Avoid enumerating through the SPListItemCollection object as each step will invoke a sparate call to a content database.
Code Snippet:
string siteURL="http://chem.agilent.com";
using (SPSite site=new SPSite(siteURL);
{
using(SPWeb web=site.OpenWeb());
{
SPList tasksList=web.Lists["Tasks"];
DataTable dt=tasksList.Items.GetDataTable();
foreach(DataRow dr in dt.Rows)
{
//Code
}
}
Code Snippet:
string siteURL="http://chem.agilent.com";
using (SPSite site=new SPSite(siteURL);
{
using(SPWeb web=site.OpenWeb());
{
SPList tasksList=web.Lists["Tasks"];
DataTable dt=tasksList.Items.GetDataTable();
foreach(DataRow dr in dt.Rows)
{
//Code
}
}
Welcome
Welcome you all in my blog where in I will share my sharepoint knowledge....So lets collaborate together to learn something new :)-
Subscribe to:
Posts (Atom)