Muhimbi

Posted at: 3:11 PM on 12 March 2010 by Muhimbi

In part of 2 of our series about porting a SharePoint 2007 based WSPBuilder project to SharePoint 2010 we discuss the changes made to our Visual Studio 2008 based project to support both versions of SharePoint

Please note that this article is based on our experiences with the beta version of SharePoint 2010. Some of the issues we have identified may have been resolved in the final release.  

The following posts are part of this series:

• Part 1 – Introduction / Problems installing the existing 2007 version on SP2010
• Part 2 – Reconfiguring the Visual Studio Solution (This post)
• Part 3 – Programmatic / visual changes (Available soon)
• Part 4 – Updating deployment scripts (Available soon)
   
  

WSP Builder

On January 13 a new ‘2010’ compatible version of WSPBuilder was released. I seriously doubt this new version is required in order to build SharePoint 2010 compatible solutions, but we upgraded to it nevertheless.

Note that if you want to use WSPBuilder to build a hybrid SharePoint 2007 / 2010 solution or a solution that just targets SharePoint 2007 then you must perform the build on a machine that runs SharePoint 2007. The latest version of WSPBuilder checks which version of SharePoint is installed on the build machine and adds SharePoint 2010 specific elements to the generated WSP file, causing deployments to fail in SharePoint 2007 environments.

Unfortunately it does not seem to be possible to modify this behaviour using a command line switch.

Visual Studio Project structure

Depending on the complexity of your project, and on the need to add any SharePoint 2010 specific functionality, you may not need to make any changes to your project structure.

However, in our case we decided to make the following changes:

1. We renamed the 12 folder to SPHive. From a functional perspective there is no need to make this change, however it provides our developers with a more consistent experience as, depending on the platform they are targeting, the files may go to either the 12 or 14 hive.
    
2. A separate shadow SPHive_2010 folder was created to store SharePoint 2010 specific copies of files that will break compatibility when deployed to SharePoint 2007. For example element files that contain Custom Actions that target the SharePoint 2010 specific Ribbon will prevent a WSP file from deploying to SharePoint 2007. Application pages that contain the DynamicMasterPageFile attribute will break compatibility as well.
    

When a build is carried out the two SPHive folders are merged and 2 separate WSP files are created. For details see the next section.

Post Build event

Although the WSPBuilder Extensions for Visual Studio are great, our projects don’t use them. Instead our main project’s Post Build event invokes either WSPBuilder manually to generate WSP files or carries out a deployment using XCOPY.

As part of this exercise we have made the following changes:

1. Auto detect the installed version of SharePoint.
2. Determine the location of the SharePoint root directory (12 or 14 Hive).
3. Added support for generating both SharePoint 2007 and 2010 WSP files when doing a release build.
4. Added the ability to carry out an XCOPY deployment of a merged version of the SPHive and SPHive_2010 folders..
    

A simplified copy of our PDF Converter’s post build event is included below. As all our development servers run the 64 bit version of Win2K8 or Win2K8R2 this script may not work on Win2K3 or 32 bit installations. Some long lines, especially those invoking WSPBuilder, have been wrapped and reformatted for readability. When copying this script please make sure that multi-line commands are all placed on a single line.

set useWSPBuilder=false

set gacutil="$(SolutionDir)..\..\SharedBinaries\GACUtil\gacutil.exe"

set wspbuilder="$(SolutionDir)..\..\SharedBinaries\WSPBuilder\wspbuilder.exe"

set SPHive_2010=$(ProjectDir)SPHive_2010

@echo ** Detect which version of SharePoint is installed.

set CommonProgramsFolder=%CommonProgramW6432%

set SharePointRoot=%CommonProgramsFolder%\Microsoft Shared\Web Server Extensions\14

set IsSP2010=true

if exist "%SharePointRoot%\bin\STSADM.EXE" goto endVersionDetection

        set SharePointRoot=%CommonProgramsFolder%\Microsoft Shared\Web Server Extensions\12

        set IsSP2010=false

        if exist "%SharePointRoot%\bin\STSADM.EXE" goto endVersionDetection

        echo ** SharePoint does not appear to be installed on this server.

        goto end

:endVersionDetection

echo Detected SharePoint Root: "%SharePointRoot%"

if $(ConfigurationName)==Debug goto debugMode

        @echo ** Not running in debug mode so enabling WSPBuilder

        set useWSPBuilder=true

:debugMode

@REM Do we want to build using XCopy or WSPBuilder?

if %useWSPBuilder%==false goto useXCopy

    @echo ** Build mode: WSP Builder

    @echo ** Remove files from the WSPBuilder GAC Directory

    del /F /Q "$(ProjectDir)GAC\*.*"

    @echo ** Move dependent DLLs to GAC directory to allow WSPBuilder to package them up

    move /y "$(TargetDir)Muhimbi.SharePoint.Common.dll" "$(ProjectDir)GAC"

    move /y "$(TargetDir)Muhimbi.SharePoint.Diagnostics.dll" "$(ProjectDir)GAC"

    move /y "$(TargetDir)Muhimbi.Licensing.Base.dll" "$(ProjectDir)GAC"

    move /y "$(TargetDir)Muhimbi.Licensing.Validator.dll" "$(ProjectDir)GAC"

    move /y "$(TargetDir)Muhimbi.Licensing.SharePoint.dll" "$(ProjectDir)GAC"

    @echo ** Building WSP for SharePoint 2007

    %wspbuilder% -BuildDDF True -BuildWSP true -ResetWebServer False -Outputpath 

        "$(ProjectDir)Solution" -12Path "$(ProjectDir)SPHive" -GACPath "$(ProjectDir)GAC" 

        -ProjectPath "$(ProjectDir)" -Cleanup True -Excludefiletypes "cmd,cs,scc" 

        -WSPName Muhimbi.PDFConverter.wsp -BuildSafeControls False

    @echo ** Building SPHive for SharePoint 2010

    set SPHive_Temp=$(ProjectDir)_SPHive_Temp

    rm -f -r "%SPHive_Temp%"

    md "%SPHive_Temp%"

    xcopy /E /Y "$(ProjectDir)SPHive" "%SPHive_Temp%"

    xcopy /E /Y "%SPHive_2010%" "%SPHive_Temp%"

    %wspbuilder% -BuildDDF True -BuildWSP true -ResetWebServer False -Outputpath 

        "$(ProjectDir)Solution" -12Path "%SPHive_Temp%" -GACPath "$(ProjectDir)GAC" 

        -ProjectPath "$(ProjectDir)" -Cleanup True -Excludefiletypes "cmd,cs,scc" 

        -WSPName Muhimbi.PDFConverter.SP2010.wsp -BuildSafeControls False

    @echo ** Cleaning up

    rm -f -r "%SPHive_Temp%"

    del /F /Q "$(ProjectDir)Solution\makecab.ddf"

    goto end

