Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Submitting xml data and thereby kicking off LiveCycle Process

Avatar

Level 8
Level 8
I have a simple form where I collect the data and put it in a field which contains xml. I also have a process that should be started when I click a button on the form. Hence I have made the databinding for the process SOAP endpoint and have made the binding to the xml-text field in the form.



However something is wrong, because nothing happens when I click the button.



So how do I submit xml-data to a LiveCycle process to kick it off through the form.



Sincerely

Kim
6 Replies

Avatar

Level 8
Level 8
Hi,



I worked it out my self, thanks anyway. Just ask if you have a similar problem.



Sincerely

Kim

Avatar

Former Community Member
Hi,



Is is possible to connect database through a stand-alone PDF template.



Please provide me a solution.?

Avatar

Former Community Member
Hello



I have a similar requirement and looking for a real neat solution for implementing this:



I have developed a pdf form using livecycle designer and it has a submit button in it. The form is published to our organization website. What we would like to do is, when the user opens and fills up the pdf form either on web browser / or after downloading to their desktop, users should be able to post the data in the form directly into our IMS database.



I understand that we need to use a Submit button with Submit As property set to XML. But, what I would like to know is the architecture and how the components communicate here. i.e. for our design document. Our users are not connected to the org. network but just to the internet where they can find this pdf form.



I am assuming that we would need to lay out these components on the diagram but not very sure of the order in which the data is flowing from LiveCycle and WebServer.



1. Web browser

2. Internet Connection

3. Webserver (this is where the org. website is and the form is located on the website)

4. LiveCycle ES on an application server?

5. Database tier.



Appreciate if anyone could tell me exactly the steps and the data flow.

Avatar

Former Community Member
Dear Mr. Ram KM,



1. It is possible to communicate the stand-alone pdf to the database via webservices.

2. webservices are best used for offline forms having submit button functionality.

3. we can call webservices(WSDL) by using javaScript calls.

3. It is also possible to communicate with the database by using data source. But I wouldn't recommend you to use this, because each client machine should contain DSN source.

4. It is not known that stand-alone pdf communicate with the database by using JDBC calls via thin driver.



I am guessing a stand-alone pdf shouldn't contain JVM. As we all know that this methodology is possible at the server side.



The above solution is given to the best of my knowledge.



Regards,



Ramesh Punugubati

Adobe Developer

Tcs,India.

Avatar

Former Community Member
Hello Ramesh

Thanks so much for the response. Can you briefly tell me the architecture I would use if Iam using WSDL. Like, what web browser, application server, livecycle ES do I need and the order in which they communicate. I need to put this in a diagram for my design document.



Here is what I am thinking.



1. Web browser sends an HTTP request to the webserver when user tries to open the PDF form.

2. Web server sends an HTTP response by allowing the user to open the PDF.

3. User fills out the PDF and clicks on Submit (In LiveCycle designer 'submit as' property set to WSDL and url of the servlet is mentioned).

4. Webserver forwards the submit request to the appropriate servlet that is located in the application server.

5. Servlet is executed on the application server and generates an xml.

(At this point I am not sure what the role of LiveCycle ES is)

6. The xml is picked up by IMS connect which is the IBM interface for Java and IMS database.



Please let me know if I am correct and also provide my suggestions.



Appreciate your help.

4.

Avatar

Former Community Member
Dear Mr. Ram KM,



The business mentioned above by you was absolutely perpect.



Adobe LiveCycle® ES (Enterprise Suite) is an integrated server solution that blends data capture, information assurance, document output, process management, and content services.



I may guess you have to install ADOBE LIVECYCLE WORKBENCH ES. The Adobe liveCycle Designer ES comes with Workbench ES once you installed. Please go through the below information, you may get some idea.

---------------------------------



1. Significance of folders in Documentum Repository (for all regions)

WorkBench -> where all work in progress or finalized templates should reside. Designer must carry his/her development of Form/Template design in this folder.

Schema -> where the XML Schema (Using which data needs to bound to the template) should reside. This schema should be the same across the entire region (dev, UAT, Prod).

Templates -> This is the run time folder. CPR application points to this folder while searching for templates. Designer should never work on this folder or move/copy any template from WorkBench to this folder. This action will be taken care of by CPR application.

Master Fragment Library -> All the fragments should reside inside this folder. Once one fragment is changed in this folder then change will be reflected immediately to all the templates that use this fragments.







NEW TEMPLATE DESIGN



2. Design approach through workbench ES.

Designer selects UAT region through WorkBench ES to do the development of the Forms/Templates.







Designer opens up an existing form/letter or creates a new form/letter through designer in Workbench ES

He/She caries out the design (forms/letters) in Workbench folder.

He/She carries out the design of fragments in Master Fragment Library folder.

Once designer is satisfied with design he/she right clicks on the document and goes to the history popup.







