Q 1. I need some clarification on the "Processes" underneath an Application's "Profile" within the DDC_Admin UI. I see "Pre", "Post", "Application", "Context" and "Document chain" as listed events but I have no idea when these events fire and what processes I should call as a result of them doing so.
"Pre" - invoked before document filling starts for this application.
"Post" - invoked after all the documents in application are submitted.
"Application" - not used.
"Context" - invoked for retrieving contexts (questions) for a particular application. If this process is not defined default implementation fetches contexts from DB.
"Document Chain" - invoked to generate document chain, depending on the context values. If this process is not defined default implementation creates document chain based on the rules (mapping of context and documents) defined through Admin UI.
Q 2. As I understand it, the submission of a form that was rendered within its iFrame can trigger a process such as an approval process wherein this form is, perhaps, sent through an approval process. Where do I specify the approval process to run and how do I get the form itself to be input to this process?
Answer: For each form a submitProcess can be defined which is invoked on submission of this form. This process can be defined in the Document Library Panel of DDC_Admin UI. The approval process is required to be specified in this submitProcess. Submitted data is passed as one of the parameters to this process.
Q 3. The "Building Dynamic Data Capture Solutions" technical guide explains that "At the completion of the form chain, the Dynamic Data Captures framework triggers a completion event that ties together the different processes that each mini application is associated with and aggregates all the documents into one package". To me, this sounds as though all of the forms the user filled in are packaged up together as either one PDF document or as a PDF package. However, I'm unsure as to where this document ends up or how I can even use it.
Answer: The DDC framework invokes the processes on defined events, however logic of packaging submitted forms is required to be implemented in relevant processes. Following two custom processes are required to be defined:
Submit Form process - Invoked on each form submission. This process should save the submitted form to some temporary storage.
Post process - Invoked after submission of all the forms. This process should retrieve all the submitted forms from temp storage and create a PDF Package out of it.
One thing I noticed was that in the HandleSubmission orchestration, under the DDC category, there is no logic in place to wait for all forms of a chain to be submitted prior to calling the PostProcess. The orchestration for HandleSubmission simply goes:
invokePostProcess is not a direct call to the actual PostProcess, rather this is a call to an internalOperation, which intern invokes the actual PostProcess. The internalOperation checks for submission of all the mandatory forms before invoking the PostProcess.
ddc_document_attachments is not being used anywhere.
Answers to other questions are as follows:
Q. What is the difference between the Submit Process field within the Administrative UI (field within Document Library interface) and the Generate Process field (found by going into a documents properties within the Application UI)? My first thought would be that the Generate Process field would be for specifying a custom render process for the document such as one that Reader extends the form so it can connect to various web services.
Answer: You are right, the Generate Process is a custom process used to generate a Document and the Submit Process is a custom process invoked at the time of Document submission.
Q. Is the Description field within the Document Library of the Administrative UI used for anything or is it simply meant to be a description within Administrative UI?
Answer: The description field is passed to the client application as part of DocumentTO. The client application can use it in whatever way. For example it could be shown as a help text in the client UI.
Q. What would the purpose be of specifying Input Data for a document in the Document Library interface? Does this data overwrite the data already in the Input Document Name form and if so why would one care to do so?
Answer: The Input Document Name field specifies the name of the template used to render the form. Input Data represents XML data that should be pre-populated in the generated form.
Q. What are Target URL and Base URL of the Document Library used for?
Answer: Target URL: represent the location of the Servlet where Form data would be submitted. This URL is computed automatically by the DDC application, so it can be left blank in Admin UI.
Base URL: represents the URL to download images in case of HTML forms. It can be left blank for PDF forms. Please go through the LC Forms documentation for more details about these.
Q. What DefaultRules, DeserializeToken and SerializeToken orchestrations actually do?
Answer: DefaultRules is not used.
DDC maintains session data across API invocations. SerializeToken and DeserializeToken processes are used to save and retrieve this session data. The default implementation saves the data to the file system, however these processes can be customized to save session data at some other place.