This content has been marked as final. Show 3 replies
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:
invokeSubmitProcess ===> updateDocumentStatus ===> invokePostProcess
Could you clarify for me your final answer above in how the Post Process is invoked AFTER submission of all the forms?
Additionally, I noticed the following table within the Adobe database:
However, I am unable to find any reference to this table within my applications. Is this table used at all and if so, what is its purpose?
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.