Signing PDF’s made easy

Pieter Rijlaarsdam, 08 May 2019

Whether you are selling, buying, leasing, hiring or contracting, the need for a physical signature is often still required.

Many processes require a physical signature to start. Whether it is required by law or to make sure arrangements are agreed on by both parties, a signature is a good way to seal the deal.

But… we are in the 21^st century… come on.

What if we could easily implement an automated signing service?

Digital signing

Let’s take a look at a typical B2B sales contracting process.

In the old days…

During the sales process, we used to manually send a PDF quotation via email requesting the customer to print, sign, scan and return the document. The signed document is returned (after several reminders) by email, the correct sales order is manually searched and the status is manually changed.

Although I am not able to verify, I am sure that in some cases this was enough burden for the customer to move on to the competitor where onboarding is easier.

But now…

In the new situation, we want to send a link to the customer, the customer preferably signs on a phone or tablet, and our process automatically continues.

As an additional benefit, we have proof of signing; automatically in SAP.

As an additional benefit, we can have automatic reminders.

As an additional benefit, we can monitor the signers’ behaviour. For instance, if the signer has viewed the document 4 times without signing we could trigger a task in SAP for sales to call the customer to ask if he has any more questions regarding the contract.

How to choose…

When running SAP, there are many options available.

While comparing the different solutions, I found that prices range from around € 50,- to more than € 500,- per month. Some with very complex API’s, adding implementation and maintenance costs.

When studying on the topic a bit, you can find out there are many local standards throughout the world, such as eIDAS for Europe. Depending on what you require to be supported, you can narrow down your search.

Signhost

For one of my clients I decided to implement an integration with Signhost.

The benefits of an easy to understand REST API, only €54,- for 50 credits per month (or €540,- for 600 credits per year) and the ability to start immediately caught my attention and paid off.

It turned out to be easy to implement and cost-effective.

In only 4 weeks time we embedded the digital signature in an existing SAP sales process.

To get started…

First get a trial account here.
Then read the documentation.
Then log in to your SAP system.
Create an https destination in SM59 to api.signhost.com.
Add the root certificate from api.signhost.com to strust.
Create a custom class (like ZCL_DIGSIG or whatever naming convention you are used to).
In the constructor, declare the destination using the cl_http_client=>create_by_destination.
Now create methods in the class that reflect the actions the interface will be performing such as

get_transaction
create_transaction
delete_transaction
start_transaction
upload_file

Within these methods, create a JSON using for instance ZJSON or /UI2/CL_JSON to create a JSON according to the specs from step 2.
Then use destination from step 4 to send the data.

[abap]

lv_uri = co_transaction.
gr_http_client->request->set_header_field( name = if_http_header_fields_sap=>request_uri value = lv_uri ).
gr_http_client->request->set_header_field( name = ‘Content-Type’ value = ‘application/json’).
gr_http_client->request->set_method( if_http_request=>co_request_method_post ).
gr_http_client->request->set_data( data = lr_xml ).

TRY.
gr_http_client->send( ).
gr_http_client->receive( ).
CATCH cx_root.
ENDTRY.

[/abap]

Now transform the response back to a structure and continue processing.

To continue…

Now that the basis has been created (that was quick), you should implement this class to be called whenever a document is ready to be signed. This could be for instance in output determination where you create the PDF using a smartform or AIF, determine the designated signer, the email address etc and then create the signing transaction.

You will also want to implement a process where you receive the feedback from the Signhost platform. Let’s say you have created the transaction, and the signer either signs or rejects the transaction. SAP should then be aware. For this, you can implement the postback url. This would be a link to a webservice hosted on your SAP landscape where the Signhost platform sends the updated transaction data to. You specify the exact URL in your transaction create request. The webservice then processes the updated transaction in SAP. Depending on what has changed (has the signer merely viewed the document or actually signed it), you can implement logic for further processing.

Once the document is signed or rejected, you will want to update certain people using SAP workflow and/or change the status of the SAP document (for instance the order) and continue processing. You might also want to store the signed document and signing receipt.

So who does what?

There are several steps in the process, and it is up to you to decide which system does what.

Create the transaction. Obviously here, SAP triggers this in the Signhost platform.
Send the email. This can be either from SAP (you can fully customize or personalise the message) or from the Signhost platform (limited customization possible).
This can be either from SAP (customizable, personalisable or manual) or from the platform (standard reminder after X days).
Notify the relevant people. You can use the standard email flow from signhost or use the postback URL to trigger processing in SAP.

To conclude…

A process that was far from loved, took time and frustrated customers can now be done quickly and easily.

By embedding the signing of a contract digitally in the process, the risk of errors, ‘abandoned carts’ and ‘hanging processes’ is minimized and cost is reduced