:useXCopy

    @echo ** Build mode: XCOPY

    xcopy /E /Y "$(ProjectDir)SPHive" "%SharePointRoot%"

    if %IsSP2010%==false goto skipSP2010Copy

        @echo Copying SharePoint 2010 specific files

        xcopy /E /Y "%SPHive_2010%" "%SharePointRoot%"

    :skipSP2010Copy

    @echo ** Installing GAC assemblies

    %gacutil% /if "$(TargetDir)Muhimbi.SharePoint.Common.dll"

    %gacutil% /if "$(TargetDir)Muhimbi.SharePoint.Diagnostics.dll"

    %gacutil% /if "$(TargetDir)Muhimbi.Licensing.Base.dll"

    %gacutil% /if "$(TargetDir)Muhimbi.Licensing.Validator.dll"

    %gacutil% /if "$(TargetDir)Muhimbi.Licensing.SharePoint.dll"

    @echo ** Installing $(OutDir)$(TargetFileName) into the GAC...

    %gacutil% /if "$(TargetPath)"

    echo ** Recycling App Pools

    cscript //NoLogo "$(SolutionDir)\RecycleAppPools.vbs"

:end

@echo ** rebuilding sitemaps and translations

"%SharePointRoot%\bin\STSADM.EXE" -o copyappbincontent

The vbscript file that we use to recycle the application pools at the end of the build process was not working on our SharePoint 2010 development machine for some reason. We are not sure if this is related to the fact that we migrated to Win2K8R2 (from Win2K8) as part of the SharePoint 2010 deployment process or if it is because the script was always broken. Basically it fell over if one of the Application Pools was not started.

The new script is now as follows:

Set oWebAdmin = GetObject("winmgmts:root\WebAdministration")

Set oAppPools = oWebAdmin.InstancesOf("ApplicationPool")

For Each oAppPool In oAppPools

    WScript.Echo "Recycling application pool: " & oAppPool.Name

    '** Only recycle pools that are currently started

    if oAppPool.GetState = 1 then

        oAppPool.Recycle    

    end if

Next

Continue to Part 3 – Programmatic / visual changes (Available soon).

.

Labels: Articles, News, PDF Converter, Products, SP2010, Workflow

Posted at: 5:01 PM on 11 March 2010 by Muhimbi

When we decided to make our popular PDF Converter for SharePoint compatible with SharePoint 2010, we had no idea what we were in for. Will it be a nightmare, will it just work, will we need to throw everything away?…. we simply didn’t know. Fortunately SharePoint 2010 is much like SharePoint 2007 and as a result we released the SharePoint 2010 compatible version earlier today.

As there is very little available information or guidance on this topic, we would like to share our experience with migrating SharePoint 2007 based WSPBuilder projects to SharePoint 2010 while maintaining a single code base that supports both environments.

This post, the first one in the series, describes what happened when we tried to install a SharePoint 2007 based solution on a machine running SharePoint 2010.

The following posts are part of this series:

• Part 1 – Problems installing the existing 2007 version on SP2010 (this post)
• Part 2 – Reconfiguring the Visual Studio Solution
• Part 3 – Programmatic / visual changes (Available soon)
• Part 4 – Updating deployment scripts (Available soon)

Please note that this article is based on our experiences with the beta version of SharePoint 2010. Some of the issues we have identified may have been resolved in the final release.

Our goal

When we started the planning phase for the SharePoint 2010 migration, we decided that ideally we would end up with a single code base that can be used to build a single WSP file that is compatible with both SharePoint 2007 and 2010. To make the product easy to maintain we only want a single Visual Studio Solution and as little code duplication as possible. At the same time we wanted to leverage SharePoint 2010’s new facilities such as the Ribbon without breaking compatibility.

Although we had to give up our single WSP file dream, more on that later, we managed to achieve our other goals.

Installing a SharePoint 2007 based solution on SharePoint 2010

When we embarked on our migration project we briefly thought: what if it just works? That would have been great, but unfortunately we stumbled at the first hurdle, the installer.

The installer for the SharePoint WFE part of the solution is a simple cmd script that invokes stsadm directly. In SharePoint 2010 stsadm lives in a different directory from its SharePoint 2007 counterpart so our dream ended rather abruptly.

Once we had fixed the installer we stumbled onto a rather annoying problem that kept us busy for the better part of 2 days. Whenever we tried to deploy a WSP file (any WSP file it turned out) the process failed without any error messages. However, the following message was logged to the Windows Application Event log: Requested registry access is not allowed.

After consulting many sources, it turned out that if the first attempt to install SharePoint 2010 fails (ours did) then the privileges on the HKLM\SOFTWARE\Microsoft \Shared Tools\Web Server Extensions\14.0\Secure\FarmAdmin registry key are not configured during subsequent successful installations. After giving the Everyone group full control on this key it was finally possible to deploy WSP files. (I realise that giving Everyone access is not best practice, but it solved the problem on our development server).

For details about the changes we had to make to our deployment scripts see part 4 of this series.

Where are my menu options?

Once the wsp file was installed and deployed, the Convert to PDF option became visible in the ECB (file context menu), woohooo! Unfortunately, the link to our Central Administration based configuration screen was missing. Because the Central Administration screens have been restructured, the Locations recognised by SharePoint 2007 have no direct mapping to their SharePoint 2010 equivalents. It is a shame that SharePoint is not automatically remapping those Locations that have a direct equivalent in SharePoint 2010. After all, the External Service Connections Location is available in both versions.
 

Link to the PDF Converter Settings screen in SharePoint 2007

For details about the changes we had to make in order to make the menus work, see part 3 of this series.

Why does it all look wrong?

The main problems we encountered during this entire exercise were related to the visual fidelity of our Application screens. We take great pride in the appearance of our solutions so we were disappointed to see that, even though we have gone through great lengths to only use those user interface elements and controls that ship with SharePoint, things didn’t look quite right.

The main visual problems we encountered are as follows:

1. The vertical alignment of checkboxes is completely off.
2. There is extra vertical spacing between the various user interface elements.
3. Some elements, particularly buttons, have a different default width and therefore wrap over multiple lines.

 
The following screenshots provide a visual comparison between the SharePoint 2007 and 2010 versions before any changes were made.

  Original SharePoint 2007 interface and the SharePoint 2010 one before making any changes

This concludes the overview of identified problems.

Continue to Part 2 – Reconfiguring the Visual Studio Solution.

.

Labels: Articles, News, PDF Converter, Products, SP2010, Workflow

Posted at: 10:09 AM on by Muhimbi

When we released the Office 2010 compatible version of the Muhimbi PDF Converter for SharePoint we were already planning, and worrying about, a SharePoint 2010 compatible version. Worrying indeed, call it fear of the unknown or fear of change, but we were anticipating a lot of work.

Fortunately we quickly found out that SharePoint 2010 is, surprise surprise, much like SharePoint 2007. If it wasn’t for an annoying SharePoint 2010 deployment bug that took us 2 days to solve, we could have completed all investigations and required changes in 2 or 3 days.

To cut a rather long story short, a beta version of the PDF Converter for SharePoint 2010 is now available. Please contact us if you want to participate in the beta program. Note that the download available on our website is the SharePoint 2007 version, which will not work with SharePoint 2010.

Although the beta is fully functional and integrates nicely with new SharePoint 2010 features such as the Ribbon, the documentation has not yet been updated. Fortunately, much - including the installation process - is the same. The only difference is the location of some of the administrative screens as highlighted in the screenshots below.

Over the next week we will release a number of blog posts describing our experience with porting a SharePoint 2007 WSPBuilder application to SharePoint 2010 and making the same code base work with both versions. If you are interested in this topic then make sure you subscribe to our RSS feed or follow us on Twitter.

Access the PDF Converter Configuration screen via General Application Settings

  The PDF Converter integrates with the new Ribbon bar

  After installing the License Manager, it can be opened from the System Settings screen

The new version is compatible with SharePoint Designer 2010 workflows

.

Labels: Articles, News, PDF Converter, Products, SP2010, Workflow

Posted at: 3:53 PM on 24 February 2010 by Muhimbi

Earlier today we released a new version of our popular PDF Converter for SharePoint. One of the key changes in this version is that it fully supports Office 2010 file formats, including all new formatting features such as Excel 2010 Sparklines.

Full installation details are provided in Appendix – Office 2010 Installation of the Administration Guide, however one detail is so essential that we feel we have to repeat it in this blog post. After all, who reads boring documentation anyway?

The single most important thing to take away from this post is that no matter what CPU architecture you deploy the PDF Converter on, if you plan to use Office 2010 to carry out the conversions then you should always install the 32 bit version of Office 2010.

Even though the Muhimbi PDF Converter for SharePoint is a hybrid 32 / 64 bit application, the 64 bit version of Office will not work in combination with our software. Even if it did, it would provide little to no benefit.

For more details about the differences between the 32 and 64 bit versions of Office, including Microsoft’s recommendation to run the 32-bit version of Office 2010 on 64 bit hardware, read this article on Microsoft’s Office 2010 blog.

.

Labels: Articles, PDF Converter, Products

Posted at: 2:29 PM on by Muhimbi

Ah, those pesky customers of ours, always looking for some niche functionality that is impossible to include in a generic product. However, using the Workflow Power Pack for SharePoint we can achieve almost anything we can think of…..almost.

Previously I described how to configure PDF Security settings from a SharePoint workflow and how to automatically watermark PDF files from a workflow.  This time I’ll show how to add JavaScript to any PDF file to automatically print the current date (the date the PDF was opened) on every page. In essence this adds a print date without modifying the PDF file every day to include the current date.

A quick introduction for those not familiar with the product: The Muhimbi Workflow Power Pack for SharePoint allows custom C# or VB.NET code to be embedded in SharePoint Designer Workflows without the need to resort to complex Visual Studio based workflows, the development of bespoke Workflow Activities or long development cycles.

The solution presented below executes a workflow whenever a PDF file is added or updated. It iterates over all pages and inserts a form field on each page. Some client side JavaScript is then added to the PDF file that iterates over all newly added fields to insert the current date every time the PDF file is opened.

As the code is well documented it is easy to make further changes and customisations, e.g. change the formatting of the date or position of the label. Note that this has only been tested with a recent version of Adobe Acrobat reader. If you use a different PDF viewer your mileage may vary.

 
Create the workflow as follows:

1. Download and install the Muhimbi Workflow Power Pack for SharePoint.
    
2. Download and install the Muhimbi PDF Converter for SharePoint.
   Note that you need version 3.2.0.20 or newer, older versions do not allow JavaScript to be inserted.
    
3. Download this article’s source code.
    
4. We need to be able to access functionality in the Muhimbi.SharePoint.DocumentConverter.PDF and System.Drawing assemblies. Add these references to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration Guide. Make sure to place each reference on a new line.
     
5. Make sure you have the appropriate privileges to create workflows on a site collection.
    
6. Create a new workflow using SharePoint Designer.
    
7. On the Workflow definition screen associate the workflow with the Shared Documents library, tick the boxes next to both ‘Automatically start….’ options and proceed to the next screen.
    
8. We only want to act on files of type PDF. Although we could have put this validation in the code, in this example we use a workflow condition for it so add a Compare Any Data Source condition and:
    
   a.  Click on the first value followed by the display data binding (fx) button.
   b.  Select Current Item as the Source and select File Type in the Field. Click the OK button to continue.
   d.  Click on the second value and enter pdf.
    
9. Click the Actions button and insert the Execute Custom Code action.
    
10. Optionally click parameter 1 and enter a relative or absolute destination path. Leave the parameter empty to save the modified file on top of the existing PDF file. For details about how paths are handled, see this post and search for the words ‘this url’.
     
