This tutorial demonstrates the Live Forms Data API Java Client library features using a web application and a JSP. The web application is created using JSP (Java Server Pages). We will refer to several Java Server Page files to explain the API features. You will see these delimiters in the files:
<frevvo-home> in the file paths refers to the frevvo subdirectory that was created when you installed frevvo.
In v9.1 and later frevvo's "Applications" are known as "Projects." The API objects and methods still use the word Application.
On This Page:
This tutorial will cover the following functions:
FormTypeFeed:Initialization of a form with XML data, Attachment and Wet Signature
You will need to do the following to complete this tutorial:
Follow these steps to install the Java API tutorial web application.
Download the Java API Tutorial v5.2 zipfile.
Re-start frevvo. This will expand the war to the <frevvo-home>\tomcat\webapps\api directory.
The Live Forms Java Client Library has the following dependencies:
These client libraries are already added in <frevvo-home>\tomcat\webapps\api\WEB-INF\lib directory of the web application that we are using. However, the actual jar versions may be different depending on the version of Live Forms being used. To ensure that you have the latest versions of these files, it is recommended that you replace the client libraries that come with the Java API Tutorial Project with the .jar files located in the <frevvo-home>\ext\client directory of your frevvo build.
Follow these steps to perform the replacement:
You must update the frevvo server and tenant information in the doLogin.jsp file for the web application to work. Follow the steps below:
On line number 14, replace the default values with your Live Forms server and port number:
On line number 20, replace the default values with the admin username, tenant and admin user password previously created for this tutorial:
To check if your web application is working, browse http://<your frevvo server host>:<port>/api/apitutorial/index.html. E.g.You should see a login page like this one:
The FormsService instance is state-full and the same instance needs to be used throughout the session. This is especially the case when rendering form URLs in the browser since an API key is automatically appended and bound to the FormsService session. As soon as you logout(), the API key becomes invalid. Typically, in a web application context, the FormsService instance is stored in the HTTP session that the user has with your web application.
Edit the <frevvo-home>\tomcat\webapps\api\apitutorial\login.jsp file.
It also accepts a URL parameter targeturl which is used to redirect the user after login. If a targeturl is not passed to the login.jsp page it will use formtypes.jsp as the default targeturl:
3. Clicking the Submit button on the login.jsp page calls the doLogin.jsp page.
Edit the <frevvo-home>\tomcat\webapps\api\apitutorial\doLogin.jsp file.
In the doLogin.jsp page, we create a FormService instance:
If the service instance is not null, that is if a user login already exists for the service instance, we logout that user from the FormsService session and remove the service instance from the HTTP session:
Then we use the LoginAs method to login to the account whose username was entered on the login.jsp page. This method allows you to login to Live Forms as any of the existing tenant users provided you can pass in the tenant's admin user and password. This is quite convenient when you want login to Live Forms using the same user that is logged into your project without having to know their password.
The request.getParameter( "username" ) gets the username value which was passed from the login.jsp page.
The LoginAs method also returns the logged in user information in AutoLoginUserInfo object.
Then we add the service instance to the HTTP session:
We also save the user information returned in AutoLoginUserInfo object alui to the HTTP session:
Lastly we redirect user to the next JSP page of the web application based on the targeturl parameter:
On your web applications login page, enter your designer user name and click Submit. You will see the formtypes.jsp page shown in the image:
Now that you have displayed the formtypes.jsp page, let's look at the formtypes.jsp file to see how this is implemented:
Edit the <frevvo-home>\tomcat\webapps\api \apitutorial\formtypes.jsp file.
The formtypes.jsp checks if the HTTP session contains a FormService instance with a valid user login. If not, then it redirects to the login.jsp page to create a valid user login:
It also gets the user information stored in the user.info attribute of the HTTP session. The ApplicationFeed and FormTypeFeed are available only for designer user logins. We will not retrieve the projects and forms if the current logged in user is not a designer, i.e. alui.designer is false:
Next it gets the ApplicationFeed for the current logged in user:
Now it will check if the Tutorial Project exists in the current logged in designer user account:
If the Tutorial Project does not exist then it will upload the project to the designer user account. The project zip file that we are uploading is <frevvo-home>\tomcat\webapps\api\apitutorial\Resources\TutorialApplication_v52_app.zip.
The default deployment state of the Employee Information form in this uploaded project is DEVELOPMENT. We changed the deploy state of the form to PRODUCTION with the code shown below:
Once the project is uploaded we now list all the Projects/Forms/Workflows in this user account.
We get the updated ApplicationFeed after the Tutorial Project is uploaded. The application feed contains all the projects in this user account:
Then we iterate over each ApplicationEntry in the ApplicationFeed and from each ApplicationEntry we get the FormTypeFeed which contains the forms and workflows in that project:
We iterate over each FormTypeEntry in the FormTypeFeed twice using the types iterator defined above. Once to collect all the forms and the second time to collect all the workflows in that project:
Then we get the Raw Link, Popup Link and Edit link for the forms/workflows from the FormTypeEntry:
Next we check if there are any submissions associated with the form/workflow. If yes, then we get the FormTypeID for the form. Then this FormTypeID is appended as the URL parameter to the showSubmissions.jsp page link. The showSubmission.jsp page will use this FormTypeID to list all the form submissions (See SubmissionFeed):
Click on the Initialize From XML link displayed against the Employee Information Form. You should see the form fields initialize with data from XML files. Similarly the upload control is initialized with an attachment file and the wet signature control is initialized with a signature image:
To initialize the Employee Information form with XML Data, Wet Signature and the Attachment, we use the FormEntryBuilder Class. You will find the XML files, upload control attachment and wet signature image that we are using in the <frevvo-home>\tomcat\webapps\api\apitutorial\Resources directory of the web application.
On the XML initialized Employee Information form, click the Save button to create a saved task:
Click on the Tasks link from the left menu to open the task list. Clicking on the perform icon of the saved task will load the saved form.
Edit the <frevvo-home>\tomcat\webapps\api\apitutorial\showTaskList.jsp file to see how the task list is embedded using the API.
First the showTaskList.jsp checks if the HTTP session contains a FormService instance with a valid user login. If not, then it redirects to login.jsp page to create a valid user login:
Then it gets the TaskFeed for current logged in user:
Using the Taskfeed we then get the Link to embed the users Task List. We use the URL Parameters container, center, resize and width to fit the task list to the space available in the embedded page.
Perform and Submit the saved task in the task list to create a form submission. Click on the Forms/Workflows link in the left menu. You should now see a View Submissions link against the Employee Information form:
Click on the View Submissions link to see the Employee Information form submissions:
Edit the <frevvo-home>\tomcat\webapps\api\apitutorial\showSubmissions.jsp file to see how we get the form submissions using the API. As explained in point 5 above, we pass the FormTypeID to the showSubmissions.jsp page in the View Submissions link.
The showSubmissions.jsp checks if the HTTP session contains a FormService instance with a valid user login. If not, then it redirects to login.jsp page to create a valid user login:
It also gets the user information stored in the user.info attribute of the HTTP session. The SubmissionFeed is available only for designer user login. We will not retrieve the submissions if the current logged in user is not a designer, i.e. alui.designer equals false:
Now we create SubmissionQuery q that will be used to retrieve the SubmissionFeed:
We get the FormTypeID that is sent as the URL parameter using request.getParameter( "formtypeId" ) and add it to the SubmissionQuery filter:
Note that if the formtypeId is not passed to the showSubmissions.jsp page (for example when you click on the Submissions link in the left menu) the filter will not be set and submissions for all the forms/workflows in the logged in users account will be listed.
Next we get the SubmissionFeed using the SubmissionQuery:
We will iterate over all the SubmissionEntries in the SubmissionFeed:
We get these details from each SubmissionEntry:
Link to Edit the submission:
Submission Form Name:
Submission Last Updated Date:
We use the doctypes iterator to iterate over four types of documents in entry.getDocumentLinks():
The four iterations over all entry.getDocumentLinks() collect:
Links to the Submission XMLs:
Link to the generated Submission PDF:
Links to the Wet Signature images of the submission:
Links to the uploaded attachments in the submission:
Click on the Logout link in the left menu. The users FormService session is destroyed and you will be redirected to the login.jsp page.
Edit the <frevvo-home>\tomcat\webapps\api\apitutorial\logout.jsp file.
The logout.jsp will check if the service instance is not null, that is if a user login already exists for the service instance. If yes, then we logout that user from the FormsService session and remove the service instance from the HTTP session:
Then it will redirect the user to the login.jsp page of the web application: