Working with BeforeProperties and AfterProperties on SPItemEventReceiver
I always forget this and when I come to create a new SharePoint Event Receiver I wonder why the BeforePropertiesor AfterProperties are sometimes not populated.
Consider an example, we need to handle the ItemUpdating event for a document library and prevent a user from changing a certain column. The code might look like this:
public override void ItemUpdating(SPItemEventProperties properties)
{
if (properties.BeforeProperties["Title"] != properties.AfterProperties["Title"])
{
properties.Cancel = true;
properties.ErrorMessage = "This column cannot be changed";
}
}
For a document library, this works just fine. For documents, Before and After properties are guaranteed for post events, such as ItemUpdating and ItemUpdated, but Before properties are not available for post events on list items.
The Before/After properties works differently between LIST and DOCUMENT LIBRARY
SharePointList
Event
BeforeProperties
AfterProperties
ListItem
ItemAdding
Null
New Value
Null
ItemAdded
Null
New Value
New Value
ItemUpdating
Null
Changed Value
Original Value
ItemUpdated
Null
Changed Value
Changed Value
ItemDeleting
Null
Null
Original Value
ItemDeleted
Null
Null
Null
SharePointDocument Library
Event
BeforeProperties
AfterProperties
ListItem
ItemAdding
Null
Null
Null
ItemAdded
Null
Null
New Value
ItemUpdating
Original Value
Changed Value
Original Value
ItemUpdated
Original Value
Changed Value
Changed Value
ItemDeleting
Null
Null
Original Value
ItemDeleted
Null
Null
Null
Properties.ListItem refers to the current list item values at this point in the event.
Original Value refers to the value which is already existing in the content DB.
New Value refers to the value which is being added newly in add event.
Changed Value refers to the value which is being updated in Update event.
So, if we go back to our original problem listed above. How can we prevent a user from changing a certain column
for an item in a list event? From the list table, you can see if we hook into the ItemUpdating event, we can compare the current item’s value (properties.ListItem) to the AfterProperties value. The code would look like this:
// SPListItem item= properties.ListItem;
// String oldvalue=item[“Title”].ToString();
if (properties.ListItem["Title"] != properties.AfterProperties["Title"])
{
properties.Cancel = true;
properties.ErrorMessage = "This column cannot be changed";
}
I always forget this and when I come to create a new SharePoint Event Receiver I wonder why the BeforePropertiesor AfterProperties are sometimes not populated.
Consider an example, we need to handle the ItemUpdating event for a document library and prevent a user from changing a certain column. The code might look like this:
public override void ItemUpdating(SPItemEventProperties properties)
{
if (properties.BeforeProperties["Title"] != properties.AfterProperties["Title"])
{
properties.Cancel = true;
properties.ErrorMessage = "This column cannot be changed";
}
}
For a document library, this works just fine. For documents, Before and After properties are guaranteed for post events, such as ItemUpdating and ItemUpdated, but Before properties are not available for post events on list items.
The Before/After properties works differently between LIST and DOCUMENT LIBRARY
SharePointList
SharePointDocument Library
Properties.ListItem refers to the current list item values at this point in the event.
Original Value refers to the value which is already existing in the content DB.
New Value refers to the value which is being added newly in add event.
Changed Value refers to the value which is being updated in Update event.
So, if we go back to our original problem listed above. How can we prevent a user from changing a certain column
for an item in a list event? From the list table, you can see if we hook into the ItemUpdating event, we can compare the current item’s value (properties.ListItem) to the AfterProperties value. The code would look like this:
// SPListItem item= properties.ListItem;
// String oldvalue=item[“Title”].ToString();
if (properties.ListItem["Title"] != properties.AfterProperties["Title"])
{
properties.Cancel = true;
properties.ErrorMessage = "This column cannot be changed";
}
|
correlation tokens in SharePoint workflow
Correlation Token:
- Is way to group together a set of related activity.
- worflowTokem - created by default in workflows used to group together the whole workflow.
- Is a unique identifier that enables mapping between the objects in a workflow and the environment that is hosting the Windows Workflow Foundation (WF) workflow runtime.
- It can be referred for uniquely identifying each instance of a workflow, modification or task. When SharePoint initiates a workflow, it does not have a unique set of objects. Instead, if one instance of the workflow is already running when the second initiates, the second will reuse objects from the first.
- Correlation token properties ensure that the single activity object is operating on the correct workflow instance and accessing the correct details about the workflow.
You will have a separate correlation token for the each of the following:
- The workflow itself.
- Each task you need to reference in the workflow
Declare the correlation token for the workflow in the OnWorkflowActivated activity. Then, for each activity that affects the entire workflow, bind that activity’s correlation token to the correlation token of the OnWorkflowActivated activity.
Correlation Token:
You will have a separate correlation token for the each of the following:
Declare the correlation token for the workflow in the OnWorkflowActivated activity. Then, for each activity that affects the entire workflow, bind that activity’s correlation token to the correlation token of the OnWorkflowActivated activity.
- Is way to group together a set of related activity.
- worflowTokem - created by default in workflows used to group together the whole workflow.
- Is a unique identifier that enables mapping between the objects in a workflow and the environment that is hosting the Windows Workflow Foundation (WF) workflow runtime.
- It can be referred for uniquely identifying each instance of a workflow, modification or task. When SharePoint initiates a workflow, it does not have a unique set of objects. Instead, if one instance of the workflow is already running when the second initiates, the second will reuse objects from the first.
- Correlation token properties ensure that the single activity object is operating on the correct workflow instance and accessing the correct details about the workflow.
You will have a separate correlation token for the each of the following:
- The workflow itself.
- Each task you need to reference in the workflow
Declare the correlation token for the workflow in the OnWorkflowActivated activity. Then, for each activity that affects the entire workflow, bind that activity’s correlation token to the correlation token of the OnWorkflowActivated activity.
If you consider workflow in SharePoint 2010,it will have certain default status such as In Progress,Completed,Failed on Start,Completed,etc..
but in case if we want custom values for the workflow that would enhance the look of the workflow status to the end user in more convenient way.
Steps Involved:
Note: I'm using Sequential Workflow,This can be used for state machine workflow also.
- Create a sequential workflow and select the type as List Workflow,
- So the Project explorer will look like,
3. Edit the Element.xml file and add the below custom tags just above the ending “Metadata” node,
<ExtendedStatusColumnValues>
<StatusColumnValue>Pending</StatusColumnValue>
<StatusColumnValue>Approved</StatusColumnValue>
<StatusColumnValue>Rejected</StatusColumnValue>
</ExtendedStatusColumnValues>
4. Let the logic in .cs file be as it is,now add a SetState activity form the toolbox and name it as setState1(any name you prefer) and this must be placed as the last activity in the workflow,then only it will work based on logic provided in all the other states located above.
5.In the propeties of setstate activity give a name for MethodInvoking property,let it be "setState1_MethodInvoking"
6. The integer value of the MAX is 15. From 0 to 14, the numbers are reserved for default values like InProgress, completed, error occurred etc. In Element.xml, the value of the first custom value will be 15 and then it will keep on increasing by 1.
So the values represented will be like,
SPworkflowStatus.Max------>Pending
SPworkflowStatus.Max+1------>Approved
SPworkflowStatus.Max+2------>Rejected
7. Build and Deploy to enjoy the result.
If you consider workflow in SharePoint 2010,it will have certain default status such as In Progress,Completed,Failed on Start,Completed,etc..
but in case if we want custom values for the workflow that would enhance the look of the workflow status to the end user in more convenient way.
Steps Involved:
Note: I'm using Sequential Workflow,This can be used for state machine workflow also.
but in case if we want custom values for the workflow that would enhance the look of the workflow status to the end user in more convenient way.
Steps Involved:
Note: I'm using Sequential Workflow,This can be used for state machine workflow also.
- Create a sequential workflow and select the type as List Workflow,
- So the Project explorer will look like,
3. Edit the Element.xml file and add the below custom tags just above the ending “Metadata” node,<ExtendedStatusColumnValues><StatusColumnValue>Pending</StatusColumnValue><StatusColumnValue>Approved</StatusColumnValue><StatusColumnValue>Rejected</StatusColumnValue></ExtendedStatusColumnValues>4. Let the logic in .cs file be as it is,now add a SetState activity form the toolbox and name it as setState1(any name you prefer) and this must be placed as the last activity in the workflow,then only it will work based on logic provided in all the other states located above.5.In the propeties of setstate activity give a name for MethodInvoking property,let it be "setState1_MethodInvoking"6. The integer value of the MAX is 15. From 0 to 14, the numbers are reserved for default values like InProgress, completed, error occurred etc. In Element.xml, the value of the first custom value will be 15 and then it will keep on increasing by 1.So the values represented will be like,SPworkflowStatus.Max------>PendingSPworkflowStatus.Max+1------>ApprovedSPworkflowStatus.Max+2------>Rejected7. Build and Deploy to enjoy the result.
No comments:
Post a Comment