11. Insert the C# based code embedded in step #3’s download (also listed below) by clicking this code.
     

    /*********************************************************************************************

                            Muhimbi PDF Converter - JavaScript Watermarking

                  Copyright 2010, Muhimbi Ltd - www.muhimbi.com - All rights reserved

     The following code shows a simple way of adding JavaScript to existing PDF Files. It adds 

     the current date to each page in the document in order to simulate a 'print date' that is

     always up to date without the need to modify the PDF file. The code is automatically executed 

     when the document is opened in the Adobe Acrobat Viewer.

     Error and permission checking as well as other minor features have been omitted for the sake 

     of brevity and clarity.

     Ideally PDF Conversion, applying security and watermarking is executed in the same step, see 

     http://www.muhimbi.com/blog/2010/01/configure-pdf-security-from-sharepoint.html

     This code requires Muhimbi’s PDF Converter and Workflow Power Pack to be installed.

    *********************************************************************************************/

    using System.Drawing;

    using System.IO;

    using Syncfusion.Pdf;

    using Syncfusion.Pdf.Parsing;

    using Syncfusion.Pdf.Graphics;

    using Syncfusion.Pdf.Interactive;

    using Muhimbi.SharePoint.DocumentConverter.PDF;

    SPFile spSourceDocument = MyWorkflow.Item.File;

    string destinationFileName = spSourceDocument.Name;

    string destinationFolderName = MyWorkflow.Parameter1 as string;

    // ** Load the document

    PdfLoadedDocument sourceDocument = new PdfLoadedDocument(spSourceDocument.OpenBinary());

    PdfDocument destinationDocument = new PdfDocument();

    // ** Copy all pages from the source document into the destination document 

    // ** so we can add JavaScript actions.

    destinationDocument.ImportPageRange(sourceDocument, 0, sourceDocument.Pages.Count - 1);

    sourceDocument.Dispose();

    // ** Iterate over all pages and add a form element

    for (int i = 0; i < destinationDocument.Pages.Count; i++)

    {

        PdfPage destinationPage = destinationDocument.Pages[i];

        // ** Create a new field using a unique name

        PdfTextBoxField field = new PdfTextBoxField(destinationPage, "_M_PrintDateField_" + i);

        // ** Center the field

        const int BOX_WIDTH = 200;

        int boxLeft = (int)((destinationPage.Size.Width - BOX_WIDTH) / 2);

        field.Bounds = new RectangleF(boxLeft, 20, BOX_WIDTH, 20);

        // ** Format the field

        PdfFont font = new PdfStandardFont(PdfFontFamily.Helvetica, 12f);

        field.Font = font;

        field.BorderColor = new PdfColor(Color.White);

        field.BackColor = new PdfColor(Color.White);

        field.ReadOnly = true;

        field.TextAlignment = PdfTextAlignment.Center;

        destinationDocument.Form.Fields.Add(field);

    }

    // ** Create a client side script that iterates over all fields and populates the date

    string jscript = @"

            var pages = " + destinationDocument.Pages.Count + @";

            var today = util.printd('dd-mm-yyyy', new Date());

            for(var i=0; i<pages; i++)

            {

                var field = this.getField('_M_PrintDateField_' + i);

                field.value = 'Today is: ' + today;

            }

            ";

    // ** Attach the script to the Document Open event.

    PdfJavaScriptAction jsAction = new PdfJavaScriptAction(jscript);

    destinationDocument.Actions.AfterOpen = jsAction;

    // ** Construct the path and file to write the watermarked PDF file to.

    if (string.IsNullOrEmpty(destinationFolderName) == true)

        destinationFolderName = spSourceDocument.ParentFolder.Url;

    SPFolder destinationFolder = Utility.GetSPFolder(destinationFolderName, MyWorkflow.Web);

    string destinationFilePath = string.Format("{0}/{1}", destinationFolder.Url,

                                               destinationFileName);

    SPWeb destinationWeb = destinationFolder.ParentWeb;

    SPFile spDestinationFile = destinationWeb.GetFile(destinationFilePath);

    // ** If a document library requires manual checkout and the file is not checked out, then 

    // ** check the file out before uploading.

    if (spDestinationFile.Exists && spDestinationFile.Item.ParentList.ForceCheckout &&

        spDestinationFile.CheckOutStatus == SPFile.SPCheckOutStatus.None)

    {

        spDestinationFile.CheckOut();

    }

    // ** Add the file to the site including the meta data

    using (MemoryStream watermarkedFile = new MemoryStream())

    {

        destinationDocument.Save(watermarkedFile);

        spDestinationFile = destinationWeb.Files.Add(destinationFilePath, watermarkedFile,

                                                     spSourceDocument.Item.Properties, true);

    }

    // ** Check the file back in if this script was responsible for checking it out.

    if (spDestinationFile.Item.ParentList.ForceCheckout == true)

    {

        spDestinationFile.CheckIn("Auto check-in after PDF watermarking.");

    }

     
12. Click the Actions button, select Log to History List, click this message and enter File watermarked.
     
13. Close the Workflow Designer.
     
14. Update an existing PDF or add a new PDF file to your library to trigger the workflow and apply the JavaScript.

  
Naturally this is just a simple example. Feel free to play around with the code, change which parameters are passed into the workflow, or add different JavaScript. Note that you may want to add a check to the code to check if the JavaScript / fields have previously been added, otherwise duplicate form fields may be added every time the PDF is updated.

Adobe’s JavaScript for Acrobat reference can be found here.

.

Labels: Articles, PDF Converter, Products, Workflow, WPP

Posted at: 11:02 AM on by Muhimbi

We are very excited to announce the new version of the Muhimbi PDF Converter for SharePoint. The main change in this version is support for Office 2010 based converters and file formats.

We are quite surprised by the number of customers asking for Office 2010 support, especially considering that at the time of writing it is still in beta. On the other hand, it appears to be very stable and particularly the improvements in converting InfoPath forms to PDF format make it worth considering.

For those not familiar with the product, the PDF Converter for SharePoint is a lightweight solution that allows end-users to convert common document types to PDF format from within SharePoint without the need to install any client side software or Adobe Acrobat. 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, French and Japanese. For detailed information check out the product page. 

The main changes in version 3.2 are as follows:

For more information check out the following resources:

• Product Page.
• FAQ.
• Release Notes.
• Administration Guide.
• User Guide.
• Screenshots.
• Message Board.

 
As always, feel free to contact us using Twitter, our Blog, regular email or subscribe to our newsletter.

Download your free trial here (4MB).
.

Labels: News, PDF Converter, Products

Posted at: 11:36 AM on 04 February 2010 by Muhimbi

As most of our products can be used from a SharePoint workflow, it is perhaps useful to know how to tweak SharePoint’s workflow engine for high-load or other specific scenarios.

