by Martin Laukkanen | Aug 6, 2010 | Development, Project 2010
This is a useful solution; with it you can update on a PDP an Excel spreadsheet saved in project’s workspace document library and then potentially update custom fields from the results.
However it is far from a complete solution to download and deploy.
First issue – Admin rights required to use Web-Part:
Installed as per instructions (build / package / run script), then when adding the web part this familiar error occurred:
“An unexpected error has occurred.”
A quick look at the ULS shows more details:
The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.
Now that’s interesting as I had this exact same issue a few months back working with a 2007 PSI project, it turns out the answer is rather simple; the web service is attempting to write to the event log using “EventLog.WriteEntry” method calls, however in Windows 2008 and above this is restricted to Administrators only. So as the PWA users are not local admins the error was guaranteed.
A quick solution is to comment out each line in the code beginning with “EventLog.” of course that will disable the logging, so you would be better off doing that after you get everything else working. The file in the solution that you are after is CostAndBenefiXlsWebPart.cs in the WebPart.CostBenefit project and you’ll find about half a dozen envent log entries to comment out.
Second issue – The default site template location:
While your in that file commenting out lines, you’ll most likely notice this;
private string pdpSitePath = @”http://project.contoso.com/PWA/MajorPWSTemplateSite;”
Although the solution will work without changing this, as that is only used when no workspace site exists (like when in server settings – project detail pages), updating that to point to your http://server/pwa/template workspace site template will fix any file not found issues when setting up your PDPs.
Third issue – Location of the Excel document used:
If you’ve gotten this far then like me you might be seeing something like this:
No item exists at http://servername/_layouts/xlviewer.aspx?list=b73da3b8-b48e-400c-8fe0-9b6a48442518&id=1&DefaultItemOpen=1&Edit=1. It may have been deleted or renamed by another user.
A little digging turned up the cause of this one to be the embedded ID in that URL “&id=1”, which means that it is trying to open the document with ID 1 in that particular list. This again is hard coded in the same .cs file as above (line 191), so you can either make certain that in your template above the first file saved to the Project Documents folder is your xls sheet, or modify the code again.
All done.
So now we should have a working webpart referencing our Excel sheet saved in the project workspace site, there are some obvious limitations, not least of all the inability to use any other spreadsheet in the webpart. But I guess that’s why they call it a “solution starter”.
Update 23/10/2010: Most of the points above have been fixed in the more recent updates to the solution starter package, make sure you update your code from Codeplex: http://code.msdn.microsoft.com/P2010SolutionStarter
by Martin Laukkanen | Apr 11, 2010 | Development, Project 2010, Troubleshooting, Workflow
I’ve been working on a full end-to-end demand management workflow over the past couple of weeks and unfortunately as RTM is due any day now, much of the final documentation is still not public, meaning that some things just need to be figured out.
One problem that I found is the custom workflow task form, which has a very useful "Review project details" link on it. However if you have used Microsoft’s demo2010a image, then you’d see that for all of the workflow’s the link initially does not work. (See image)
Fortunately this one was relatively easy to guess, thanks MS for making it quite obvious!
Firstly a custom workflow task content type called PSWApprovalTask is created by default in the PWA site "Project Server Workflow Tasks" list, here’s what it looks like out-of-the-box:
Interestingly though, it is not by default added to the list content types, BUT if you run through the Sample Proposal Workflow once then you will see it appear in the list automatically. For the purpose of this just use the ‘Add from existing site content types’ option in List Settings to add it:
Now another interesting thing is apparent on the list settings page:
Specifically Microsoft has pre-defined three Columns named: Project Name, Project Owner and ProjectUid (and some others..), however they are not added to the content type by default either, but they are used in the views including the default My Tasks.
To the point:
Now getting to the point of this post, if you use the content type and populate all of those fields then the task approval page will work as expected! Specifically the ProjectUID Column needs to be populated with guess what: the Project’s GUID, once that is done then the link works as expected!
Too easy!
Well unfortunately not. The Visual Studio Workflow Activities included with Project Server 2010 gives you the very handy ReadProjectProperty action, however while having a choice of either reading a Custom Field based on GUID or a pre-defined built in field based on name, it does not include Project GUID. This is where it gets complicated.
The “simple” solution is to use PSI, then using something like this nice little method created by Chris Boyd you can retrieve the GUID by providing the Project Name using PSI method ReadProjectStatus.
Unfortunately having to use PSI in what otherwise could be a very simple SharePoint workflow in my opinion is clunky, it would be very nice if MS could add the Proj_UID property to the ReadProjectProperty action!
If you’re interested, based on Chris’s blog post linked above, here is an extract of my code to get all of those fields working (Note that this plugs in nicely to my last code post: Extending the Branching Workflow):
// Declare your PSI Stuff
private static WebSvcProject.Project project = new WebSvcProject.Project();
private void createTask_InitApproval(object sender, EventArgs e)
{
[… insert your other required task attributes …]
taskProps.ExtendedProperties["Project Name"] = Proj_Name[0];
taskProps.ExtendedProperties["Project Owner"] = Proj_Owner_Name[0];
taskProps.ExtendedProperties["ProjectUid"] = GetProjectUidFromProjectName(Proj_Name[0]);
}
public static Guid GetProjectUidFromProjectName(string projectName)
{
Guid projectGUID;
project.Credentials = CredentialCache.DefaultCredentials;
WebSvcProject.ProjectDataSet readProjDs = new WebSvcProject.ProjectDataSet();
readProjDs = project.ReadProjectStatus(
Guid.Empty,
WebSvcProject.DataStoreEnum.WorkingStore,
projectName,
0
);
if (readProjDs.Project.Rows.Count == 1)
{
projectGUID = new Guid(readProjDs.Project[0].PROJ_UID.ToString());
}
else
{
throw new Exception("No Project by the name: " + projectName + " Found");
}
return projectGUID;
}
Enjoy!
Update 4/08/2010:Check the comments below for a much easier way to correct this issue, without the use of PSI.
by Martin Laukkanen | Apr 11, 2010 | Development, How to, Project 2010, Workflow
With Project Server 2010 you get an out of the box workflow named ‘Sample Proposal Workflow’, this is quite a good demonstration as it includes all of the usual things you might see in such a process; Validation, Approval, Selection, etc. However unfortunately as of this time (days before RTM) the source for this sample is still not available, at the moment the only SDK example is a simple Branching Workflow which only includes a single validation step.
I had an opportunity at the Sydney Ignite to ask Jan Kalis about this one, and he assured me that the full source for the sample will be released sometime around RTM, but we’ll have to wait a little bit more for that one.
In the meantime the world moves on and I have been busily writing my first full blow demand management workflow for a customer deployment, and so I thought I would share some of what I have done here. To that end I have taken the SDK Branching Workflow and extended it to include an Approval stage similar to that in the Sample Proposal Workflow.
Read below for what I have done and what you need to test it for yourself, then download my Visual Studio 2010 project below.
Branching Workflow with Approval:
The steps below are a summary of the changes made to the Branching Workflow, for a more complete how-to guide I very strongly suggest that you read the SDK Branching Workflow article and if you complete the examples there you will end where my steps below begin. Furthermore all the general requirements for getting this running (Visual Studio 2010 etc) are in the SDK article.
Before you start (or download):
This example is built on a default PWA instance, I have renamed the out of the box Sample Proposal Workflow to ‘Branching Workflow with Approvals’ then after deploying the code changed the workflow selected to the new one. All other PDPs and Stages are used as is, and the only other change required is an optional one below in step 5 below (see image).
Changes Made:
- Starting with the SDK Branching Workflow (note that if you download it in the p14betasdk then the code is incomplete and a few steps from the MSDN article must be completed). I also renamed the Feature and the Workflow in the deployment package to avoid confusion.
- Then I added a pre-build event command to automatically regenerate the Strong Name. (Can be removed, but just makes testing easier)
- Added a step after the Proposal Details Stage where the workflow goes to Proposal Selection Stage in Select Phase (updateProjectStageStatus20 – Waiting for Approval) – Note I have used the Select phase as my ‘Approval’ phase, I am not doing anything with Portfolio Selection here just approval.
- Next I read the Project Properties of "Project Name" and "Owner" for the Workflow Task (These are optional and just for completeness).
- Read "Portfolio Managers" Project Server Group membership to create approval request for first person returned in group.
- Create Workflow Task using CreateTaskWithContentType and assign to approver and populate task properties with Project Name and Owner.
Important: In order for these task properties to work you must ad the built in Columns to the PSWApprovalTask content type by editing the Default Workflow Approvals, then updating the content type to include the existing list columns.
(See Screenshot from List Settings PSWApprovalTask Content Type Properties)
- Then we add a while activity onTaskChanged to wait for the Approval task to be actioned. In this step the ExtendedProperties are checked for a value "Approved" anything else results in Rejection.
- And finally an IfElseActivity is used to branch on the Approved / Rejected result.
- If true then continue to end and UpdateProjectStageStatus to Execution stage.
- Else UpdateProjectStageStatus to Not Selected state and Terminate.
Here is the result in Visual Studio:
What’s left?
- Email notification? You can simply use the SharePoint list notifications on the Workflow Task list as a simple and consistent email notification method.
- Portfolio Selection? I’ll leave that one to you.
Technical Details:
This example was created on the following beta software, meaning that things might change by RTM:
- SharePoint Server 2010 RC Build
- Project Server 2010 RC Build
- Visual Studio 2010 RC Build
Download the full project files in a zip here. (*see update below)
MSDN References:
How to: Create a Branching Workflow <http://msdn.microsoft.com/en-us/library/ee767701(v=office.14).aspx>
Step 3: Create the Workflow <http://msdn.microsoft.com/en-us/library/ms580283.aspx>
UPDATE 3/09/2010:
I thought that I’d revisit this one as clearly from the comments there was something wrong after RTM, basically the problem everyone seems to be having relates to the ‘WorkflowTaskCTypeID’ defined. Somehow what I had in the BranchingWorkflow.cs file is actually incorrect, the solution has the following on line 46:
public String WorkflowTaskCTypeID = “0x0108010038A52C27344148C9B9214F82C7C0298500544602C73FFD1245BCC090442C85426B”;
When it should be:
public String WorkflowTaskCTypeID = “0x0108010038A52C27344148C9B9214F82C7C02985?;
Not quite sure where the first one came from (and why it worked?!) but that fixed it for me. If you update that line then recompile / rebuild you should be good.
PS. I don’t use the CreateTaskWithContentType anymore, have a look at the 2010 workflow activity (OfficeTask class) used in the Sample Proposal found in the SDK: http://msdn.microsoft.com/en-us/library/microsoft.office.workflow.actions.officetask.aspx
by Martin Laukkanen | Feb 23, 2010 | Development, SharePoint 2010
While diving deeper into the SharePoint 2010 PowerShell command-lets I realised that my last blog using a borrowed script based on 2007 was in need of a major update for 2010, so see here a version doing the same thing but with no use of STSADM (and thus no need to run as admin in 2008).
Warmup2.ps1
############################################################################
#WarmUp2.ps1 - Enumerates all web sites in web applications in a 2010
# SharePoint farm and opens each in a browser.
#Notes:
#-"get-webpage" function borrowed from:
# http://kirkhofer.wordpress.com/2008/10/18/sharepoint-warm-up-script/
#
#Assumptions:
#-Running on machine with WSS/MOSS 2010 installed
############################################################################
Add-PsSnapin Microsoft.SharePoint.PowerShell
$extrasitelistfile = 'c:ToolsWarmupwarmup-extrasites.txt'
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}
#This passes in the default credentials needed. If you need specific
#stuff you can use something else to elevate basically the permissions.
#Or run this task as a user that has a Policy above all the Web
#Applications with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential("username","password","machinename")
$apps = get-spwebapplication -includecentraladministration
foreach ($app in $apps) {
$sites = get-spsite -webapplication $app.url
foreach ($site in $sites) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;
}
}
# Warm up other sites specified in warmup-extrasites.txt file (such as SSRS)
if (test-path $extrasitelistfile) {
$extrasites = get-content $extrasitelistfile
foreach ($site in $extrasites) {
write-host $site;
$html=get-webpage -url $site -cred $cred;
}
}
The script still retrieves a list of all sites in all web applications in the farm (including Central Admin) and additionally retrives a list of sites in a text file by default located in “C:ToolsWarmupwarmup-extrasites.txt”
Warmup-extrasites.txt
http://servername/ReportServer
Enjoy!
by Martin Laukkanen | Feb 20, 2010 | Development, SharePoint 2007
[Update: 23/02/10] I have updated this script in a new post here which does not rely on STSADM and therefore does not need to be run as admin.
With all the 2010 lab testing I have been doing lately I’ve been meaning to get around to creating / finding a new WarmUp script to use but this time based on PowerShell.
What I found is fortunately there are loads of examples out there to get you started as with most things PowerShell. See Kirk Hofer’s Blog for the one I started with.
So anyway I have added a little to the script, now in addition to opening each site in the farm it also parses a text file (C:ToolsWarmupwarmup-extrasites.txt) for additional URL’s, which I use to warm up particular SSRS or Excel reports.
Warmup.ps1
############################################################################
#Assumptions:
#-Running on machine with WSS/MOSS
############################################################################
$stsadmexe = 'C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BINSTSADM.exe'
$extrasitelistfile = 'c:ToolsWarmupwarmup-extrasites.txt'
function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}
#This passes in the default credentials needed. If you need specific
#stuff you can use something else to elevate basically the permissions.
#Or run this task as a user that has a Policy above all the Web
#Applications with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential("username","password","machinename")
[xml]$x=&$stsadmexe -o enumzoneurls
foreach ($zone in $x.ZoneUrls.Collection) {
[xml]$sites=&$stsadmexe -o enumsites -url $zone.Default;
foreach ($site in $sites.Sites.Site) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;
}
}
# Warm up other sites specified in warmup-extrasites.txt file (such as SSRS)
if (test-path $extrasitelistfile) {
$extrasites = get-content $extrasitelistfile
foreach ($site in $extrasites) {
write-host $site;
$html=get-webpage -url $site -cred $cred;
}
}
Warmup-ExtraSites.txt
http://servername/ReportServer
Download both files here.
Take note of the variables at the top of the script with the paths pointing to the 14 hive and the extra sites text file.
Save those files somewhere (default c:ToolsWarmUp) then schedule them to run with a command line as follows:
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe C:ToolsWarmupwarmup.ps1
Finally just make sure you select the Run with highest privileges option as stsadm will need that to enumerate the sites.
Enjoy!
