If signoSign/Universal is to be hosted at the customer’s site where a Web application allowing users to access documents already exists, this customer Web application can be used for deep integration.

If you are using the persistence interface, it is necessary that the documents to be signed are made available in a database, file system or other transactional transfer.

It makes no difference where the documents originate (file system, database), as the authors of this customer Web application know how the documents are accessed. This way, by calling signoSign/Universal, a document ID that references the document to be fetched is transferred. The method used to fetch the document (‘getDocumentFile’ in signoSign/Universal) can use the document ID to access the data source and load the document in the viewer and display it. The integrator can/must program the exact access logic on the file itself.

Core properties of the integration scenario

• The signoSign/Universal viewer is installed next to the customer Web app as an additional application on the customer’s server or another server. This way, the user can use it as part of the customer Web application. For this, you need to implement the relevant interfaces (see separate technical documentation). Also, every document link needs to reference the signoSign/Universal viewer and transfer the document ID. 
  
  
• The signoSign/Universal viewer directly exchanges documents and resources with the customer implementation. This way, the documents always remain on the server (with the exception of the Java applet, see above), and after processing they are available on the server again. 
  
  
• The signoSign/Universal viewer can be physically embedded directly into the customer Web app (Java EE) and is installed together with this. Alternatively, the customer implementation could be, for example, a Web service that communicates with a remote Web app or a database.

This integration scenario offers

• The highest level of integration and
• The highest level of flexibility for the integrator

Workflow
These are the individual steps of the process:

1. Start the customer Web app containing a link to a PDF/SGN document.
   
   
2. Tap/click one of these hyperlinks.
   
   
3. The selected document is temporarily loaded into the signoSign/Universal viewer Web app via the interface. Here, the document data required for dis-playing the document is extracted.
   
   
4. This document data (not the document itself) is displayed in the signoSign/Universal viewer for processing and signing.
   
   
5. After processing or signing, press the ‘Save’ button to return the document data to the signoSign/Universal viewer Web app.
   
   
6. Here, the data is inserted into the customer document, which is then exported back to the customer Web app (via the interface implemented by the customer) and saved there. 

A programming interface in the form of a static library is available for integration in a native iOS app. This way, it is possible to directly transfer the PDF generated through the customer app to signoSign/Universal.

The signoSign/Universal API includes the libSignoSignMobile.a component, a static library that can be used to implement basic PDF processing functions within a separate iOS app. The signoSign/Universal server is required in order to use this library. It can be hosted by signotec or directly by the customer.

Function overview

• Displaying a PDF document in full-screen mode by transferring a PDF document or URL to a PDF.
  
  
• Filling in PDF form fields.
  
  
• Signing signature fields on the iPad.
  
  
• Adding signature fields on the iPad.
  
  
• Saving the PDF document.
  
  
• Exporting the PDF document as an email (requires an existing email account).
  
  
• Exporting the document to another app (“Open in…”).
  
  
• Printing the document via AitPrint.