One of the most common (sub) tasks executed from a SharePoint workflow is the submission of an email. SharePoint ships with an Email Workflow Action out of the box, which is unfortunately very limited in its abilities. For example, it is not possible to include attachments, specify the From Address, set the Priority or specify the SMTP server to use.
In this blog post I’ll describe how to send an email from a workflow that automatically includes all files / attachments for the current item from a SharePoint Designer 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.
Please note that this tutorial was originally written for SharePoint 2007. In newer versions of SharePoint please replace the ‘Build Dynamic String’ action with the ‘Set Workflow Variable’ action. Some familiarity with building basic workflows in SharePoint Designer and SharePoint programming in C# is required. Please see the Workflow Power Pack User Guide series for more details.
The solution presented below uses the standard Build Dynamic String Action to create the body of the email. This body is then passed as Parameter 1 to the Execute Custom Code Action. Parameter 2 is used to specify the To Address. This code is a great starting point for further customisation. For more details see the standard .net MailMessage and SmtpClient classes.
Make sure you have the appropriate privileges to create workflows on a site collection.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with the list or library of your choice, tick the boxes next to both ‘Automatically start… ’ items and proceed to the next screen.
Click the Actions button and insert the Build Dynamic String action.
Click dynamic stringand enter an HTML based email.
Click variable1 and create a new string based variable named mailMessage.
Click the Actions button and insert the Execute Custom Code action.
Click parameter 1, open the Workflow Lookup dialog and select Source: Workflow Data, Field: mailMessage.
Click parameter 2 end enter the address to send the email to. Naturally this could be a lookup value as well.
Insert the following C# based code by clicking this code.
When we released the Muhimbi URL Shortener for SharePoint, we knew that even though it was a great product, we couldn’t please everyone. For example, all generated Short URLs point to list items’ Form View, from where the item can be edited, deleted or opened in an external application. This behaviour is by design, but some customers prefer to have the short URL point directly to the file, e.g. a Generated PDF.
In this article we describe how to generate a short URL from a SharePoint Designer workflow with full control over which view the URL points to using both MuSH and 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 creates a short URL for the current item the workflow is acting on. An optional value can be specified in Parameter 1 to control if the generated URL points to the file or display form using the ‘displayform’ and ‘file’ values.
We need to be able to access functionality in the Muhimbi.SharePoint.URLShortener assembly. Add this reference to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration Guide.
Make sure you have the appropriate privileges to create workflows on a site collection.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with the list or library of your choice, tick the box next to ‘Automatically start this workflow when a new item is created’ and proceed to the next screen.
Click the Actions button and insert the Execute Custom Code action.
Click this variable and create a new Workflow Variable named shortURL using string as the type.
Click parameter 1 and enter file or displayform or leave it empty to default to displayform.
Insert the following C# based code by clicking this code.
using Muhimbi.SharePoint.URLShortener;
// ** Where do we want the shortened URL to point to?
Click the Actions button, select Log to History List, click this message, set the Source to Workflow Data and the Field to shortURL.
Close the Workflow Designer and add an item to your list or library to trigger the workflow.
Once the workflow has finished, click the Completed link to see the generated short URL.
Naturally this is just a simple example. Under normal circumstances you would do something more useful with the shortURL workflow variable, for example embed it in an email.
When I worked in the SharePoint team for a London based financial firm, one of the first user requests that came up was to find an easy way to synchronise team calendar entries with a department level calendar.
There are a number of ways to approach the automatic synchronisation of lists (a Calendar is just a SharePoint list). In this posting I will discuss how to synchronise any source list with a destination list, with the Exception of Document Libraries, using the Muhimbi Workflow Power Pack and a small script.
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.
Before developing the script we have to think about our approach as the synchronisation of list items involves both adding new items as well as updating existing ones. In order to be able to update an item we need to somehow track which item in the destination list is a copy of an item in the source list. As SharePoint does not provide an easy way to track this kind of information (The CopySource field is read only, sigh) the script will need to create a new and hidden field on the destination list to track an item’s origin.
The solution presented below allows any two lists to be synchronised in one direction (Source List to Destination List). The name of the Destination List is passed using Parameter 1. Only those fields available in both the source and destination lists will be copied over so there is no need for the two lists to have exactly the same content type. The very first time the script is executed, a new hidden field will be created on the Destination List, so make sure you execute the first run using an account that has the appropriate privileges to add columns to the list.
// ** Remember where the original was copied from so we can update it in the future
newItem["_M_CopySource"] = sourceItem["FileRef"];
newItem.Update();
Close the Workflow Designer and add an item to the source list to trigger the workflow.
Once the workflow has finished, open the destination list and verify the source item has been copied over.
As mentioned previously, it should be possible to use this script on any list with the exception of Document Libraries. Synchronising Document Libraries can be done using a similar approach, but copying an item works slightly different.
The script in this post assumes the destination list lives in the same site as the source list. This, however, can be easily changed by referencing the desired list in line 2 of the code.
You may want to add a condition to only synchronise list items that match certain criteria (e.g. status = completed).
Quite a few of our customers use a SharePoint Designer workflow to automatically create PDF files whenever a document is created or modified in a SharePoint Document Library. Some of these customers want to use the same directory structure for the source files as well as the converted files.
The problem that we’ll address in this posting is how to automatically synchronise the two directory structures using the Muhimbi Workflow Power Pack and a small script.
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 script we’ll develop is executed every time a file is created anywhere in a document library. The file’s path will be extracted and replicated in the destination Document Library. Ideally we would only like to trigger this workflow whenever a new folder is created, but using SharePoint designer it is not possible to trigger workflows for folders.
At the end of the custom activity the destination path is returned to the workflow, from where it can be used for further processing.
Make sure you have the appropriate privileges to create workflows on a site collection.
Create a source and destination Document Library. Alternatively use the same Document Library for the source and the destination, just create a new folder in the root to mirror the folder structure to.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with the Source Document Library and tick the box next to “Automatically start this workflow when a new item is created” and proceed to the next screen.
Click the Actions button and insert the Execute Custom Code action.
Click this variable and create a new Workflow Variable named destinationPath using string as the type.
Insert the following C# based code by clicking this code.
SPList sourceList = MyWorkflow.List;
// ** The destination Document Library (optionally point it to a different site collection)
Update the destinationList and rootFolderName variables to match your situation.
Click the Actions button, select Log to History List, click this message, set the Source to Workflow Data and the Field to destinationPath.
Close the Workflow Designer and add an item somewhere in a nested folder in the source Document Library to trigger the workflow.
Once the workflow has finished, click the Completed link to see which path the new folder has been created in. Check that the destination folder(s) have been created by navigating to the Destination Library.
In case you want to use this in combination with Muhimbi’s PDF Converter for SharePoint then you can use the path returned in the destinationPath variable and use it as the destination URL in the Convert To PDF workflow activity. If you want to use it in combination with something else, then use it as you see fit.
Note that a small change may be required to the script, or perhaps as a Custom Code Condition, if the source and destination Document Libraries are the same and files will be written to the location specified in rootFolderName. Otherwise the folder structure inside the destination folder will be mirrored in the destination folder, just at a deeper level.
In part 3 of our series of User Guide related blog postings for the Muhimbi Workflow Power Pack for SharePoint we provide an example of how to embed c# or vb code directly into a SharePoint Designer Workflow Action.
A quick introduction In case you are 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 following Blog postings are part of this User Guide series:
Language Features: Discusses the script like syntax, the generic workflow action and condition, passing parameters, returning values from a workflow and using the MyWorkflow property.
Embedding .net code in a Workflow Condition: Provides a number of examples of how to use the Evaluate Custom Code condition to carry out basic as well as complex conditional tasks.
Embedding .net code in a Workflow Action (this article): Contains a number of examples of how to use the Execute Custom Code to basically carry out any action you can think of in a SharePoint Designer Workflow.
Creating Custom Methods: Shows how to create your own methods in your scripts in order to keep the code organised and easy to maintain.
SharePoint ships with a number of Workflow Actions to carry out basic tasks such as setting the value of an item or sending an email. However, if you need to do something slightly different that is not supported by any of the stock actions, you need to resort to expensive third party utilities that may match some of your requirements, but probably not all of them.
This section describes how to use the Muhimbi Workflow Power Pack to implement your exact requirements without any limits or dependencies on third party logic. See part 2 of this series for another example that automatically renames a file based on keywords in its name.
Reading a SQL Database using a Workflow Action
Although SharePoint can be used to store much of your data, in reality a typical enterprise stores data in all kind of formats and data stores.
In this example we’ll discuss how to use the Muhimbi Workflow Power Pack to retrieve data stored in a SQL Server Database. The example is not particularly practical as we just read a group name out of the SharePoint Content Database, however the same principle can be used for any database.
To create this workflow, carry out the following steps:
We need to be able to access functionality in the System.Data assembly. Add this reference to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration Guide.
Make sure you have the appropriate privileges to create workflows on a site collection.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with your list of choice (any list will do), tick the two “automatically start” check boxes and proceed to the next screen.
Click the Actions button and insert the Execute Custom Code action.
Click this variable and create a new Workflow Variable named groupName using string as the type.
Insert the following C# based code by clicking this code.
using System.Data.SqlClient;
// ** Get the connection string for the content DB
In part 2 of our series of User Guide related blog postings for the Muhimbi Workflow Power Pack for SharePoint we provide a number of examples of how to embed c# or vb code directly into a SharePoint Designer Workflow Condition.
A quick introduction In case you are 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 following Blog postings are part of this User Guide series:
Language Features: Discusses the script like syntax, the generic workflow action and condition, passing parameters, returning values from a workflow and using the MyWorkflow property.
Embedding .net code in a Workflow Condition (this article): Provides a number of examples of how to use the Evaluate Custom Code condition to carry out basic as well as complex conditional tasks.
Embedding .net code in a Workflow Action: Contains a number of examples of how to use the Execute Custom Code to basically carry out any action you can think of in a SharePoint Designer Workflow.
Creating Custom Methods: Shows how to create your own methods in your scripts in order to keep the code organised and easy to maintain.
SharePoint ships with a number of Workflow Conditions to carry out basic comparisons inside your SharePoint Designer workflows. However, these Conditions are limited in scope and mainly facilitate simple comparisons of workflow variables.
This post describes how to use the Muhimbi Workflow Power Pack to write your own conditional logic in c# and embed it directly into your SharePoint Designer workflow.
The following example shows how to check if a document’s file name contains a reference to a highly confidential project (Project Flames). If it does then the document will be renamed automatically.
To create this workflow, carry out the following steps:
Make sure you have access to a Document Library in a site collection and the appropriate privileges to design a workflow on that site collection.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with your Document Library, tick the two “automatically start” check boxes and proceed to the next screen.
Click the Conditions button and insert the Evaluate Custom Code condition.
Insert the following C# based code by clicking code and then the ellipsis (…) button.
if (MyWorkflow.Item.Name.IndexOf("Flames", StringComparison.CurrentCultureIgnoreCase) >= 0)
{
MyWorkflow.ReturnValue = true;
}
else
{
MyWorkflow.ReturnValue = false;
}
Add the Execute Custom Code Action and insert the following code by clicking this code and pasting the following.
Close the workflow designer. This will automatically check the syntax of the code embedded in the Custom Action.
The workflow is now ready to be executed. Upload a file named “Project Flames Hostile Takeover.docx” and watch it being renamed automatically.
In this simple example we could have merged the conditional code into the Action. However that would not work with more complex workflows where the Action does not necessarily contain our own custom code.
As we have access to the full power of the .net framework, there are very few limitations to how complex the conditional code can be. In the following example we will check the value of a field stored deeply in an XML Document generated by InfoPath. To be more specific, if any of the items in the Expense claim form were filed for a day in the weekend then we will send an email to John the Expenses Manager.
Naturally this conditional logic could have been added inside the validation of the InfoPath form itself. However, that would require access to Tom the InfoPath Expert and Tom is very busy and going on holiday tomorrow. In other words, we will need to be creative.
To create this workflow, carry out the following steps:
We need to be able to access functionality in the System.XML assembly. Add this reference to the relevant Web Application using the Workflow Power Pack Central Administration screens as described in the Administration guide.
Make sure you have the appropriate privileges to create Form Libraries and design workflows on a site collection.
Open InfoPath, select Customize a Sample followed by Sample - Expense Report.
Select Publish from the File menu, save the form anywhere on your local system and complete the wizard to publish it to a new Document Library named Expense Forms in your site collection. There is no need to expose any columns to SharePoint.
In the Expense Forms Document Library fill out the form, enter one expense in a weekend and make sure you save it to the Document Library. Don’t submit it as that will go via email.
Create a new workflow using SharePoint Designer.
On the Workflow definition screen associate the workflow with your new Expense Forms Document Library, tick the two “automatically start” check boxes and proceed to the next screen.
Click the Conditions button and insert the Evaluate Custom Code condition.
Insert the following C# based code by clicking code and then the ellipsis (…) button.
using System.Xml;
using System.IO;
// ** Innocent until proven guilty
MyWorkflow.ReturnValue = false;
XmlDocument doc = new XmlDocument();
// ** Load the XML Form data out of the current item
using(Stream s = MyWorkflow.Item.File.OpenBinaryStream())
{
doc.Load(s);
// ** Make sure we can query the namespaces properly.
XmlNamespaceManager xnsm = new XmlNamespaceManager(doc.NameTable);
Even though we have only recently released the Muhimbi Workflow Power Pack for SharePoint, we are already getting good feedback from users. Most of the questions we get are already covered in the User Guide, which is why we have decided to republish the user guide as a series of blog postings.
A quick introduction In case you are 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 following Blog postings are part of this User Guide series:
Language Features (this article): Discusses the script like syntax, the generic workflow action and condition, passing parameters, returning values from a workflow and using the MyWorkflow property.
Embedding .net code in a Workflow Condition: Provides a number of examples of how to use the Evaluate Custom Code condition to carry out basic as well as complex conditional tasks.
Embedding .net code in a Workflow Action: Contains a number of examples of how to use the Execute Custom Code to basically carry out any action you can think of in a SharePoint Designer Workflow.
Creating Custom Methods: Shows how to create your own methods in your scripts in order to keep the code organised and easy to maintain.
Script Like Syntax
To allow code to be entered in an easy fashion, without needing to worry about namespaces, class or method names, the WPP takes a script like approach. In essence the person designing the workflow can just enter a single line of code and the WPP will make sure it is wrapped in the appropriate class.
Even though the traditional structure of a typical C# or VB.net file is not used, it is still possible to add shortcuts to namespaces by adding Using (c#) or Imports (VB) statements to the top of the code.
Note that in order to use System.XML, a reference will need to be added in Central Admin. For details see the Administration Guide
Workflow Action Structure
When adding a new Execute Custom Code action to a workflow you are presented with the following workflow sentence.
The fields are as follows.
Field
Type
Description
this code
Text
The C# or VB.net code to execute.
Language
C# or VB
The language the code is written in.
parameter 1
Object
An optional parameter to pass to the workflow.
parameter 2
Object
Another optional parameter to pass to the workflow.
this variable
Object
An optional workflow parameter to fill with the result.
Enter an optional comment
Text
An optional summary of what the code does.
Workflow Condition structure
When adding an Evaluate Custom Code Condition to a workflow, you are presented with the following.
The fields are as follows.
Field
Type
Description
this code
Text
The C# or VB.net code to execute.
Language
C# or VB
The language the code is written in.
parameter 1
Object
An optional parameter to pass to the condition.
parameter 2
Object
Another optional parameter to pass to the condition.
Enter an optional comment
Text
An optional summary of what the code does.
A condition should always evaluate to either True or False.
Passing values and Parameters
Workflow parameters and other values can be passed to the custom code in a number of ways.
Parameter 1 & 2: Use the Parameter 1 & 2 variables to pass a constant, workflow variable or any other kind of Workflow Lookup value. Note that these values are passed as type Object and may need to be cast into the correct data type in your code.
The Parameter1 and Parameter2 values can be accessed from the custom code using the MyWorkflow variable. For details see Using the MyWorkflow section below.
Embedding Workflow Lookup variables: Workflow Actions allow lookup variables to be directly embedded into the source code using the Add Lookup button.
At runtime all lookup variables are placed into the code as text, so please make sure that the generated syntax is still valid.
For example, the following code will not execute correctly:
String name = [%Variable: firstName%];
As this may result in the following code:
String name = John;
To solve this problem, add quotes around the variable as follows:
String name = "[%Variable: firstName%]";
Which will result in to following, syntactically correct, code:
String name = "John";
Note that SharePoint does not allow Workflow Lookups to be defined in the code for Custom Conditions as these are handled differently inside the workflow execution engine.
Returning Values
Variables or result values can be returned from your custom code by using the MyWorkflow.ReturnValue property.
Returning values using the return statement is not supported.
Using the MyWorkflow property
When developing workflows you frequently need access to data related to the workflow. To make accessing this data easy you can access the MyWorkflow property from your own code.
Represents the execution environment of an Activity. This class selectively exposes workflow runtime capabilities and services to individual activities.
// ** Pass the message back to the workflow for further processing
MyWorkflow.ReturnValue = message;
This is just an example. Rather than logging to the workflow history from your own code, you could simply pass the ReturnValue into a standard SharePoint Designer Log to History List activity.
One of our customers recently wrote in a support email “If only Microsoft allowed C# code to be used in SharePoint Designer workflows, my life would be so much easier”. Little did this person know that we were in the middle of a development cycle to make his wish come true, just in time for Christmas as well.
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.
What does this mean for day-to-day SharePoint Designer Workflow development? When Microsoft released SharePoint 2007, they included a basic set of Workflow Actions and Conditions to allow basic comparison of values and simple tasks such as setting a field value or logging to the Workflow History. If you wanted to do anything else your options were limited to expensive third party workflow tools that would hopefully support the functionality you are after, or writing your own solution in Visual Studio.
From as little as $349, the Workflow Power Pack is the last 3rd party workflow solution you’ll ever need. The possibilities are only limited by your own imagination, for example:
Carry out tasks by comparing deeply nested XML data inside InfoPath forms.
Create Actions that directly access SQL Databases or other common data sources.
Make string, date and numerical operations simple (Finally!).
Access any SharePoint functionality using the SharePoint Object Model.
Send emails and includie attachments.
Create folders in the current SharePoint List or any other list regardless of Site Collection.
Control security on individual List Items or entire Document Libraries.
One of the key changes introduced with the release of the Muhimbi PDF Converter Server Platform and API 3.0 is the ability to convert typical Office files via a web services based interface. This makes it very simple to convert typical Office files to PDF format from your own .NET, Java or any other web services capable environment.
This post describes the key features of the web services based interface and provides a simple example describing how to convert a document to PDF format. Source code for a more comprehensive demo is available for download as well. Feel free to contact us if you have any questions.
Prerequisites
Let’s make sure all prerequisites are in place before we start our tutorial.
Convert popular document types to PDF or XPS format with near perfect fidelity. At the time of writing support is available for MS-Word, PowerPoint, Excel, InfoPath, Visio and MS-Publisher, but by the time you are reading this additional document formats may have been added.
Scalable architecture that allows multiple conversions to run in parallel.
Runs as a Windows Service. No need to install or configure IIS or other web service frameworks.
Convert password protected documents.
Apply security settings to generated PDF files including encryption, password protection and multiple levels of PDF Security options to prevent users from printing documents or copy a document’s content.
Generate a regular PDF file or a file in PDF/A format.
Generate high resolution PDF Files optimised for printing or normal resolution files optimised for use on screen.
Control how to deal with hidden / selected content such as PowerPoint Slides and Excel worksheets.
In addition to the features described above, the MDCS software stack also contains a layer of functionality to control concurrency, request queuing and watchdog services to deal with unresponsive and runaway processes. More detail can be found in the brochure.
Object Model
Although the Object Model exposed by the web service is easy to understand, the system provides very powerful functionality and fine grained control to specify how the PDF file is generated.
As outlined in the image below, the web service contains 3 methods:
Convert: Convert the file in the sourceFile byte array using the specified openOptions and conversionSettings. The generated PDF or XPS file is returned as a byte array as well.
GetConfiguration: Retrieve information about which converters are supported and the associated file extensions. Consider calling this service once to retrieve a list of valid file extensions and check if a file is supported before it is submit to the web service. This will prevent a lot of redundant traffic and will increase scalability.
GetDiagnostics: Run a diagnostics test that carries out an internal end-to-end test for each supported document type. Call this method to check if the service and all prerequisites have been deployed correctly.
The full object model is available in the following diagram. Click to enlarge it.
PDF Converter Web Service Class Diagram. Click to enlarge.
Simple example code
The following sample shows the minimum steps required to convert a document to PDF format. In our example we are using Visual Studio and C#, but any environment that can invoke web services should be able to access the required functionality. Note that the WSDL can be found at http://localhost:41734/Muhimbi.DocumentConverter.WebService/?wsdl. A Java based example is installed alongside the product and discussed in the User & Developer Guide.
This example does not explicitly set ConversionSettings.Format. As a result the file is converted to the default PDF format. It is possible to convert files to other file formats as well by setting this property to a value of the OutputFormat enumeration. For details see this blog post.
Start a new Visual Studio project and use the project type of your choice. In this example we are using a standard .net 3.0 project of type Windows Forms Application. Name it ‘Simple PDF Converter Sample’.
Add a TextBox and Button control button to the form. Accept the default names of textBox1 and button1.
In the Solution Explorer window, right-click References and select Add Service Reference.
In the Address box enter the WSDL address listed in the introduction of this section. If the MDCS is located on a different machine then substitute localhost with the server’s name.
Accept the default Namespace of ServiceReference1 and click the OK button to generate the proxy classes.
Double click Button1 and replace the content of the entire code file with the following:
using System;
using System.IO;
using System.ServiceModel;
using System.Windows.Forms;
using Simple_PDF_Converter_Sample.ServiceReference1;
namespace Simple_PDF_Converter_Sample
{
publicpartialclassForm1 : Form
{
// ** The URL where the Web Service is located. Amend host name if needed.
if (client != null && client.State == CommunicationState.Opened)
client.Close();
}
}
}
Providing the project and all controls are named as per the steps above, it should compile without errors. Run it, enter the full path to the source file, e.g. an MS-Word document, and click the button to start the conversion process. The conversion may take a few second depending on the complexity of the document.
Note that In this example we are programmatically configuring the WCF Bindings and End Points. If you wish you can use a declarative approach using the config file.
In order to carry out internal testing we have developed an application that can be used to control each end every function exposed by the web services. The full source code as well as a compiled binary can be downloaded below.
Note that although the test harness works well and can be used to batch convert a large number of documents, this is not commercial grade code. Use at your own risk.
If you wish to access the PDF Converter from your own custom SharePoint code, you may want to consider using our high level Wrapper methods. If you are not using the wrapper methods then please make sure you are invoking the web service from a user who has privileges to do so. By wrapping the code in SPSecurity.RunWithElevatedPrivileges you will automatically connect using an account in the WSS_WPG windows group, which has access by default.
One of the most common (sub) tasks executed from a SharePoint workflow is the submission of an email. SharePoint ships with an Email Workflow Action out of the box, which is unfortunately very limited in its abilities. For example, it is not possible to include attachments, specify the From Address, set the Priority or specify the SMTP server to use.
When we released the 
When I worked in the SharePoint team for a London based financial firm, one of the first user requests that came up was to find an easy way to synchronise team calendar entries with a department level calendar. 
Quite a few of our customers use a SharePoint Designer workflow to 
In part 3 of our series of User Guide related blog postings for the 
In part 2 of our series of 
Even though we have only recently released the 
Embed C# or VB.net code directly into your SharePoint Designer Workflow
Secure your system by controlling which Assemblies can be accessed
One of the key changes introduced with the release of the 