This article explains in detail what can be tuned and how it can be tuned. If you are in a rush then you can skip over the first 20%.

In summary:

• Workflow Throttle: Controls how many workflows can be processing at any one time on the entire server farm. This setting does not control how many workflows can be "In Progress" concurrently, but rather how many can be actively using the processor. When this number is exceeded, workflow instances that are started and events that wake up dehydrated workflows are queued for later processing. The default value is 15. This setting is per farm, so the number of front-end Web servers is irrelevant
  
  stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv "25"
   
   
• Workflow Batch Size: Workflows, by their very nature, do not execute in a nonstop, linear fashion. Instead, they run for a little while, pause, run some more, and then pause again, continuing in this manner until the process is complete. Although an outside observer or a developer might disagree, workflows are a collection of batches and the workflow engine is simply a glorified batch controller.
  
  stsadm -o setproperty -pn workitem-eventdelivery-batchsize -pv "125"
   
   
• Workflow Timeout: The timeout setting specifies the amount of time (in minutes) in which a workflow timer job must complete before it is considered to have stopped responding and is forced to stop processing. Jobs that time out are returned to the queue to be reprocessed later. The default timeout period is five minutes
  
  stsadm -o setproperty -pn workflow-eventdelivery-timeout -pv "10"
   
   
• Workflow Timer Interval: The workflow timer interval specifies how often the workflow SPTimer job fires to process pending workflow tasks. This interval also represents the granularity of delay timers within your workflow. If a timer is set to delay for one minute, but the interval timer fires only every five minutes, the workflow delays for five minutes, not one minute
  
  stsadm -o setproperty -pn job-workflow -pv value -url http://myWssServer
   

For our products you may need to tweak Workflow Timeout for very long running PDF Conversions. Changing the Timer Interval can be useful during development when using Pause Until or Pause For workflow Activities.

.

Labels: Articles, MuSH, PDF Converter, Workflow, WPP

Posted at: 12:18 PM on 26 January 2010 by Muhimbi

We get a great amount of interest from our existing PDF Converter customers for the Workflow Power Pack for SharePoint. I am not really surprised as there is a lot of of synergy between the two.

Last week I described how to configure PDF Security settings from a SharePoint workflow. This time I’ll describe another common request; adding a watermark to a PDF File.

A quick introduction for those not familiar with the product: The Muhimbi Workflow Power Pack for SharePoint allows custom C# or VB.NET code to be embedded in SharePoint Designer Workflows without the need to resort to complex Visual Studio based workflows, the development of bespoke Workflow Activities or long development cycles.

The solution presented below executes a workflow whenever a PDF file is added or updated. As part of the workflow it loads portrait and landscape based watermarks and applies the relevant template to each page of the document. The workflow author can specify if the watermark goes in the foreground or the background, the SharePoint location of the watermarks as well as the level of transparency. As the code is well documented it is easy to make further changes and customisations, e.g. the PDF file that needs to be watermarked may not be the file the workflow is acting on.

 
Create the workflow as follows:

1. Download and install the Muhimbi Workflow Power Pack for SharePoint.
    
2. Download and install the Muhimbi PDF Converter for SharePoint.
   Note that you need version 3.1.2.18 or newer, older versions do not allow watermarking.
    
3. Download this article’s source code and sample watermarks.
    
4. We need to be able to access functionality in the Muhimbi.SharePoint.DocumentConverter.PDF and System.Drawing assemblies. Add these references to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration Guide. Make sure to place each reference on a new line.
     
5. Make sure you have the appropriate privileges to create workflows on a site collection.
    
6. Create a new workflow using SharePoint Designer.
    
7. On the Workflow definition screen associate the workflow with the Shared Documents library, tick the boxes next to both ‘Automatically start….’ options and proceed to the next screen.
    
8. We only want to act on files of type PDF. Although we could have put this validation in the code, in this example we use a workflow condition for it so add a Compare Any Data Source condition and:
    
   a.  Click on the first value followed by the display data binding (fx) button.
   b.  Select Current Item as the Source and select File Type in the Field. Click the OK button to continue.
   d.  Click on the second value and enter pdf.
    
9. Click the Actions button and insert the Execute Custom Code action.
    
10. Optionally click parameter 1 and enter a relative or absolute destination path. Leave the parameter empty to save the watermarked file on top of the existing PDF file. For details about how paths are handled, see this post and search for the words ‘this url’.
     
11. Insert the C# based code embedded in step #3’s download (also listed below) by clicking this code.
     

    /*********************************************************************************************

                                 Muhimbi PDF Converter - Watermarking

                  Copyright 2010, Muhimbi Ltd - www.muhimbi.com - All rights reserved

     The following code shows a simple way of adding a watermark to existing PDF Files. 

     Error and permission checking as well as other minor features have been omitted for the sake 

     of brevity and clarity.

     Ideally PDF Conversion, applying security and watermarking is executed in the same step, see 

     http://www.muhimbi.com/blog/2010/01/configure-pdf-security-from-sharepoint.html

     This code requires Muhimbi’s PDF Converter and Workflow Power Pack to be installed.

    *********************************************************************************************/

    using System.Drawing;

    using System.IO;

    using Syncfusion.Pdf;

    using Syncfusion.Pdf.Parsing;

    using Syncfusion.Pdf.Graphics;

    using Muhimbi.SharePoint.DocumentConverter.PDF;

    SPFile spSourceDocument = MyWorkflow.Item.File;

    string destinationFileName = spSourceDocument.Name;

    string destinationFolderName = MyWorkflow.Parameter1 as string;

    string watermarkDocumentPortraitPath = @"Shared Documents/Watermarks/WatermarkA4Portrait.pdf";

    string watermarkDocumentLandscapePath = @"Shared Documents/Watermarks/WatermarkA4Landscape.pdf";

    // ** z-order and transparency of the watermark

    bool watermarkInBackground = true;

    float watermarkTransparancy = 0.25f;

    // ** Load the document and watermarks

    PdfLoadedDocument sourceDocument = new PdfLoadedDocument(spSourceDocument.OpenBinary());

    SPFile spWatermarkDocumentPortrait = MyWorkflow.Web.GetFile(watermarkDocumentPortraitPath);

    PdfLoadedDocument watermarkDocumentPortrait = new PdfLoadedDocument(

                                                    spWatermarkDocumentPortrait.OpenBinary());

    SPFile spWatermarkDocumentLandscape = MyWorkflow.Web.GetFile(watermarkDocumentLandscapePath);

    PdfLoadedDocument watermarkDocumentLandscape = new PdfLoadedDocument(

                                                    spWatermarkDocumentLandscape.OpenBinary());

    // ** Create the PDF Templates

    PdfTemplate watermarkTemplatePortrait = watermarkDocumentPortrait.Pages[0].CreateTemplate();

    PdfTemplate watermarkTemplateLandscape = watermarkDocumentLandscape.Pages[0].CreateTemplate();

    // ** Iterate over all pages and apply watermark

    foreach (PdfPageBase page in sourceDocument.Pages)

    {

        // ** Is the current page portrait or landscape?

        PdfTemplate watermarkTemplate = null;

        if (page.Size.Width > page.Size.Height)

            watermarkTemplate = watermarkTemplateLandscape;

        else

            watermarkTemplate = watermarkTemplatePortrait;

        // ** Place watermark behind or in front of text?

        if (watermarkInBackground == true)

        {

            PdfTemplate pageTemplate = page.CreateTemplate();

            page.Layers.Clear();

            PdfGraphics g = page.Graphics;

            g.SetTransparency(watermarkTransparancy);

            g.DrawPdfTemplate(watermarkTemplate, PointF.Empty, page.Size);

            g.SetTransparency(1f);

            g.DrawPdfTemplate(pageTemplate, PointF.Empty, page.Size);

        }

        else

        {

            PdfGraphics g = page.Graphics;

            g.SetTransparency(watermarkTransparancy);

            g.DrawPdfTemplate(watermarkTemplate, PointF.Empty, page.Size);

        }

    }

    // ** Construct the path and file to write the watermarked PDF file to.

    if (string.IsNullOrEmpty(destinationFolderName) == true)

        destinationFolderName = spSourceDocument.ParentFolder.Url;

    SPFolder destinationFolder = Utility.GetSPFolder(destinationFolderName, MyWorkflow.Web);

    string destinationFilePath = string.Format("{0}/{1}", destinationFolder.Url,

                                               destinationFileName);

    SPWeb destinationWeb = destinationFolder.ParentWeb;

    SPFile spDestinationFile = destinationWeb.GetFile(destinationFilePath);

    // ** If a document library requires manual checkout and the file is not checked out, then 

    // ** check the file out before uploading.

    if (spDestinationFile.Exists && spDestinationFile.Item.ParentList.ForceCheckout &&

        spDestinationFile.CheckOutStatus == SPFile.SPCheckOutStatus.None)

    {

        spDestinationFile.CheckOut();

    }

    // ** Add the file to the site including the meta data

    using (MemoryStream watermarkedFile = new MemoryStream())

    {

        sourceDocument.Save(watermarkedFile);

        spDestinationFile = destinationWeb.Files.Add(destinationFilePath, watermarkedFile,

                                                     spSourceDocument.Item.Properties, true);

    }

    // ** Check the file back in if this script was responsible for checking it out.

    if (spDestinationFile.Item.ParentList.ForceCheckout == true)

    {

        spDestinationFile.CheckIn("Auto check-in after PDF watermarking.");

    }

     
12. Click the Actions button, select Log to History List, click this message and enter File watermarked.
     
13. Close the Workflow Designer.
     
14. In the Shared Documents library create a sub folder named Watermarks and copy the 2 watermark files that are part of step #3’s download into it. If the watermarks are named differently or stored in a different location then update the paths in the script accordingly. Note that the sample watermarks are exactly A4 sized but they work fine on differently sized documents.
     
15. Update an existing PDF or add a new PDF file to your library to trigger the workflow and apply the watermarks.
     

Naturally this is just a simple example. Feel free to play around with the code, change which parameters are passed into the workflow, modify where watermarked files are written to or add dynamic text as a watermark. Leave a comment below if you are trying to do anything specific.

.

Labels: Articles, PDF Converter, Products, Workflow, WPP

Posted at: 12:03 PM on 22 January 2010 by Muhimbi

Any organisation that deals with computer software, free or otherwise, must be aware of the License Agreement that comes with a software product. How many computers can the software be used on, by how many users and how long is the license valid are only some of the questions that need to be answered.

We have invested quite some time in making our Software License Agreement readable for people without a legal background. However, it is difficult to cover all grounds using plain English.

This post attempts to explain the key elements of our Software Agreement in plain English. Note that this is only a summary and does not replace the actual License Agreement.

The following topics are discussed in this post:

• Summary of available licenses
• Renewing Licenses / Support licenses
• What servers / environments do you need a license for
• Licensing requirements for non SharePoint based deployments

Summary of available licenses

We use a graded licensing system to match your budget and exact needs. The following license types are available:
 

• Free evaluation version: If you install the software without a license then you are using the evaluation version. The software is fully functional without any time limits, but an evaluation message will be displayed on most screens and in any generated document. You are not permitted to use any evaluation software in your production environment. Support is provided using any of the means in the Support area on our site.
   
• Web Application License: This license is sold at a considerable discount to allow small organisations with just a single SharePoint server and Web Application to get started with our software. If you have a single SharePoint server then you can use this license on a single Web Application on as many Site Collections as you like.
   
• Web Farm License: If you have more than one server in your SharePoint farm or want to use our software on multiple Web Applications then you may want to consider this license. If you want to use our software on multiple farms or if your farm is spread over multiple geographical locations then you need either a Site or OEM license as described below.
   
• Site License: If you have multiple separate SharePoint Farms, for example when you are a hosting company, then this license may be the best option as it allows the software to be used on an unlimited number of separate SharePoint farms at a single location.
   
• OEM License: If your SharePoint Farm or Farms spreads multiple physical locations, e.g. across a data centre, Disaster recovery site and or local branch offices OR if you want to bundle our Software as part of your own solution then the OEM Subscription is most likely the best option. Please read the details in the Software License Agreement if you want to bundle our software with your own solution. Note that you are not allowed to use our Products to develop derived works that offer similar functionality as the Product or expose the features of the Product for use by an unlicensed third party unless agreed with Muhimbi.
   
• OEM License + Source Code: If you need all the benefits of the OEM License and / or you need access to the source code to make modifications specific to your organisation, then this license type is the best option. Note that we do not provide support for our software once changes have been made to the source code. Please read the details in the Software License Agreement if you want to bundle our software with your own solution. Note that you are not allowed to use our Products to develop derived works that offer similar functionality as the Product or expose the features of the Product for use by an unlicensed third party unless agreed with Muhimbi.

