Multiple Content Types
Public folders let users store multiple content types in the same folder hierarchy
and, in some cases, the same folder. For example, a team can share a set of
public folders that store the team calendar, contacts, and project information.
The project folder could contain Microsoft Office Project documents, Microsoft
Word documents, Microsoft Excel spreadsheets, and email messages. However, public
folders are limited in that certain disparate message classes—such as
an appointment, a contact, and a mail message—cannot coexist in a single
folder.
WSS 3.0 introduces the concept of content types. A content type describes the
characteristics of an item in SharePoint, including its properties, workflows,
associated document template, and information management policies. For example,
you can define a budget content type that has a budget template, a specific
set of custom properties, and an approval workflow associated with it. When
a user creates an item of that budget content type, he or she creates a budget
document from the template, populates the required properties, and saves the
document, triggering an approval workflow. SharePoint supports the storage of
multiple content types within the same container. SharePoint content types are
managed and updated from a central location and can be deployed across an organization
to quickly roll out updates to forms or document templates.
The content types assigned to a SharePoint container are available from the
container's main menu, making it easy for a user to create an item of a specific
type. Together, SharePoint's content-type functionality and the ability to email-enable
SharePoint containers provide a repository from which you can initiate a specific
workflow or information management policy.
Security
From Outlook, the public folder owner can apply role-based permissions to public
folders, granting read, write, and delete access. Using the Exchange Folder
Visible permission, you can specify which users see the presence of the folder.
This is an important feature from a usability standpoint: It's frustrating to
click a folder only to receive an access denied message. Public folder permissions
are set on a folder level. If users have access to a folder, they automatically
have access to all nonfolder items within that folder. This is where SharePoint
has an advantage over Exchange—you can apply role-based security at the
item level, letting users see only the items to which they have access, as Figure
1 shows. Although Exchange public folder permissions don't map to SharePoint
permissions, you can use the same AD mail-enabled security groups to apply security
to both environments. Surprisingly, SharePoint lacks the ability to restrict
the creation of subfolders, a security feature many organizations would like
to have, and which public folders do offer.
Document Repository
Public folders are a convenient way to share documents that don't change. But
because they lack document management functionality, such as version control
and conflict resolution, public folders aren't well suited to sharing dynamic
content often generated by team collaboration.
WSS 3.0 provides basic document management features, such as major and minor
versioning, check-in/checkout, document profiles, workflow, and auditing. MOSS
2007 adds an additional layer of document management capabilities by providing
features such as Web content management and publishing, records management,
and policy management.
Deleted-Item retention
If you delete a public folder item, and you have full read, write, and delete
permissions on the folder, you can use Exchange's deleted item retention feature
to recover the content. You configure the Exchange server for deleted item retention,
including the length of the retention period, which is when item recovery has
to occur.
WSS 3.0 has a two-stage recycle bin, which Figure
2 shows. Each site within a site collection has a recycle bin that's accessible
to end users. When users navigate to the site recycle bin, they receive a personalized
view of the content they've deleted from the site, referred to as the end-user
recycle bin, from which they can recover their deleted content. The second level
of deleted-item retention occurs at the site-collection level; the administrator
has access to this site-collection recycle bin. This bin tracks content deleted
from all sites within the site collection, including content currently listed
in the end-user recycle bins. When a user empties the end-user recycle bin,
the deleted content disappears from that bin but remains in the site-collection
recycle bin. The administrator can change the view of the site-collection recycle
bin to display only items that have been deleted from the end-user recycle bin,
providing a convenient way to retrieve content for a user. The retention period
for items in the recycle bin defaults to 30 days; the administrator can also
configure this value.
Extensibility
Some companies have embraced the extensibility of public folders by building
applications that leverage custom forms, event sinks, and the workflow engine.
Exchange provides the ability to create a custom form and associate it with
a public folder. Exchange Web forms, available in Exchange 2003 and Exchange
2000, provide a mechanism for building custom Web pages that override the default
Microsoft Outlook Web Access (OWA) public folder rendering, in case you want
a custom version for your users. However, Exchange Web Forms have been removed
from Exchange 2007. If you require this capability, Microsoft recommends that
you use ASP.NET to extract data from Exchange 2007 and render it for Webbased
clients.
Exchange 2003 and Exchange 2000 support an event architecture that lets your
code trigger when items are saved, modified, deleted, moved, or copied within
the Information Store (IS). For example, to send an email notification when
a user posts a document to a public folder, you register your code in the public
folder to be executed when a save event occurs. Exchange supports synchronous
and asynchronous events. Synchronous events let you modify an item before a
specific action, such as save or delete, is completed. Asynchronous events let
you modify an item after the action is completed.
Exchange 2003 and Exchange 2000 provide a workflow engine that uses event sinks
to determine the state of an item involved in a workflow process. Additionally,
Exchange 2003 and Exchange 2000 include a scripting technology, Collaboration
Data Objects for Workflow (CDOWF), which provides tools for writing and managing
Exchange workflows. However, Exchange 2007 doesn't ship with a workflow engine
or CDOWF. Microsoft recommends that existing applications based on public folders
be left in place on Exchange 2003 servers. Customers who want to migrate their
servers to Exchange 2007 should consider porting their Exchange workflow applications
to Windows Workflow Foundation. Workflow Foundation is part of Microsoft .NET
Framework 3.0 and will be included in Windows Server 2008 (formerly codenamed
Longhorn Server). Workflow Foundation provides a runtime engine, a base activity
library, and designing tools that run in Microsoft Visual Studio 2005. Companies
that have used the more complex features of Exchange and built sophisticated
public folder applications should scrutinize the WSS 3.0 and MOSS 2007 feature
set to determine whether migration is even an option.
MOSS 2007 offers InfoPath Forms
Services, which lets you build XML-based
forms and integrate them into your business processes. InfoPath Forms Services
provides a server-based runtime environment for Microsoft Office InfoPath
2007 Forms and lets users complete
Web-enabled forms by using a browser
or an HTML-enabled mobile device. Webenabled forms remove the requirement
for the user to install client components in
order to update forms.
SharePoint provides a set of synchronous and asynchronous events that you can
integrate with lists, document libraries, sites, and even user operations. Workflow
Foundation is at the heart of the MOSS 2007 workflow functionality. MOSS 2007
comes with a set of predefined workflow templates for common workflows, such
as approval routing and issue tracking. MOSS 2007 workflows can be associated
with a document library, list, or content type and can be authored by using
the browser, Microsoft Office SharePoint Designer, or VS 2005 and Workflow Foundation.
Additionally, MOSS 2007 workflows can leverage InfoPath forms and support Office
2007 client integration, letting you approve a workflow within an Office application
such as Outlook.
)
The_Craigster July 17, 2007 (Article Rating: