Subscribe to News feed

Converting TIFF files to PDF using the Muhimbi PDF Converter Services & SharePoint

Posted at: 12:27 PM on 25 March 2011 by Muhimbi

tiffIt is easy to overlook the good old TIFF format when developing applications as it has been eclipsed in the recent years by more modern, browser friendly, image formats such as JPG, PNG and GIF. However, there are a number of scenarios for which TIFF is still widely used, particularly because a single TIFF file can hold multiple pages.

Two of the more popular uses for multi-page TIFF files are the scanning of multiple pages into a single file and the reception of multi-page faxes. As these kind of document management scenarios are very common, particularly with our SharePoint customers, we have decided to add native support for this format to our popular range of PDF Conversion products.
 

The key features are as follows:

  1. Convert multi page TIFF files to a single PDF file.
  2. Automatic page size detection.
  3. Compatible with PDF/A.
  4. Supports all TIFF formats recognised by the underlying operating system.

 

As the converter is part of our highly scalable PDF Conversion platform, it automatically benefits from all its features including reliability, scalability, watermarking engine, cross platform support, web services based API, PDF security, SharePoint integration, Nintex Workflow integration, Java support, InfoPath attachments, Windows Azure etc.

As they say, a picture is worth a thousand words, so listed below is a rather boring copy of a converted multi page TIFF file.
 

Multi-Page-TIFF

.

Labels: , , , , ,

Using Windows Azure to convert documents to PDF format – Part 2 (Azure Connect)

Posted at: 11:05 AM on 22 March 2011 by Muhimbi

Windows-Azure-Logo10Today’s article is another guest post by John Dent from BlueHub Solutions, who have been using our popular PDF Conversion Services to convert documents in MS-Office, AutoCAD, HTML, Image and many other formats to PDF from a Windows Azure based solution.

Over the next few weeks we’ll publish a number of posts related to using our software in combination with the Azure platform, so make sure you subscribe to our RSS feed or follow us on Twitter.

The following posts are part of this series:

  1. Using Windows Azure in combination with an internet facing web service.
  2. Using Windows Azure in combination with a web service hosted inside an organisation’s private network. (This post)
  3. Using Windows Azure in combination with a 3rd party web service hosted inside a custom Azure VM. (Coming soon)

If you have any questions then please contact us, we are always happy to talk to our customers. For now I’ll hand you over to John.
 

---------------------------

Introduction

Welcome to my second post on using the Muhimbi PDF Converter Services from within an Azure application. As you may remember, and depending on the condition of your short-term memory cells, as we left it previously our web application was calling into the Muhimbi web service through an Internet URL.

For a number of reasons, including security and architectural elegance, this architecture could be considered undesirable – we are effectively being forced to host what is essentially an Intranet application on the Internet. It would be better to be able to run the Muhimbi web service as an Intranet application on our local business network, and still have our Azure application connect to it.

As luck would have it, Microsoft have provided exactly this functionality under the “Azure Connect” banner – this is a way of creating a secure channel through which an Azure application can communicate with local network resources. Even better, it’s really easy and seems to work really well.

 

Beta Signup

Azure Connect is still a Beta feature at this stage, so the first step is to register for the Windows Azure Connect Beta program – you do this by logging in to the Azure Management Portal, then selecting Home and Beta Programs. You have to wait for your request to be manually accepted, which can take a couple of days.

Microsoft’s official documentation on setting up Azure Connect can be found on MSDN. An in depth video presentation is available on Channel 9 as well. Listed below are the steps we used.

 

Endpoint Installation

Once you’re a fully paid up Beta program member, log onto the Azure Management Portal and select the Virtual Network section. (The Virtual Network button didn’t always work for me, instead I used the ‘Connect’ button at the top of the screen.)
 

image1

 
Having done this, select your Azure subscription from the tree control on the top-left.
 

image2

 
You may at this point be prompted to update your subscription options - complete the requested information as necessary.

The next step is to install a Local Endpoint on the server that is running the Muhimbi PDF Conversion Service. Do this by clicking the Install Local EndPoint button on the toolbar. This generates a connection token and gives you a download link for the software to install on your Intranet server.
 

image3

 
This will then download and install the Windows Azure Connect software (a Windows Service), which then automatically allows your server to be securely accessed via TCP from Azure and vice versa. Effectively this creates a kind of VPN between the machine on which the software is installed and your Azure applications, and allows the machine to be accessed by network name from Azure.

Internet facing firewalls are effectively bypassed in the process, though note that Azure Connect itself needs port 443 on the Windows Firewall to be open for outgoing traffic (as would normally be the case).

Installing Azure Connect is then delightfully straightforward …
 