Renewing Licenses / Support licenses

Independent of the type of license purchased, you automatically receive a 1 year support license, which entitles you to free updates and access to our support desk using any of the means listed on the Contact Us page.

After the support license has expired your software will continue to work, but you can no longer download new versions released after the expiry of the license. You can renew your support license for 30% of the current retail price, which is not necessarily the price you originally bought the product for, although they may be the same.

What servers / environments do you need a license for

Licensing requirements for non SharePoint based deployments

Our products mainly focus on use from a SharePoint environment. However, some products can also be used from non SharePoint environments as well. For example, our PDF Conversion Service can run as a standalone service and be accessed from any application that supports Web Services.

The licenses are largely the same, with the exception of the Web Application License, which is only available for SharePoint based environments.

• Web Farm License: Get this license if you want to access our software from a single solution on an unlimited number of servers located at a single location, using an unlimited number of developers and end-users.
   
• Site License: If you intend to access our software from multiple solutions located on servers at the same site, then get this license.
   
• OEM License: If you want to access our software from servers spread across more than one physical location then get this license.
   
• OEM License + Source Code: If you need all the benefits of the OEM License and / or you need access to the source code to make modifications specific to your organisation, then this license type is the best option. Note that we do not provide support for our software once changes have been made to the source code. Please read the details in the Software License Agreement if you want to bundle our software with your own solution. Note that you are not allowed to use our Products to develop derived works that offer similar functionality as the Product or expose the features of the Product for use by an unlicensed third party unless agreed with Muhimbi.
   

I realise this post is almost longer than the License Agreement is is trying to explain, but I hope it clarifies our licensing position. If you have any further questions then please check out the following sources or contact us at licensing@muhimbi.com.

• License Agreement
• Licensing FAQ

.

Labels: Audit, MuSH, Partnering, PDF Converter, Products, WPP

Posted at: 4:10 PM on 20 January 2010 by Muhimbi

It has been exactly 2 months since we released a completely overhauled version of our PDF Converter for SharePoint. We are seeing a considerable increase in downloads as well as purchases, which means one thing….. increased customer feedback!

The new version of the software resolves the most urgent issues, removes a number of pain points that should make configuration for certain scenarios a lot easier, improves support for the more complex InfoPath forms and adds support for converting MS-Visio files as well as a number of related vector formats (vsd, vdx, svg, svgz, dwg, dxf).

For those not familiar with the product, the PDF Converter for SharePoint is a lightweight solution (4MB download) that allows end-users to convert common document types to PDF format from within SharePoint without the need to install any client side software or Adobe Acrobat. 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, French and Japanese. For detailed information check out the product page as well as the following blog postings:

• Using the PDF Converter from a SharePoint workflow.
• Configure PDF Security from a SharePoint Workflow.
• Inserting SharePoint List data into a PDF document using a workflow.
• Using the PDF Converter for SharePoint from your own code.
• Automatically convert files to PDF using an e-mail enabled SharePoint Document Library.
• Batch print InfoPath Forms using the PDF Converter for SharePoint.
• Converting Office files to PDF Format using a Web Services based interface.
• Troubleshooting steps for the PDF Converter for SharePoint.
• Troubleshooting InfoPath to PDF Conversion / Document Converter Architecture.
   

 
The main changes in version 3.1 are as follows:

For more information check out the following resources:

• Product Page.
• FAQ.
• Release Notes.
• Administration Guide.
• User Guide.
• Screenshots.
• Message Board.

 
As always, feel free to contact us using Twitter, our Blog, regular email or subscribe to our newsletter.

Download your free trial here (4MB).
.

Labels: News, PDF Converter, Products

Posted at: 4:35 PM on 15 January 2010 by Muhimbi

Our PDF Converter for SharePoint is getting great reviews, but naturally we cannot please everyone, or at least not yet. One of the requests we get from time to time is to add support for the ability to specify PDF Security settings (Open Password, Owner Password, Block Print, Block Copy etc).

The thing is, our underlying engine and Web Service interface already support this functionality. However, the user interface and workflow action have not yet been updated. In this article we describe how to access this ‘hidden’ functionality from a workflow using the Workflow Power Pack.

A quick introduction for those not familiar with the product: The Muhimbi Workflow Power Pack for SharePoint allows custom C# or VB.NET code to be embedded in SharePoint Designer Workflows without the need to resort to complex Visual Studio based workflows, the development of bespoke Workflow Activities or long development cycles.

The solution presented below automatically converts any updated or newly created files to PDF format and applies the DisablePrint and DisableContentCopy security flags to the file. As the code is well documented it is easy to make further changes and customisations.

 
Create the workflow as follows:

1. Download and install the Muhimbi Workflow Power Pack for SharePoint.
    
2. Download and install the Muhimbi PDF Converter for SharePoint.
    
3. We need to be able to access functionality in the Muhimbi.SharePoint.DocumentConverter.PDF, System.ServiceModel and System.Runtime.Serialization assemblies. Add these references to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration Guide. Make sure to place each reference on a new line.
     
4. Make sure you have the appropriate privileges to create workflows on a site collection.
    
5. Create a new workflow using SharePoint Designer.
    
6. On the Workflow definition screen associate the workflow with the library of your choice, tick the boxes next to both ‘Automatically start….’ options and proceed to the next screen.
    
7. To prevent the code from acting on files that are already in PDF format, add a Compare Any Data Source condition and:
    
   a.  Click on the first value followed by the display data binding (fx) button.
   b.  Select Current Item as the Source and select File Type in the Field. Click the OK button to continue.
   c.  Click equals and change it to not equals.
   d.  Click on the second value and enter pdf.
    
8. Click the Actions button and insert the Execute Custom Code action.
    
9. Click parameter 1 and optionally enter a relative or absolute destination path (For details see this post and search for the words ‘this url’). Leave the parameter empty to write the PDF file to the same directory as the source file.
    
