Searching for something in the ASP.NET Membership model led me to this Scott Gu's post: ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security Resources
It's an old post but worth referencing.
It's a never ending ASP.NET 2.0 river of resources, it contains loads of links and references of resources for:
Authorization & Authentication models.
Membership, Roles, Profiles, Personalization & Providers.
Security guidelines and how-to's.
Tuesday, October 30, 2007
Sunday, July 8, 2007
ASP.NET Session State Brief
I'm writing this post to answer some people's questions about Session State storage, while this information is well known for many developers, some can find it useful. I'll try to brief things up.
Introduction
HTTP is a stateless protocol, meaning that a Web server treats each HTTP request for a page as an independent request; the server retains no knowledge of variable values used during previous requests.
What's a Session?
A session is a time limited, user (browser) specific, logical connection to a web application.
In other words, a server may treat subsequent requests, made from a specific browser/user, to web pages of the same web application, as logically placed under the same umbrella (session).
This way user specific variables or properly called Session specific variables can be stored somewhere, to be available for subsequent requests.
How requests can be identified to belong to a specific session?
When a user starts a new session, or the browser sends the first request to the web application, ASP.NET starts a new session and the SessionID for that session is sent to the browser with the response.
Then the ASP.NET would expect the SessionID to be sent back from the browser in the subsequent requests, to tie them all under the same session.
A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, then the session is considered expired. Requests made with an expired SessionID value result in a new session being started.
How is the SessionID maintained?
That's configurable in the web application, Session ID values are transmitted between the browser and the Web server in a cookie, or in the URL if cookieless sessions are specified, as shown in the following example.
http://www.anysite.com/s(lit3py55t21z5v55vlm25s55)/orderform.aspx
For the first option, it won't work if the user disables cookies in his browser.
For the second option, session will be lost if the user re-writes the URL, removing the SessionID.
Where is the Session State stored?
That's configurable in the web application too.
If enabled, Session State or Session Specific variables can be stored in the following locations:
- InProc: stores values in the memory of the ASP.NET worker process. It offers the fastest access to these values. However, the session data is lost when the ASP.NET worker process recycles or the IIS is restarted.
It's not appropriate for Server Farms, where more than one web server is used, since subsequent requests can be directed to different servers.
- StateServer: uses a stand-alone Microsoft Windows service (aspnet_state.exe) to store serialized session variables. This service may run on another machine, thus be shared among multiple web servers in a web farm.
This is somehow slower than the InProc mode, due to serialization and deserialization. Especially if run on a separate machine.
- SQLServer: although this is the slowest solution of all, this is used for highest reliability, since a failover clustering can be used. Serialization is used here as in the StateServer mode.
- Custom: stores session state data using a custom session state store provider. You must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. See Implementing a Session-State Store Provider for more details.
For Out-Of-Proc options (anything but the InProc):
- Make sure session variables are serializable. See KB 312112 for details.
- Using a web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details.
The following is an example of the configuration section written under [system.web] section:
[sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=[username];password=[strong password]" cookieless="false" timeout="20" /]
More on using the SQL Server option:
To install the session state database on SQL Server, run the Aspnet_regsql.exe tool located in the following folder on your web server:
[systemroot]\Microsoft.NET\Framework\versionNumber
Supply the following information with the command:
-The name of the SQL Server instance, using the -S option.
-The logon credentials for an account that has permission to create a database on SQL Server. Use the -E option to use the currently logged-on user, or use the -U option to specify a user ID along with the -P option to specify a password.
-The -ssadd command-line option to add the session state database
The Aspnet_regsql.exe tool will create a database named ASPState containing stored procedures called from the ASP.NET to save and retrieve session state to and from the database.
Session data itself is stored in the tempdb database by default, which might not be the best option, since tempdb is cleared when the SQL Server restarts.
You can optionally use the -sstype option to change the storage location of session data.
The following are the possible values of the -sstype option:
t data will be stored in the SQL Server tempdb database.
p data will be stored in the ASPState database instead of in the tempdb database.
c Stores session data in a custom database. You must also include the name of the custom database using the -d option.
For example, the following command creates a database named ASPState on a SQL Server instance named "SampleSqlServer" and specifies that session data is also stored in the ASPState database: aspnet_regsql.exe -S SampleSqlServer -E -ssadd -sstype p
P.S. this turned out to be anything but a brief article, isn't it?
References:
.NET Framework Developer's Guide: Session State
ASP.NET: Session State Overview
Nothin' but ASP.NET: ASP.NET Session State
ASP.NET: Session-State Modes
.NET Framework General Reference: sessionStateElement
INFO: ASP.NET State Management Overview
Peter A. Bromberg: ASP.NET Session State FAQ
ASP.NET Technical Articles: Session State Providers
ASP.NET: Securing Session State
Introduction
HTTP is a stateless protocol, meaning that a Web server treats each HTTP request for a page as an independent request; the server retains no knowledge of variable values used during previous requests.
What's a Session?
A session is a time limited, user (browser) specific, logical connection to a web application.
In other words, a server may treat subsequent requests, made from a specific browser/user, to web pages of the same web application, as logically placed under the same umbrella (session).
This way user specific variables or properly called Session specific variables can be stored somewhere, to be available for subsequent requests.
How requests can be identified to belong to a specific session?
When a user starts a new session, or the browser sends the first request to the web application, ASP.NET starts a new session and the SessionID for that session is sent to the browser with the response.
Then the ASP.NET would expect the SessionID to be sent back from the browser in the subsequent requests, to tie them all under the same session.
A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, then the session is considered expired. Requests made with an expired SessionID value result in a new session being started.
How is the SessionID maintained?
That's configurable in the web application, Session ID values are transmitted between the browser and the Web server in a cookie, or in the URL if cookieless sessions are specified, as shown in the following example.
http://www.anysite.com/s(lit3py55t21z5v55vlm25s55)/orderform.aspx
For the first option, it won't work if the user disables cookies in his browser.
For the second option, session will be lost if the user re-writes the URL, removing the SessionID.
Where is the Session State stored?
That's configurable in the web application too.
If enabled, Session State or Session Specific variables can be stored in the following locations:
- InProc: stores values in the memory of the ASP.NET worker process. It offers the fastest access to these values. However, the session data is lost when the ASP.NET worker process recycles or the IIS is restarted.
It's not appropriate for Server Farms, where more than one web server is used, since subsequent requests can be directed to different servers.
- StateServer: uses a stand-alone Microsoft Windows service (aspnet_state.exe) to store serialized session variables. This service may run on another machine, thus be shared among multiple web servers in a web farm.
This is somehow slower than the InProc mode, due to serialization and deserialization. Especially if run on a separate machine.
- SQLServer: although this is the slowest solution of all, this is used for highest reliability, since a failover clustering can be used. Serialization is used here as in the StateServer mode.
- Custom: stores session state data using a custom session state store provider. You must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. See Implementing a Session-State Store Provider for more details.
For Out-Of-Proc options (anything but the InProc):
- Make sure session variables are serializable. See KB 312112 for details.
- Using a web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details.
The following is an example of the configuration section written under [system.web] section:
[sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=[username];password=[strong password]" cookieless="false" timeout="20" /]
More on using the SQL Server option:
To install the session state database on SQL Server, run the Aspnet_regsql.exe tool located in the following folder on your web server:
[systemroot]\Microsoft.NET\Framework\versionNumber
Supply the following information with the command:
-The name of the SQL Server instance, using the -S option.
-The logon credentials for an account that has permission to create a database on SQL Server. Use the -E option to use the currently logged-on user, or use the -U option to specify a user ID along with the -P option to specify a password.
-The -ssadd command-line option to add the session state database
The Aspnet_regsql.exe tool will create a database named ASPState containing stored procedures called from the ASP.NET to save and retrieve session state to and from the database.
Session data itself is stored in the tempdb database by default, which might not be the best option, since tempdb is cleared when the SQL Server restarts.
You can optionally use the -sstype option to change the storage location of session data.
The following are the possible values of the -sstype option:
t data will be stored in the SQL Server tempdb database.
p data will be stored in the ASPState database instead of in the tempdb database.
c Stores session data in a custom database. You must also include the name of the custom database using the -d option.
For example, the following command creates a database named ASPState on a SQL Server instance named "SampleSqlServer" and specifies that session data is also stored in the ASPState database: aspnet_regsql.exe -S SampleSqlServer -E -ssadd -sstype p
P.S. this turned out to be anything but a brief article, isn't it?
References:
.NET Framework Developer's Guide: Session State
ASP.NET: Session State Overview
Nothin' but ASP.NET: ASP.NET Session State
ASP.NET: Session-State Modes
.NET Framework General Reference: sessionState
INFO: ASP.NET State Management Overview
Peter A. Bromberg: ASP.NET Session State FAQ
ASP.NET Technical Articles: Session State Providers
ASP.NET: Securing Session State
Sunday, June 24, 2007
Deploying Crystal Reports - Visual Studio 2005
As you already might know, a free version of Crystal Reports is installed/bundled with Visual Studio 2005.
Now to deploy an application that uses Crystal Reports, the resources on the internet suggests using one of the following methods to deploy the Crystal Reports redistributable package.
1- Using Crystal Reports for .NET Framework 2.0 Windows Installer:
Which I failed to find online, even on the Business Objects online downloads section, but doing a complete search for "CR*.msi" on my hard disk, I managed to find it on the following path:
[Microsoft Visual Studio 8 Install Folder]\SDK\v2.0\BootStrapper\Packages\CrystalReports\CRRedist2005_x86.msi
2- Using Merge Modules:
For which you should create a setup project for your application and in there, you should right-click the setup project node in the Solution Explorer, and select "Add Merge Module", and browse to the following path:
[Windows Root Drive]\Program Files\Common Files\Merge Modules\CrystalReportsRedist2005_x86.msm
This most probably won't be found on your machine!!
I wonder why this merge module wasn't installed with Crystal Reports.
So what you need to do is to go to the Business Objects download site, download this file and put it where it should have been put (in the above path).
Now build your setup project, and Crystal Reports run-times will be installed with your application.
Now to deploy an application that uses Crystal Reports, the resources on the internet suggests using one of the following methods to deploy the Crystal Reports redistributable package.
1- Using Crystal Reports for .NET Framework 2.0 Windows Installer:
Which I failed to find online, even on the Business Objects online downloads section, but doing a complete search for "CR*.msi" on my hard disk, I managed to find it on the following path:
[Microsoft Visual Studio 8 Install Folder]\SDK\v2.0\BootStrapper\Packages\CrystalReports\CRRedist2005_x86.msi
2- Using Merge Modules:
For which you should create a setup project for your application and in there, you should right-click the setup project node in the Solution Explorer, and select "Add Merge Module", and browse to the following path:
[Windows Root Drive]\Program Files\Common Files\Merge Modules\CrystalReportsRedist2005_x86.msm
This most probably won't be found on your machine!!
I wonder why this merge module wasn't installed with Crystal Reports.
So what you need to do is to go to the Business Objects download site, download this file and put it where it should have been put (in the above path).
Now build your setup project, and Crystal Reports run-times will be installed with your application.
Wednesday, June 13, 2007
ODP.NET & LLBLGen Pro
Using LLBLGen Pro as your Data Access solution for an Oracle Database, you either have to use Microsoft's Provider For Oracle, or Oracle Data Provider for .NET (aka ODP.NET).
And both of them work on top of Oracle Client. So an Oracle Client is needed for any of the above providers, which is installed automatically when you install the ODP.NET.
Many .NET developers favors the ODP.NET over the MS provider, especially those with a long track dealing with Oracle database. Because the MS provider has some limitations (lacking the support of some Oracle Native DataTypes, eg. XMLType).
Using LLBLGen Pro with the ODP.NET:
When you build the code generated by LLBLGen Pro on the Development machine, it references the Oracle.DataAccess.dll version found on your machine.
(Oracle.DataAccess.dll is the Oracle Data Provider assembly)
Also it's worth noting that the "SD.LLBLGen.Pro.DQE.OracleX.NET20.dll" the Dynamic Query Engine shipped with LLBLGen Pro, and referenced in the generated code, was built against a specific version of the Oracle.DataAccess.dll (eg. SD.LLBLGen.Pro.DQE.Oracle10g.NET20.dll was built against Oracle.DataAccess.dll v.9.2.0.401 as far as I can remember).
This shouldn't cause any problems in most of the cases, since installing the ODP.NET installs some Publisher Policy files that redirect calls to older versions of the Oracle.DataAccess.dll to the newer installed version.
I said most of the cases because some older versions of the ODP.NET missed those publisher policy files. If this is the case you may include the assembly redirections into your app.config /web.config file, which should look like the following:
Note: Assembly redirection can work the other way around, you can re-direct calls to a new version of the Oracel.DataAccess to an older installed version.
ODP.NET Versioning Schema:
It's worth mentioning here that Oracle have changed the ODP.NET / Oracle.DataAccess versioning schema.
Starting with 10.2.0.2, Oracle Data Provider for .NET ships with two sets of binaries; one set for .NET Framework 1.x and another for .NET Framework 2.0.
For example, if the ODP.NET product version number is 10.2.0.2.10, the correspondingODP.NET assembly versions are:
■ .NET Framework 1.x version: 1.102.2.10
■ .NET Framework 2.0 version: 2.102.2.10
Note that the Oracle installer and documentation still refer to the ODP.NET product version number and not the assembly/DLL version number. As with the .NET Framework system libraries, the first digit of the assembly version number indicates the version of the .NET Framework to use with an ODP.NET assembly. Publisher Policy DLL is provided as before so that applications built with older version of ODP.NET are redirected to the newer ODP.NET assembly.
The Problems:
Problems can rise when you deploy your application on a machine with a different version of the ODP.NET, then you might see the following exception:
Could not load file or assembly 'Oracle.DataAccess, Version=x.x.x.x, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified.
This should be solved by a correct assembly redirection. (From the version you see in the exception to the version already installed).
Another exception you might see is:
The Provider is not compatible with the version of the Oracle Client.
An assembly re-direction should solve this issue, too. This shows up when you have different version of the Oracle.DataAccess.dll in your machine check the Global Assembly Cash (GAC).
Due to older installations or so, while only one of them is corresponding to the latest installed version of the ODP.NET, yet your application references an older one. The first exception won't show up, since your application can find the dll, thanks to the GAC, but it's not the one that should be used.
Just to make sure which ODP.NET version is installed on your machine, check the following registry path HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ODP.NET
In most of the cases the assembly re-direction are the answers.
In some rare cases after getting rid of the re-directions issue you might see the following exception:
Unable to cast object of type 'Oracle.DataAccess.Client.OracleConnection' to type 'Oracle.DataAccess.Client.OracleConnection'
Pretty weird!!
This can be caused by some calls to the Oracle.DataAccess.dll inside the SD.LLBLGen.Pro.DQE.OracleX.NET20.dll which were not successfully re-directed to the installed version.
To solve this issue you will have to re-build the DQE dll to reference the same version of the Oracle.DataAccess.dll found on your development machine.
Details can be found in this post:
http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=9007&StartAtMessage=0즃
And both of them work on top of Oracle Client. So an Oracle Client is needed for any of the above providers, which is installed automatically when you install the ODP.NET.
Many .NET developers favors the ODP.NET over the MS provider, especially those with a long track dealing with Oracle database. Because the MS provider has some limitations (lacking the support of some Oracle Native DataTypes, eg. XMLType).
Using LLBLGen Pro with the ODP.NET:
When you build the code generated by LLBLGen Pro on the Development machine, it references the Oracle.DataAccess.dll version found on your machine.
(Oracle.DataAccess.dll is the Oracle Data Provider assembly)
Also it's worth noting that the "SD.LLBLGen.Pro.DQE.OracleX.NET20.dll" the Dynamic Query Engine shipped with LLBLGen Pro, and referenced in the generated code, was built against a specific version of the Oracle.DataAccess.dll (eg. SD.LLBLGen.Pro.DQE.Oracle10g.NET20.dll was built against Oracle.DataAccess.dll v.9.2.0.401 as far as I can remember).
This shouldn't cause any problems in most of the cases, since installing the ODP.NET installs some Publisher Policy files that redirect calls to older versions of the Oracle.DataAccess.dll to the newer installed version.
I said most of the cases because some older versions of the ODP.NET missed those publisher policy files. If this is the case you may include the assembly redirections into your app.config /web.config file, which should look like the following:
[configuration](Replace the square brackets with the triangular ones used for xml.)
[runtime]
[assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"]
[dependentAssembly]
[assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/]
[bindingRedirect oldVersion="9.2.0.20-9.2.0.420" newVersion="9.2.0.700"/]
[/dependentAssembly]
[/assemblyBinding]
[/runtime]
[/configuration]
Note: Assembly redirection can work the other way around, you can re-direct calls to a new version of the Oracel.DataAccess to an older installed version.
ODP.NET Versioning Schema:
It's worth mentioning here that Oracle have changed the ODP.NET / Oracle.DataAccess versioning schema.
Starting with 10.2.0.2, Oracle Data Provider for .NET ships with two sets of binaries; one set for .NET Framework 1.x and another for .NET Framework 2.0.
For example, if the ODP.NET product version number is 10.2.0.2.10, the correspondingODP.NET assembly versions are:
■ .NET Framework 1.x version: 1.102.2.10
■ .NET Framework 2.0 version: 2.102.2.10
Note that the Oracle installer and documentation still refer to the ODP.NET product version number and not the assembly/DLL version number. As with the .NET Framework system libraries, the first digit of the assembly version number indicates the version of the .NET Framework to use with an ODP.NET assembly. Publisher Policy DLL is provided as before so that applications built with older version of ODP.NET are redirected to the newer ODP.NET assembly.
The Problems:
Problems can rise when you deploy your application on a machine with a different version of the ODP.NET, then you might see the following exception:
Could not load file or assembly 'Oracle.DataAccess, Version=x.x.x.x, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The system cannot find the file specified.
This should be solved by a correct assembly redirection. (From the version you see in the exception to the version already installed).
Another exception you might see is:
The Provider is not compatible with the version of the Oracle Client.
An assembly re-direction should solve this issue, too. This shows up when you have different version of the Oracle.DataAccess.dll in your machine check the Global Assembly Cash (GAC).
Due to older installations or so, while only one of them is corresponding to the latest installed version of the ODP.NET, yet your application references an older one. The first exception won't show up, since your application can find the dll, thanks to the GAC, but it's not the one that should be used.
Just to make sure which ODP.NET version is installed on your machine, check the following registry path HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ODP.NET
In most of the cases the assembly re-direction are the answers.
In some rare cases after getting rid of the re-directions issue you might see the following exception:
Unable to cast object of type 'Oracle.DataAccess.Client.OracleConnection' to type 'Oracle.DataAccess.Client.OracleConnection'
Pretty weird!!
This can be caused by some calls to the Oracle.DataAccess.dll inside the SD.LLBLGen.Pro.DQE.OracleX.NET20.dll which were not successfully re-directed to the installed version.
To solve this issue you will have to re-build the DQE dll to reference the same version of the Oracle.DataAccess.dll found on your development machine.
Details can be found in this post:
http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=9007&StartAtMessage=0즃
Monday, June 4, 2007
OWA Issue on Vista
The Symptoms:
If you are using Outlook Web Access (OWA) on a Windows Vista, to access Exchange Server 2000/2003 , you may find yourself unable to edit any e-mail message.
i.e . Not able to write any new e-mails nor reply to any e-mail.
(You will see a small red 'x' instead of the editor area).
The Cause:
Microsoft has removed the DHTML Editing ActiveX Control (the control that enables you to edit nice rich text with html capabilities) from Windows Vista for security reasons.
The Resolution:
Ask your Exchange Admin or whoever is in charge to install the KB911829 patch for the exchange server. This patch installs a new iFrame Editor instead of the ActiveX one.
If you are using Outlook Web Access (OWA) on a Windows Vista, to access Exchange Server 2000/2003 , you may find yourself unable to edit any e-mail message.
i.e . Not able to write any new e-mails nor reply to any e-mail.
(You will see a small red 'x' instead of the editor area).
The Cause:
Microsoft has removed the DHTML Editing ActiveX Control (the control that enables you to edit nice rich text with html capabilities) from Windows Vista for security reasons.
The Resolution:
Ask your Exchange Admin or whoever is in charge to install the KB911829 patch for the exchange server. This patch installs a new iFrame Editor instead of the ActiveX one.
Monday, May 28, 2007
Real World ASP.NET 2.0 GridView
I have posted earlier on how to Insert from a GridView
Matt Dotson has some nice ideas for a Real World GridView:
Bulk Editing
Two Headed & Grouping GridViews
Excel-like Frozen Headers for ASP.NET 2.0
Matt Dotson has some nice ideas for a Real World GridView:
Bulk Editing
Two Headed & Grouping GridViews
Excel-like Frozen Headers for ASP.NET 2.0
ASP.NET 2.0 Data tutorials
My previous post was about how to Insert from a ASP.NET 2.0 GridView, and the tutorial linked was one of other ASP.NET 2.0 Data Tutorials posted by Scott Mitchell
In case you haven't came across these tutorials, here they are:
http://www.asp.net/Learn/DataAccess/
Good Work.
In case you haven't came across these tutorials, here they are:
http://www.asp.net/Learn/DataAccess/
Good Work.
Inserting from the ASP.NET GridView
Scott Mitchel, has this nice idea of using the footer or a GridView as an inserting panel, Since the GridView already misses the inserting functionality, unlike the FormView or the DetailsView.
Here is the tutorial:
http://www.asp.net/Learn/DataAccess/tutorial53vb.aspx?tabid=63
And he has a follow-up post on his blog to handle the case when the GridView has no rows!!
In this case the GridView unlike the old DataGrid won't display the footer nor the header...oops, (they should have gave us the option here) anyway, the workaround is to use the EmptyDataTemplate to put some controls (a DetailsView is a good option), and here are the full details:
http://scottonwriting.net/sowblog/posts/11904.aspx
Here is the tutorial:
http://www.asp.net/Learn/DataAccess/tutorial53vb.aspx?tabid=63
And he has a follow-up post on his blog to handle the case when the GridView has no rows!!
In this case the GridView unlike the old DataGrid won't display the footer nor the header...oops, (they should have gave us the option here) anyway, the workaround is to use the EmptyDataTemplate to put some controls (a DetailsView is a good option), and here are the full details:
http://scottonwriting.net/sowblog/posts/11904.aspx
Tuesday, March 20, 2007
Building ASP.NET 2.0 Web Sites Using Web Standards
Summary: Microsoft ASP.NET 2.0 has many features to help you design and build Web sites that are compliant with XHTML and accessibility standards. This article looks at how and why you should be building these standards-compliant sites. (78 printed pages)
http://msdn2.microsoft.com/en-us/library/aa479043.aspx
http://msdn2.microsoft.com/en-us/library/aa479043.aspx
Monday, March 19, 2007
Thursday, February 15, 2007
Custom Workflow with Visual Studio 2005 for SharePoint 2007, Part 1
The following series of posts are a compilation of different resources (blogs, MSDN, TechEd...etc).
Software Requirements:
1- Windows Server 2003 R2
2- Microsoft .NET framework 3.0
3- Microsoft Office InfoPath 2007
4- Microsoft Windows Sharepoint Services 3.0
5- Office SharePoint Server 2007 basic installation
6- Visual Studio 2005 with SP1
7- Visual Studio 2005 Extensions for Windows Workflow Foundation
8- Office Sharepoint Server 2007 SDK + ECM starter Kit
Note: The Office SharePoint Server 2007–specific workflow activities require that Microsoft Windows SharePoint Services 3.0 and Office SharePoint Server 2007 be installed on the computer you use to develop the workflows
Workflow and Windows SharePoint Services 3.0:
The WF runtime engine can be hosted in any Windows process. Windows SharePoint Services 3.0 takes advantage of this, acting as a host for this engine. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, or content type. This template can then be loaded and executed by the Windows SharePoint Services-hosted WF runtime engine, creating a workflow instance. The figure below shows how this looks
Sharepoint Server vs Sharepoint Services:
Windows SharePoint Services 3.0 offers a general foundation for human workflow applications. Office SharePoint Server 2007 provides extra capabilities built on this foundation. When is the workflow support in Windows SharePoint Services sufficient, and when is Office SharePoint Server also required? Here’s a short summary of the major factors in making this decision.
Windows SharePoint Services alone is appropriate for:
· Adding application logic to Windows SharePoint Services sites that works with documents and list items.
· Building workflow applications where user interaction via ASPX forms in a Web browser is sufficient.
Office SharePoint Server is required for:
· Using most of the pre-defined workflows that Microsoft provides. (The exception is Issue Tracking, which ships with Windows SharePoint Services and uses only ASPX forms.)
· Building workflow applications where user interaction via Office 2007 client applications is required. This option also allows using InfoPath workflow forms, which are simpler to create and provide more functionality than ASPX forms.
The roles played by different people in a workflow life cycle:
1- Workflow author: the developer or information worker who creates a workflow template.
2- Windows SharePoint Services administrator: the person who installs a workflow template and associates it with a document library or list.
3- Workflow initiator: the person who starts a running workflow, causing a workflow instance to be created from a particular workflow template.
4- Workflow participants: the people who interact with a workflow instance to carry out the business process it supports.
Both installation and association are done automatically for workflows created using Office SharePoint Designer. For those created using WF Workflow Designer and Visual Studio, however, a Windows SharePoint Services server administrator must explicitly install the workflow template. Once this is done, the template must be associated with a library, list, or content type, something that can be performed by someone with lesser permissions than a server administrator. Whoever creates this association also assigns it a unique name, allowing it to be referenced by users. Optionally, the workflow’s author can let the person who creates the association set options for the workflow’s behavior, such as specifying a default list of people who should always participate in the process. The same template can be associated with multiple libraries, lists, or content types, with each association customized as required. After the association has been created and any options set, a workflow initiator can create a workflow instance from this association, as described next.
There are plenty of moving parts in a Windows SharePoint Services workflow. The figure below gives an overall view of how the process works.
Visual Studio 2005 vs SharePoint Designer 2007:
ref. SharePoint 2007 Workflow Jumpstart
Forms in a workflow lifecycle:
Windows SharePoint Services workflow consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow’s behavior.
A Windows SharePoint Services workflow can potentially display its own forms at four points in its lifecycle:
1- Association: When a Windows SharePoint Services administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.
2- Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options, as shown in step 3 of the previous diagram.
3- Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. Shown in step 6 in the previous diagram, this form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.
4- Modification: Although it wasn’t shown in the scenario above, the creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.
Workflows built solely on Windows SharePoint Services define their forms as ASPX pages, while those using Office SharePoint Server can also use forms created with InfoPath.
The most important Activities available for designing a workflow are:
· OnWorkflowActivated: every Windows SharePoint Services workflow must begin with this activity. Among other things, this activity can accept information supplied by the administrator via the Association form when the workflow is associated with a document library or list. It can also accept information supplied via the Initiation form when the workflow is started.
· CreateTask: creates a task assigned to a particular user in a task list.
· OnTaskChanged: accepts information from the Task Completion form.
· CompleteTask: marks a task as completed.
· DeleteTask: removes a task from a task list.
· OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.
· SendEmail: sends email to a specified person or group of people.
· LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Windows SharePoint Services doesn’t support WF’s standard tracking service.
A typical pattern for a simple Windows SharePoint Services workflow begins with an OnWorkflowActivated activity, and then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard while activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the while, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending email, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.
Software Requirements:
1- Windows Server 2003 R2
2- Microsoft .NET framework 3.0
3- Microsoft Office InfoPath 2007
4- Microsoft Windows Sharepoint Services 3.0
5- Office SharePoint Server 2007 basic installation
6- Visual Studio 2005 with SP1
7- Visual Studio 2005 Extensions for Windows Workflow Foundation
8- Office Sharepoint Server 2007 SDK + ECM starter Kit
Note: The Office SharePoint Server 2007–specific workflow activities require that Microsoft Windows SharePoint Services 3.0 and Office SharePoint Server 2007 be installed on the computer you use to develop the workflows
Workflow and Windows SharePoint Services 3.0:The WF runtime engine can be hosted in any Windows process. Windows SharePoint Services 3.0 takes advantage of this, acting as a host for this engine. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, or content type. This template can then be loaded and executed by the Windows SharePoint Services-hosted WF runtime engine, creating a workflow instance. The figure below shows how this looks
Sharepoint Server vs Sharepoint Services:
Windows SharePoint Services 3.0 offers a general foundation for human workflow applications. Office SharePoint Server 2007 provides extra capabilities built on this foundation. When is the workflow support in Windows SharePoint Services sufficient, and when is Office SharePoint Server also required? Here’s a short summary of the major factors in making this decision.
Windows SharePoint Services alone is appropriate for:
· Adding application logic to Windows SharePoint Services sites that works with documents and list items.
· Building workflow applications where user interaction via ASPX forms in a Web browser is sufficient.
Office SharePoint Server is required for:
· Using most of the pre-defined workflows that Microsoft provides. (The exception is Issue Tracking, which ships with Windows SharePoint Services and uses only ASPX forms.)
· Building workflow applications where user interaction via Office 2007 client applications is required. This option also allows using InfoPath workflow forms, which are simpler to create and provide more functionality than ASPX forms.
The roles played by different people in a workflow life cycle:
1- Workflow author: the developer or information worker who creates a workflow template.
2- Windows SharePoint Services administrator: the person who installs a workflow template and associates it with a document library or list.
3- Workflow initiator: the person who starts a running workflow, causing a workflow instance to be created from a particular workflow template.
4- Workflow participants: the people who interact with a workflow instance to carry out the business process it supports.
Both installation and association are done automatically for workflows created using Office SharePoint Designer. For those created using WF Workflow Designer and Visual Studio, however, a Windows SharePoint Services server administrator must explicitly install the workflow template. Once this is done, the template must be associated with a library, list, or content type, something that can be performed by someone with lesser permissions than a server administrator. Whoever creates this association also assigns it a unique name, allowing it to be referenced by users. Optionally, the workflow’s author can let the person who creates the association set options for the workflow’s behavior, such as specifying a default list of people who should always participate in the process. The same template can be associated with multiple libraries, lists, or content types, with each association customized as required. After the association has been created and any options set, a workflow initiator can create a workflow instance from this association, as described next.
There are plenty of moving parts in a Windows SharePoint Services workflow. The figure below gives an overall view of how the process works.
Visual Studio 2005 vs SharePoint Designer 2007:
ref. SharePoint 2007 Workflow Jumpstart
Forms in a workflow lifecycle:
Windows SharePoint Services workflow consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow’s behavior.
A Windows SharePoint Services workflow can potentially display its own forms at four points in its lifecycle:
1- Association: When a Windows SharePoint Services administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.
2- Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options, as shown in step 3 of the previous diagram.
3- Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. Shown in step 6 in the previous diagram, this form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.
4- Modification: Although it wasn’t shown in the scenario above, the creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.
Workflows built solely on Windows SharePoint Services define their forms as ASPX pages, while those using Office SharePoint Server can also use forms created with InfoPath.
The most important Activities available for designing a workflow are:
· OnWorkflowActivated: every Windows SharePoint Services workflow must begin with this activity. Among other things, this activity can accept information supplied by the administrator via the Association form when the workflow is associated with a document library or list. It can also accept information supplied via the Initiation form when the workflow is started.
· CreateTask: creates a task assigned to a particular user in a task list.
· OnTaskChanged: accepts information from the Task Completion form.
· CompleteTask: marks a task as completed.
· DeleteTask: removes a task from a task list.
· OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.
· SendEmail: sends email to a specified person or group of people.
· LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Windows SharePoint Services doesn’t support WF’s standard tracking service.
A typical pattern for a simple Windows SharePoint Services workflow begins with an OnWorkflowActivated activity, and then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard while activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the while, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending email, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.
Subscribe to:
Posts (Atom)
