This document will give developers a technical overview of the different parts and architecture of the DocVue component.
Use this page when you plan to develop for or fix bugs in IFS Document Management AutoVue Integration or want to have a deeper understanding about it.
AutoVue has three main parts you need to know about to get an overview of the DocVue component. You will get an overview of what they are and what they are used for below.
AutoVue Applet. The AutoVue Applet is the actual document viewer. It will send document information (the keys and some other attributes) to the AutoVue Servlet and show the returned display stream from the AutoVue Server. Even if the file is big the AutoVue Applet will only get the information it needs to display the part of the file the AutoVue Applet is currently show.
AutoVue Java Servlet. The AutoVue Servlet is packaged with our implementation called IFS AutoVue Connector and is deployed on the extended server as a war-file. The war file itself is then merged into the main ear file (ifsapp.ear) that is the IFS application. It will pass the document information that comes from the AutoVue Applet to IFS AutoVue Connector which is also a servlet and then return the result from the AutoVue Server to the AutoVue Applet.
AutoVue Server. The AutoVue Server converts the actual document file it gets from the AutoVue Servlet and connects to the AutoVue Applet. The AutoVue Applet will only get information about the currently viewed part of the document, not the complete document. It's a server application written in Java and for performance reasons it should be installed on its own server/machine unless it's only for demo or test.
We don't have control over the process from AutoVue Applet to AutoVue Server so we have created a ticket solution as a replacement for proper authentication. Below is explained how it works.
When the user wants to view a document we create a ticket using the database API Vue_Link_Auth_Ticket_API by calling the procedure Generate_Ticket. The ticket is returned and saved in the database table vue_link_auth_ticket_tab. The ticket will be set in the AutoVue Applet as AutoVue DMS Arg "ticket" so AutoVue Servlet can fetch it along with the document keys.
The table vue_link_auth_ticket_tab have the following table:
Column | Description |
---|---|
idd | Numeric counter to identify the ticket |
created_date | When the ticket was createdtd> |
user_id | The user's User ID, for example "ALAIN" |
ticket | 20 randomized alphanumeric text that always will be unique |
The created_date will be used so the ticket is only valid for 60 seconds, after that the ticket can't be used anymore. Old unused tickets will be deleted each night by a database batch job that is created in DocvueTicketBatchJob.ins.
When the IFS AutoVue Connector gets the document information provided by the
AutoVue Applet it will call the procedure Use_Ticket in Vue_Link_Auth_Ticket_API
and validate the ticket using the DOCVUETICKETUSER (more details in next section).
The procedure returns User ID stored in the user_id column and deletes the ticket
so it can't be used again. The tickets are generated when the user is within IFS
Application so the database can retrieve userID by checking who is making the call
to generate the ticket. IFS AutoVue Connector will only use the DOCVUETICKETUSER
user to use the ticket, all other database calls will be done using the returned
user ID so standard security on document access remains as usual.
The user DOCVUETICKETUSER have the role DOCVUE_USE_TICKET, this user is only used
to verify the ticket using the database call described above (Use_Ticket in Vue_Link_Auth_Ticket_API)
and nothing else. You can read more about the user and role in "DocvueActivityRoles.htm"
found in the component root.
The IFS AutoVue Connector will handle the communication with IFS like retrieve information about the document and provide the AutoVue Server with documents (by delivering a file stream) that should be viewed in the AutoVue Applet. Development on IFS AutoVue Connector are done using IFS Developer Studio.
In the image below you can see the process and in what order the different methods will be called.
The second column in the process chart above shows which class in the source package actions will be called. So for Action Open request you will find ActionOpen class and so on.
The first we do in ActionOpen is to verify and use the ticket, and we retrieve
document information like name, last modified and size.
The servlet will fetch the document information for the AutoVue Server in GetProperty
(found in DMSBackendImp.java) and if the AutoVue Server finds the current document
in its cache (it will compare size, date and name) it will start streaming the file
to the AutoVue Applet else it will go to the next step.
In ActionDownload we use DOCMAN FileTransferService to get out the document and
then return a FileInputStream to AutoVue Server that will provide the AutoVue Applet
with the document.
This document does not describe the code in detail, it's better to view the code and the comments there for more details.