10. Download the source code or insert the C# based code listed below by clicking this code.
     

    /********************************************************************************************

                                      Muhimbi PDF Converter

                  Copyright 2010, Muhimbi Ltd - www.muhimbi.com - All rights reserved

     The following code is a simplification of the code that is normally executed by the Muhimbi 

     PDF Converter Workflow Action. Error and permission checking as well as other minor features

     have been omitted for the sake of brevity and clarity.

     This code allows more control over the PDF Conversion process compared to what is possible 

     with the Out-Of-The-Box action, for example: PDF Security Options, Use of PDF/A, Quality, 

     Enable Macros and the ability to specify a password to open a source file.

     This code requires Muhimbi’s PDF Converter and Workflow Power Pack to be installed.

     For details about the Web Services interface see:

     http://www.muhimbi.com/blog/2009/12/converting-office-files-to-pdf-format.html

    ********************************************************************************************/

    using Muhimbi.SharePoint.DocumentConverter.PDF;

    using Muhimbi.SharePoint.DocumentConverter.PDF.WebServiceClient;

    using System.Collections;

    // ** Set all variables required for the conversion of the file.

    SPFile sourceFile = MyWorkflow.Item.File;

    // ** Specify an empty string or null to use the same directory as the source file. 

    // ** Alternatively specify an absolute or relative (to the web) path, e.g. 

    // ** subsite1/Shared Documents/PDF  or /sites/HumanResources/subsite1/Shared Documents/PDF

    string          destinationFolderName   = MyWorkflow.Parameter1 as string;

    string          destinationFileName     = Utility.ExtractFileName(sourceFile.Name) + ".pdf";

    string          openPassword            = "";

    string          ownerPassword           = "A Nice And Strong Password!";

    SecurityOptions securityOptions         = SecurityOptions.DisablePrint | 

                                              SecurityOptions.DisableContentCopy;

    bool            copyMetadata            = true;

    // ** Get a reference to the PDF Converter web service.

    DocumentConverterServiceClient client   = WebServiceConverterHelper.OpenService();

    //** Set the various open options

    OpenOptions openOptions                 = new OpenOptions();

    openOptions.Password                    = "";

    openOptions.OriginalFileName            = sourceFile.Name;

    openOptions.FileExtension               = Utility.ExtractFileExtension(sourceFile.Name);

    openOptions.AllowMacros                 = MacroSecurityOption.None;

    openOptions.RefreshContent              = true;

    //** Specify the various security settings

    ConversionSettings conversionSettings   = new ConversionSettings();

    conversionSettings.Fidelity             = ConversionFidelities.Full;

    conversionSettings.Format               = OutputFormat.PDF;

    conversionSettings.Quality              = ConversionQuality.OptimizeForPrint;

    conversionSettings.Range                = ConversionRange.VisibleDocuments;

    conversionSettings.StartPage            = 0;

    conversionSettings.EndPage              = 0;

    conversionSettings.GenerateBookmarks    = BookmarkGenerationOption.Automatic;

    conversionSettings.PDFProfile           = PDFProfile.PDF_1_5;

    // ** Specify either an Open or Owner Password in order to activate the security Options

    conversionSettings.OpenPassword         = openPassword;

    conversionSettings.OwnerPassword        = ownerPassword;

    conversionSettings.SecurityOptions      = securityOptions;

    // ** Read the content of the source file

    byte[] sourceFileArray = sourceFile.OpenBinary();

    // ** Carry out the actual conversion to PDF

    byte[] convertedFile = client.Convert(sourceFileArray, openOptions, conversionSettings);

    // ** Construct the path and file to write the PDF file to.

    if (string.IsNullOrEmpty(destinationFolderName) == true)

        destinationFolderName = sourceFile.ParentFolder.Url;

    SPFolder destinationFolder = Utility.GetSPFolder(destinationFolderName, MyWorkflow.Web);

    string destinationFilePath = string.Format("{0}/{1}", destinationFolder.Url, 

                                               destinationFileName);

    SPWeb destinationWeb = destinationFolder.ParentWeb;

    SPFile spDestinationFile = destinationWeb.GetFile(destinationFilePath);

    // ** If a document library requires manual checkout and the file is not checked out, then 

    // ** check the file out before uploading.

    if (spDestinationFile.Exists && spDestinationFile.Item.ParentList.ForceCheckout && 

        spDestinationFile.CheckOutStatus == SPFile.SPCheckOutStatus.None)

    {

        spDestinationFile.CheckOut();

    }

    // ** Copy metadata, if requested.

    if (copyMetadata == true && 

        sourceFile.Name.EndsWith("x", StringComparison.InvariantCultureIgnoreCase) == false)

    {

        // ** Pre office 2007 formats (without the trailing x) are treated differently 

        // ** from the office 2007 formats when it comes to copying meta data.

        Hashtable metadata = sourceFile.Item.Properties;

        // ** Add the file to the site including the meta data

        spDestinationFile = destinationWeb.Files.Add(destinationFilePath, convertedFile, 

                                                     metadata, true);

    }

    else if (copyMetadata == true)

    {

        // ** Add the file to the site.

        spDestinationFile = destinationWeb.Files.Add(destinationFilePath, 

                                                     convertedFile, null, true);

        // ** Copy the Actual meta data to the newly created file.

        foreach (SPField field in sourceFile.Item.Fields)

        {

            if (field.ReadOnlyField == false && 
                spDestinationFile.Item.Fields.ContainsField(field.InternalName) == true)

            {

                spDestinationFile.Item[field.InternalName] = sourceFile.Item[field.InternalName];

            }

        }

        // ** Update the meta data

        spDestinationFile.Item.Update();

    }

    else

    {

        // ** Actively strip all meta data

        Hashtable metadata = new Hashtable(sourceFile.Item.Properties.Count);

        foreach (Object key in sourceFile.Item.Properties.Keys)

        {

            metadata.Add(key, string.Empty);

        }

        // ** Add the file to the site with all meta data stripped

        spDestinationFile = destinationWeb.Files.Add(destinationFilePath, convertedFile, 

                                                     metadata, true);

    }

    // ** Check the file back in if this script was responsible for checking it out.

    if (spDestinationFile.Item.ParentList.ForceCheckout == true)

    {

        spDestinationFile.CheckIn("Auto check-in after PDF Conversion");

    }

     
11. Click the Actions button, select Log to History List, click this message and enter File converted to PDF.
     
12. Close the Workflow Designer and update or add an item to your library to trigger the workflow.
     

 
Naturally this is just a simple example. Feel free to play around with the code, change which parameters are passed into the workflow or modify where converted PDF files are written to.

.

Labels: Articles, PDF Converter, Products, Workflow, WPP