I was recently asked to help out a client who was having problems with standard Out Of the Box Approval workflow.
We checked the Farm and isolated the issue to one specific site collection, all other site collections were fine.
To resolve this we opened the site collection in SPD, open the All files section drilled into the _catalogs/wfpub folder, the folder for the Approval workflow was present but for some reason the wfconfig.xml file had been modified from the site definition (Shown by blue I symbol), once this file had been reset to the site definition workflows were working again.
In this first section we will start creating our SharePoint Designer 2013 workflow. Our focus here is the “Call HTTP Web Service” action. We will be using and Ebay web service for this example. The response from the web service is in JSON (See image below). The “Call HTTP Web Service” workflow action would be useless without the new “Dictionary” workflow action.
In this section we will be taking the workflow a bit further.
1. We will extract the “Title” and “DealURL” data from the JSON response.
2. We will then create and entry in the WebServiceList for each node in our JSON response ( 7 in total )
Following on from yesterdays post regarding problems with getting into the CA site, today we got on with the job of looking at Web Analytics, and the reports that we can provide to end users.
So we checked the Web Analytics reports and could see good graphs like the ones below, very nice.
Just the sort of thing you could hand to a client.
So the next stage was to get the Schedule Web Analytics Reports workflow running and send the reports to a test user for analysis, this is when the fun started, no matter what we did the workflow simply refused to work, all we were getting was “An error has occurred in” and no reports, nothing in the ULS logs, nothing in the Event Viewer and nothing of any help in the Workflow History list, really handy, we knew that ‘normal’ workflows such as Approval worked fine on this system, so it was a bit baffling.
After a few(more) hours of head scratching I decided to try the Schedule Web Analytics Alerts workflow instead, which still failed, but at least gave out a more helpful error.
Of course it turned out that our test account didn’t have a mailbox (duh!), so we used a different account (with a mailbox) and the Schedule Web Analytics Reports worked fine
But it really annoyed me that 2 workflows related to the same area in SharePoint have clearly been developed by different teams in Microsoft and both show different failure messages for the same event.
We go the reports out finally, and they are just straight Excel exports, so we might not even use them, another fun packed day working with SharePoint !
Just a quick blog to go over which features should be enabled for Approval tasks in SharePoint Designer 2010 Workflows.
Project Server – PWA. Workflow being created within a Project Site.
Features enabled at the site collection (PWA):
Features enabled at the site (PWA):
- Features enabled at the site (Project Site):
However, we were getting the following error appear when trying to use the “Start Approval Workflow” action:
Cannot insert this action. To use task process actions, the Office SharePoint Server Standard Site features must be enabled for this site by an administrator.
Interesting error message given that the Standard features were enabled at both the Site Collection and Site level.
On further inspection, it turns out (rather obviously) that the Workflow feature needs to be enabled at the Site Collection level.
It caught us out for a little while, but a quick Google and thanks to this MSDN Forum post, we got the result we needed:
Hopefully, this post helps somebody out.
New with InfoPath 2010 is a People Picker control, this acts like the People Picker in SharePoint and allows you to choose contacts from AD.
I was using this control recently and wanted to promote the chosen person value to a list when the form is submitted, to my surprise I found that the submitted value was just a text value, not a presence aware name, so had none of the rich integration that OCS or Lync offers.
To get around this drawback I had to write a small workflow that fired when the form was submitted.
The workflow read the list value into a variable and then wrote it back to another column in the same list, but was key was to make the return field data type an Email Address.
Now we have a presence aware Name value.
Most SharePoint 2010 solutions will have some form of workflow associated with them.
Workflows written in SharePoint designer can be powerful, but tricky to troubleshoot if they do not work correctly.
Some workflows will complete but not perform as expected, and some will simply fail with the ever helpful An error has occurred in <Workflow Name> written to the history list.
To help us out with this is the Log to History List core action in our workflow designer Action List.
This allows us to write a message to the workflow history, and as such we could write back the value of a workflow parameter or variable that we can check on.
To illustrate this I have written a one step workflow with one Variable and one Parameter, the workflow has an Initiation Form that allows a user to select a colour.
We set the variable varColour to be the value of the colour the user selected which is stored in the parameter ParamColour , on the second line we use the Log to History List to output the value of varColour to the workflow history.
This is what it looks like, firstly we choose a colour from the Initiation Form
The workflow processes and completes, when we check the History list we can see that our message and the value of varColour have been recorded in the Workflow History list
Normally the Workflow History list is hidden from the browser, but you can change this setting in SharePoint Designer.
A common thing I do for most clients is to create a unique alphanumeric ID that is consistent in length with pre-filled zeros.
Risk list alphanumeric ID example:
However, as has been documented many times (link); you cannot use the ID column of a list in a calculated column. To get over this issue I use a simple SharePoint Designer workflow to copy the ID value to another column (Unique Reference) and then base my calculation on the Unique Reference column.
Step One: Create a common site column for use across the Site Collection
- Column Name: Unique Reference
- Column Type: Single Line Of Text
Step Two: Create a calculated column for the alphanumeric ID
- Column Name: Risk ID
- Column Type: Calculated Column
- Formula: =”RSK” & TEXT([Unique Reference], “0000”)
NB: The TEXT function will prefill the ID with zeros
- Step Three: Add the Unique Reference and Risk ID column to your List or Content Type
Step Four: Create the SharePoint Designer Workflow
- Create a list or content type (SP2010 only) workflow
- Workflow should fire on Creation only (disable Manual and Edit)
- Use the following steps:
- Publish the workflow (list workflow)
- Assign the workflow to the content type (if you have created a redistributable workflow in SPD 2010) and assign the content type to the list (content type workflow)
Step Five: Hide the Unique Reference column in the list / content type
- This will stop the Unique Reference column from showing to the end user.
NB: You must hide the Unique Reference column after you have created and published the workflow otherwise it will not appear in SharePoint Designer
You list items will now have a unique alpha numeric ID
NB: Please remember that automatic workflows will not fire if you are logged in as the farm account (link)