Notes on Zend SOAP webservice development

Developing SOAP webservices with the Zend Framework is very easy, but there are some things that aren't explicitly mentioned in the documentation. Hopefully this hints will help you to save time.

WSDL caching

While developing a webservice application do not forget to disable WSDL caching, e.g. in your php.ini configuration file.

soap.wsdl_cache_enabled=0

Set path to SOAP server in WSDL file

When you use a controller for your webservice and desire to have two actions, one for the automatically generated WSDL file and one for the server, use the setUri method of the Zend_Soap_AutoDiscover class to set the URI of the server.

$wsdl->setUri('http://example.localhost/index/soapserver');

Error handling

Error handling with exceptions is easy. I suggest to create your own Exception class first, it can be empty for now:

In your webservice class throw your new exception on invalid input for example.
On SOAP server side, you have to register your Exception class:


On Soap client side embed your request in a try - catch block:

Which for example outputs: 'SOAP ERROR: [Receiver] The product ID does not exist!'

The code

The webservice controller:


The webservice class:


The custom Exception class:

Google Chrome double request session problem

While working on an older PHP project based on a self made framework I noticed strange behaviour when running the project in Chrome. Everything worked fine in all other browsers, no matter, if it was production or development environment.

Each time I logged in the session ID cookie changed. The consequence was, that when trying to reload the page or open other restricted pages the system logged me out.

Even though everthing worked fine on other browsers, I tried to find the bug in the PHP code. I thought I missed something, set wrong headers which Chrome interpreted more strictly than other browsers or something similar. None of that was true. I debugged the code responsible for the session, made sure nothing is going to fall through the cracks. Code that was intended to run once on page execution ran twice, which lead me to the idea, that it's a forwarding/reloading issue.

I checked the $_SERVER array for header information, which differed between browsers. But there was nothing suspicious. REQUEST_URI then revealed the problem: While you would expect only one request to '/' Chrome requested '/favicon.ico' in a second request. This somehow caused a reload with a seperated cookie space, because the reloaded page couldn't read the session cookie and created a new one. I'm not sure what happened in detail but providing a favicon.ico file helped.

I'd like to emphasize that I didn't use a favicon in the HTML, perhaps there is a flag set in the server configuration which is ignored by other browsers.

Hope this helps someone, this took me some time to figure out.

Font problems with wkhtmltopdf

Recently I ran into problems with font kerning and font sizes when creating PDFs with wkhtmltopdf on different machines. I create PDFs on my ubuntu machine locally and on a FreeBSD server remotely.

Unfortunately font sizes differed a lot and from the beginning the kerning wasn't as I expected. The space after characters like 'v' is too small or too big, depending on the chosen font size. Sometimes it happens that two characters get rendered  one on the other. This is not acceptable.

I found out that this topic is already discussed in the wkhtml bugtracker. Users have different approaches to that problem, but none of the solutions is acceptable for me. Running an XServer is not possible and running xvfb as a wrapper to the tool sounds a lot slower than using wkhtmltopdf 'natively' and certainly is!

After experimenting with CSS modifications concerning font sizes, letter spacing, --zoom and --disable-smart-shrinking / --enable-smart-shrinking parameters to wkhtmltopdf I finally found a working solution. It's very easy to apply and has no disadvantages.

I need polish characters in my texts, so I downloaded high quality fonts from TeX Gyre Project. They provide their fonts in ODF format instead of the commonly used TTF format. I don't know, if the fonts of the Gyre Project solve the problem or if it is the newer ODF format that eliminates certain limitations of the TTF format when used on different operating systems.

In your external or internal stylesheet of your HTML file you'd like to convert, define a custom font face like this:


Don't forget to use the correct path to your font. Whenever you want to use it, use your new defined font family:


This eliminates all problems arising due to different font versions on different systems and the kerning bug in wkhtmltopdf version 0.10.0_beta5

Filling PDF forms using XFDF

Description

This article is about user data that can be provided in PDF form back to the user. Don't use old methods in the web which suggest to use FDF. FDF and the PHP FDF module are deprecated, don't support UTF-8 and you'll have only problems with it ;). 

One common use case is a web form that requires the user to input information for an application that has to be sent by snail mail for confirmation or to print the information in a user friendly form that is exchangeable.

The key is creating an XFDF file that holds all the user information connected to IDs of form input fields that are defined in a PDF file with empty inputs. The empty fields are then filled with the user information. The URL to the PDF file is defined in the XFDF file. If the user opens the XFDF file with the help of the Adobe Reader browser plugin, all happens in the user's browser window. An alternative for the user is downloading the XFDF file to open it later.

Advantages:

1. As filled PDF forms can't be saved (but can be printed), this is an alternative to keep the inputted data,
2. you don't need HTML to PDF converters. Create professional looking PDFs in any program you like

Disadvantages:

1. If the PDF file is available online, the user has to have an active internet connection whenever he or she opens the XFDF file, 
2. Adobe Reader asks, if it should fill out the PDF with possibly unsecure data. The PDF stays empty without user's confirmation.

One workaround for the 1st disadvantage is PDFToolkit. It allows to flatten a PDF file with the XFDF file to create a user ready downloadable PDF file, but the data is not editable anymore. The 2nd workaround is to download the empty PDF file to disc and change the URL in the XFDF file which is in XML format.

Creating PDF forms with OpenOffice

OpenOffice has a toolbar with form elements. You can find it in the View->Toolbars->Form Elements menu. Just place the elements you need in the document and export the whole thing as PDF. Don't forget  to check the "Create PDF Form" option. Please be aware of the IDs of the form elements in the document. You can set the ID by chosing "Properties" in the context menu of the element. To check the form elements afterwards you can use PDFToolkit:

pdftk test.pdf dump_data_fields
\--\-
FieldType: Text
FieldName: textelement1

FieldNameAlt:
FieldFlags: 0
FieldValue:
FieldValueDefault:
FieldJustification: Left

Generating the XFDF file

The specification I used can be found on Adobe Website. This is the PHP code to create an XFDF file out of an array of user input data fields.


And this is how to use it:


As you can see, only the XFDF file is outputted. The Adobe Reader plugin parses it and tries to download the corresponding PDF file to fill in the user data.

Dynamic HTML to PDF conversion

There are a lot of libraries out there which allow you to create PDFs from HTML documents. Some of them even allow to use external stylesheets, others allow inline styles only. They have one disadvantage in common: the PDF never looks like your original HTML file. Other limitations include i.e.:

• No support for floating,
• no support for ordered lists,
• no support for nested tables,
• in general table support is weak for all libraries I tested,
• only a subset of CSS styles is supported,
• dynamic content placement is very difficult,
• problems on page breaks,
• etc.

The easiest way is to just print the HTML page to a PDF file. The generated files are nearly 100% as you expect them to be. The best solution I found to accomplish this is wkhtmltopdf. Ask your webhosting provider to install this tool, if you don't have the possiblity to install it by yourself. I heard of people that managed it to install wkhtmltopdf in their home directory successfully.

wkhtmltopdf uses QT libraries. These libraries include the Webkit rendering engine for Apple Safari Browsers. So you can expect to have all CSS and HTML features working that Safari currently supports. You have to compile the author's patched QT libraries to have full functionality without the need of using a running XServer. Alternatively use the static executables.

You can find a PHP Class you can use with wkhtmltopdf. It's pretty self explaining and the example application should help you creating your first PDF file. I create PDF files by rendering an HTML file out of my PHP application, saving it to a writable directory with other necessary external files like images, js and css and executing the wkhtmltopdf converter.

It's a great tool and creates small PDF files. I'm missing security features like password protection, though.