image4

 
Finally, even though Azure Connect tunnels its way over the public internet, it still adheres to any locally (as on the server) configured firewall rules. The Muhimbi PDF Converter Services listens on port 41734 by default, so add a rule to your server’s firewall to allow incoming requests on this port. In our case we had to specify this on the Private Profile in the Windows Firewall. Alternatively, as a quick test, disable the entire Private Profile firewall (Note that in Windows 7 / Win2K8 R2 there is no longer a single option to disable the entire firewall).

 

Configuring the Azure application to use the new end-point

Once this is done, your new end-point should appear in the Virtual Network section of the Azure Management Portal.
 

image5

 
After this we can update our application to connect though this end-point simply by specifying the computer name, in my case jonny-PC.

Going back to our Azure PDF Conversion Application, as developed in part 1 of this series, we can now reconfigure the web reference so that it uses jonny-PC via Azure Connect (as I’ve installed the Muhimbi PDF Conversion Services on my PC).
 

image6

 
The next step is to set up the Azure project so that it can work as an end point for the virtual network. To do this go the Virtual Network section of the Azure Management Portal and click the Get Activation Token button.
 

image7

 
We need to enter this into our application - to do this we go into the properties of the Azure project (under the Roles folder), select the Virtual Network tab, and enable Windows Azure Connect for this project. At this point enter the activation token into the box.
 

image8

 
After we save this project we need to change a value in the ServiceConfiguration.cscfg configuration file. Change the following line from

    <Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value=" " />


To

    <Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value="false" />

 

This setting means that for simplicity we don’t have to set the application up to join a domain when we enable the Azure Connect functionality, which would be the alternative approach.

At this point it is worth checking the web.config of the application to verify that the web service URL is correct.
 

image9

 

Deployment

The next step is to republish the application to the Azure server. I recommend at this point to delete the old Azure application in the Management Portal and create a fresh “Staging deployment”. This is because at the time of writing there seems to be a small bug with the service definition configuration not getting updated properly.

The Virtual Network section of the Azure Management Portal should now look like this:
 

image10

 
We need to group the endpoints together so that they can talk to each other, so to do this click on Create Group, and:

  • Enter a name
  • Add the PC end point
  • Check Allow connections between endpoint in group
  • Add the Azure role


You should end up with a screen that looks like this:
 

image11
 
You may need to wait a few minutes before it is activated, so be patient if you get an error about the host name not being resolved. After this you should be able to launch the Azure hosted application and convert a document using the Muhimbi PDF Converter Service instance on your local network.

 

Next post – The Azure VM Role

For my next post I’m going to explore how to host a custom VM Role in Azure, i.e. a complete virtual server, again themed around the Muhimbi PDF Converter Services.

 

About Me

If you have any comments then please post them below, or feel free to email me at johnd@bluehub.co.uk. Alternatively you can contact Muhimbi’s support team.

 

John Dent

.

Labels: , , , , , ,

Auditing field level changes using Muhimbi SharePoint Audit 2.0

Posted at: 1:44 PM on 21 March 2011 by Muhimbi

Tracking Field, not 'Track & Field', doh!

As part of the series about New features in Muhimbi SharePoint Audit 2.0 I would like to dive into a great new addition, which is the auditing of field level changes, a feature unique to our product.

As you may be aware, SharePoint’s native auditing capabilities are somewhat limited. You may, with a lot of effort, be able to track that an item has been changed (by Item ID, sigh), but there is no way to find out which field has been changed and what the old or new values are.

Sure, you can enable ‘Version History’ on a list, but that only provides a little bit of detail, must be enabled manually on every list and the details cannot be queried as part of an Audit Report.

As tracking field level changes is rather useful, we have decided to add it to the core product and treat it the same as any other audit even type, resulting in the following advantages:

  1. Auditing of this kind of information is automatically enabled when a Site Collection or list is created. There is no need to manually enable it.
     
  2. Field changes are automatically included when the audit logs are queried or reports are generated, including all filtering and pivoting options.

 

So, if you are familiar with the product then it all works like any other audit event type. You specify either at the Farm, Web Application or Site Collection level that you want to track the Field Change’ event type and the system sorts it all out for you.
 

Field-Change-settings

 
Once enabled, all field level changes are audited automatically. See the following screenshot for an example that shows a single audit entry for a change to the standard Task List.
 

Field-Change-Detail


When generating a full Audit Report all changes are grouped together as follows (Click to enlarge)

Field-Change-Report

 
That’s it. Nice, powerful, integrated, intuitive. Download your free trial version here, no registration needed,

.





Labels: , , ,

Need support from experts?

Access our Forum

Download Free Trials