It is always interesting to see how your customers have a completely different look on the fantastic product you have been working on for months. After the initial release of our PDF Converter for SharePoint, the majority of the support calls we received were about how to use the product from a SharePoint workflow. Errrr…… we hadn’t really thought about workflows as it is so un-cool, related to SharePoint designer…and…and…and… actually we had never done much with SharePoint workflows.
As much of our feature set and product development is driven by customer demand, it was time to skill up on workflows and - dare I say it - SharePoint Designer. And you know what? It is pretty cool!As a result a new, workflow enabled, version of the PDF Converter is now available for download.
What follows is an example of how to create a simple workflow in SharePoint Designer, which converts a file to PDF format as soon as it has been approved. If you prefer to use Nintex Workflow then have a look at this post.
Before you start, make sure the PDF Converter for SharePoint has been installed and you have access to a site collection with the appropriate rights to create workflows. Some basic knowledge about creating and configuring document libraries is assumed.
Create and configure the Document Library
Create a document library named ‘Important Documents’.
Once created, enable ‘Requires content approval’ on the library’s Settings > Document Library Settings > Versioning Settings screen.
In the document library, create two folders: ‘Confidential Proposals’ and ‘Approved PDF Files’.
Create and configure the work flow
Start SharePoint Designer and open the site collection that contains the ‘Important Documents’ library.
From the File menu select New > Workflow.
On the first screen of the Workflow wizard, specify the following settings:
Name the workflow ‘Convert Approved documents to PDF Format’.
Select the ‘Important Documents’ list.
When creating a SharePoint Designer Workflow in SharePoint 2013 then please select Platform Type: SharePoint 2010 Workflow.
Select the 2nd and 3rd checkboxes to make sure the workflow is triggered whenever a document is created or (its status) is updated.
Click the ‘Next’ button to proceed.
We are now ready to create the workflow. From the ‘Conditions’ menu select ‘Compare any data source’. This inserts the ‘If valueequalsvalue’ condition.
Click on the first ‘value’ followed by the ‘display data binding’ (fx) button.
Select ‘Current Item’ as the Source and select ‘Approval Status’ in the Field. Click the OK button to continue.
Click on the second ‘value’ and select ‘Approved’ from the list.
To avoid that the same workflow is executed on the converted PDF file after the conversion has taken place, we need to specifically exclude pdf files as follows:
Add another ‘Compare any data source’ condition.
Click on the first ‘value’ followed by the ‘display data binding’ (fx) button.
Select ‘Current Item’ as the Source and select ‘File Type’ in the Field. Click the OK button to continue.
Click ‘equals’ and change it to ‘not equals’.
Click on the second ‘value’ and enter ‘pdf’.
With the Conditions in place we can now add the Actions, which is where the magic happens.
From the ‘Actions’ menu, select ‘Convert to PDF’. It may be hidden behind the ‘More Actions’ option.
The following action is inserted:
Convert this document to this url using the same file name and include / exclude meta data. Store the converted item details in List ID: Variable: List ID, Item ID: Variable: List Item ID.
Let’s examine what the various options mean:
this document: Specify which document to convert. Select the option and make sure ‘Current Item’ is selected.
this url: Specify the location the converted file will be written to. The following options are available:
Leave it empty: When no value is specified then the converted document is written to the same folder as where the source file is located.
Site Relative URL: By specifying a URL relative to the current site, e.g. ‘subsite/shared documents/PDF Files’, any folder location in the current site collection can be targeted. This is the option we want to use so enter Important Documents/Approved PDF Files.
Web Application relative URL: Using a URL that is relative to the entire web application, e.g. ‘/sites/Press Office/Public Documents/To Distribute’, any folder location in any site collection can be targeted.
the same file name: The name of the converted file can be specified here. In our case we’ll leave it empty to make sure we use the same name as the original document.
include / exclude meta data: In case of sensitive documents we may want to strip any custom SharePoint columns from the file. Assuming that our document library contains a column ‘Yearly sales forecast’, we want to select ‘Exclude’.
Variable: List ID: A new workflow variable named ‘List ID’ is automatically created. After the file has been converted, this variable will contain the ID of the list the converted file was saved to. This can later be fed into another action in order to manipulate this file further.
Variable: List Item ID: A new workflow variable named ‘List Item ID’ is automatically created. After the file has been converted, this variable will contain the ID of the item the converted file was saved to. This can later be fed into another action in order to manipulate this file further.
Insert a new action named ‘Log to History List’ and enter ‘File converted to PDF Format’.
Insert a new action named ‘Update List Item’ and click this list. We are now going to automatically mark the converted PDF file as approved.
From the ‘List’ dropdown select ‘Important Documents’.
Click the ‘Add’ button and set the field to ‘Approval Status’ and the value to ‘Approved’. Click OK. Please note that things have changed in SharePoint 2010, it is no longer possible to set the value of the ‘Approved’ field. For details and a workaround see this thread on our forums.
In the ‘Find the List Item’ area set the Field to ‘Important Documents:ID’.
Click the fx button next to ‘Value’, specify ‘Workflow Data’ as the Source and set the Field to ‘Variable: List Item ID’. Click OK.
Click ‘OK’ again to return to the Workflow Designer. It should look like the image below.
Click the ‘Finish’ button to activate the workflow.
Testing the work flow
Testing the workflow is simple: create or upload an MS-Word file to the ‘Confidential Proposals’ folder, from the context menu select ‘Approve / Reject’ and approve the file.
This will automatically start the workflow and after a few seconds the Workflow status should change to ‘Completed’ as shown in the screenshot below.
Once the workflow has completed, you should see the PDF version of the document in the ‘Approved PDF Files’ folder.
If an error occurs during the execution of the workflow then have a look at the following:
We are dealing with a lot of translation and localisation work at the moment and unfortunately there does not seem to be a definitive list of which languages (and their codes) are supported by SharePoint.
The Locale ID is important for SharePoint Solutions that deploy to the 12/Template/<locale id> folder, for example custom workflow activity .ACTIONS files.
The culture name is used in the names of resource files.
During the 6 week public beta cycle of the initial release of the PDF Converter for SharePoint we have received a lot of positive feedback as well as a number of bug reports.
Feedback has been processed, bugs have been fixed and we are happy to announce our first (non beta) release with immediate availability.
For those not familiar with the product, the PDF Converter for SharePoint is a light weight solution (2.5MB download) that allows end-users to convert common document types, such as doc, docx, rtf, txt etc, to PDF format from within SharePoint. It integrates at a deep level with SharePoint and leverages facilities such as the Audit log, localisation, security and tracing. It runs on both WSS 3 as well as MOSS and is available in English, German, Dutch and Japanese. For detailed information check out the product page.
The main changes introduced in version 1.1 are as follows:
335
Improved support for documents that use extended character sets such as Japanese.
Installation improvements on non English versions of operating systems.
331
Removal of GUI based installer. It was not robust enough.
483
More descriptive errors logged to the event log when there are problems with the deployment of resources if the Timer service account is not a local administrator.
481
No longer creating a custom Event Source in the registry and thereby preventing security related errors.
241
Significant improvements in memory usage when converting documents.
366
Improved compatibility with certain kinds of document content.
When Microsoft released their Office 2007 suite of applications they introduced the new Office Open XML standard as well. This XML standard would be the default format for all their applications and the structure of the files would be made an official ECMA standard.
As this standard is based on XML, the content of - for example - an MS-Word file should be relatively easy to parse and then do something useful with it. Something useful is in the eye of the beholder and James Newton King thought it was a good idea to set a couple of months aside and use it as a showcase for Silverlight 2.0, resulting in TextGlow, a Silverlight control that, you guessed it, can display MS-Word files.
This article shows you how to embed TextGlow into SharePoint and use it to display content stored in a Document Library. It is assumed that you are familiar with the Content Editor Web Part, if not then check out Todd Bleeker’s excellent resource on this topic.
TextGlow in SharePoint
OK, let’s get started
Make sure you have a copy of Silverlight 2.0 installed on your system
Navigate to an existing or create a new SharePoint site collection.
Download the TextGlow Silverlight viewer, unzip and copy the TextGlow folder (including the folder) to a document Library named ‘Shared Documents’
Add a new Content Editor Web Part (CEWP) to a page of your choice and set the height to something suitable (I used 700 pixels),
Open the Source Editor for the CEWP and paste in the following code.
Save the changes and admire the results of your work.
Please note that TextGlow is a proof of concept only. It crashes (badly) if you throw a document at it that is more than a few pages long. If you don’t like it then you can fix it yourself as the TextGlow source code has been open sourced. Alternatively you can use something more mature such as our PDF Converter for SharePoint and display the resulting PDF file in the Page Viewer Web Part.
This article was originally posted on our CTO’s personal blog. Due to the tremendous amount of positive feedback we have decided to update the post and move it to the Muhimbi blog, which has more of a SharePoint focused audience. Please check out our PDF Converter for SharePoint, URL Shortener and other SharePoint products if your find this article helpful.
Ever since SharePoint 2007 was introduced I have been really disappointed with the 2 minute spin-up time of the sites and the 30 second wait when launching STSADM.
How could Microsoft have released this? I thought, What is wrong with these people?Why is there no uproar in the SharePoint Community at large?
The SharePoint community quickly came up with workarounds such as the SPWakeUp tool on Codeplex, but these tools don’t actually fix the underlying problem and are of no help at all when you are developing a project that requires a SharePoint restart between compilations.
Before you continue reading you should realise that there are multiple factors that affect initial load time. There is the ‘loading of the assemblies and associated pre-compilation’ wait time, which can be solved by faster hardware, and then there is the problem outlined below, which may or may not be present in your environment. Read on to find out.
As it turns out this problem does not occur on all SharePoint installations, it only happens under a certain combination of circumstances. Fortunately I have identified the root cause as well as a solution.
Symptoms for STSADM:
You start STSADM without any parameters
There is a delay of about 30 seconds
While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic.
Symptoms for SharePoint sites:
You make the first request of the day, or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.
There is a delay of about 2 minutes
While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today, there is no CPU activity, swapping or significant network traffic.
So, what is going on here? Quite a few SharePoint developers are complaining about this on the Internet - and we even encountered the problem on the training disk images used by a renowned SharePoint training provider - but no-one has a real solution.
After yet another night of Googling around I found the solution in a posting about SQL Server 2005, which appears under certain circumstances to suffer from the same problem as SharePoint 2007. (Note that in my particular situation the problem is caused by SharePoint being slow, not SQL Server.)
The problem is that when loading signed assemblies the .net Framework checks the Internet based Certificate Revocation List. As our servers have, like most secure environments, no outgoing connections to the public Internet, the connection to crl.microsoft.com times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.
After the timeout the assembly is still loaded and the software works as expected, though very slow every time a new signed assembly is loaded for the first time, which happens a lot. The worst thing is that no entries are written to the event log and no exceptions are thrown so you are left completely in the dark about why your application is so bloody slow.
There are a couple of workarounds, which one works best is for you to decide:
Add crl.microsoft.com to your hosts file and point it to your local machine. Some people have reported success with this, but it didn't work for me.
Allow your servers to directly connect to crl.microsoft.com. If your environment dictates the use of a proxy server, configure it using proxycfg.
Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard or run the vbscript at the end of this posting to help you out. Alternatively you can manually modify the registry for each account:
Add them:
certutil -addstore CA CodeSignPCA.crl
certutil -addstore CA CodeSignPCA2.crl
Mark Russinovich has written a detailed post about this problem and provides a 5th option, which involves a manual change to each web application’s web.config file.
We decided to go for Option 3 (disable CRL check) and life is good again, the improvement is significant.
VBScript to apply registry change:
The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.
const HKEY_USERS = &H80000003
strComputer = "."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\default:StdRegProv")
strKeyPath = ""
objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys
strKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"
For Each subkey In arrSubKeys
objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, "State", 146944
Next
With thanks to Nik Shaw for the script.
Please read the comments section below, it contains some interesting replies including changes required for the various Windows versions as well as a PowerShell equivalent of the above mentioned VBScript code.