Select the latest document in the list and click on Save as button in the popup screen to save it to the local hard disk or any file system.

Designer now goes to CPR Application and click on Add button.







The Add popup opens up.







Designer clicks on Browse button and adds the letter/forms she had downloaded to his/her disk and adds corresponding Meta data. He/She then hits Done. At this point behind the scene CPR application puts the corresponding letter/Form into Templates folder with all the meta data set.

The UAT test on the newly uploaded templates then happens.

Once the UAT is successful then the corresponding templates need to be promoted to Production.



First Step: Promoting new Fragments to Production



Administrator directly logs into Production fragment library folder and creates the fragments again in production. This needs to be done very carefully as this fragments will be available immediately for end users (on click of Save in the designer).



Note: The downloaded fragments (from UAT region) can be moved to production directly using drag and drop feature of Workbench ES.



Second Step: Promoting new templates to Production



If UAT is successful Administrator then uploads the template file into production the way he/she did in UAT region. He/she needs to put appropriate meta data in production also.



EXISTING TEMPLATE MODIFICATION



3. Design approach through workbench ES.

Designer selects UAT region through WorkBench ES to do the change of the existing Forms/Templates.







Designer opens up an existing form/letter or creates a new form/letter through designer in Workbench ES

He/She caries out the design (forms/letters) in Workbench folder.

He/She carries out the design of fragments in Master Fragment Library folder.

Once designer is satisfied with design he/she right clicks on the document and goes to the history popup..







Select the latest document in the list and click on Save as button in the popup screen to save it to the local hard disk or any file system.

Designer now goes to CPR Application and finds the templates he/she wants to modify.

Designer highlights the corresponding row and hits on Modify.







The Modify popup opens up.

Designer clicks on Browse button and adds the letter/forms she had downloaded to his/her disk and edits corresponding Meta data (if needed). He/She then hits Done. At this point behind the scene CPR application puts the corresponding letter/Form into Templates folder with all the meta data set. Also it inactivates the older version if any.

The UAT test on the newly uploaded templates then happens.

Once the UAT is successful then the corresponding templates need to be promoted to Production.



First Step: Promoting existing Fragments to Production



Administrator directly logs into Production fragment library folder and updates the fragments again in production. This needs to be done very carefully as this fragments will be available immediately for end users (on click of Save in the designer).



Note: The downloaded fragments (from UAT region) can be moved to production directly using drag and drop feature of Workbench ES.



Second Step: Promoting existing templates to Production



If UAT is successful Administrator then uploads the template file into production the way he/she did in UAT region. He/she needs to put appropriate meta data in production also.



-----------------------------------------------------

FormFragsRenderPdfServlet:

---------------------------



import java.util.Properties;

import java.io.*;



import javax.servlet.ServletContext;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.ServletOutputStream;



import com.adobe.etech.FileUtils;

import com.adobe.formServer.client.EJBClient;

import com.adobe.formServer.interfaces.*;



import com.adobe.pso.eforms.model.XDPWrapper;

import com.adobe.pso.eforms.model.FragmentMetadata;

import com.adobe.pso.eforms.model.TemplateMetadata;

import com.adobe.pso.eforms.model.XSDReference;

import com.adobe.pso.eforms.util.FormServerDefinition;

import com.adobe.pso.eforms.util.RenderFormOptions;

import com.adobe.pso.eforms.util.RenderUtils;

import com.adobe.pso.eforms.util.XDPUtils;



/**

* @version 1.0

* @author

*/

public class FormFragsRenderPDFServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

System.err.println("RenderPdfServletScott - doGet");

try {



ServletContext context = this.getServletContext();



// 1. Construct the web app's context url

String contextURL = request.getScheme()

+ "://"

+ request.getServerName()

+ ":"

+ request.getServerPort()

+ request.getContextPath();



// 1a. If making an EJB remote call to FS, construct the JNDI properties object.

Properties jndiProps = new Properties();

jndiProps.setProperty("java.naming.factory.initial","com.ibm.websphere.naming.WsnInitialContextFactory");

jndiProps.setProperty("java.naming.factory.url.pkgs","com.ibm.ws.naming");

jndiProps.setProperty("java.naming.provider.url","corbaloc:iiop:127.0.0.1:2809");



// 2. Create FormServerDefinition object to define the form server invocation method

FormServerDefinition fServDef = new FormServerDefinition();

fServDef.setInvocationMethod(FormServerDefinition.EJB_REMOTE);

fServDef.setJndiProperties(jndiProps);



//Specify the path to load the data from

byte[] cXMLData = getBytesFromFile(new File (context.getRealPath("/data/data.xml")));



// 3. Set the various options for rendering the form. The setFormQuery() method establishes the name

// of the temporary file created on the filesystem to hold the "pre-rend