Once the final correspondence is generated, it can be bound
to a LiveCycle process. Depending on the project requirement, this
process can perform further actions such as archiving, printing,
emailing, or sending the review.
Implementation overviewThe postprocess bound to a letter template is called when
the final correspondence is submitted. You can create a process
that archives the letter, prints it, sends it via email, or that
uses any of the other services available in Workbench. When you
create the process in Workbench, use the following input variables:
inXMLDoc (xml type): The data submitted from the
final correspondence.
nPDFDoc (document type): The final rendered correspondence
(PDF), generated by the solution on submit. The submitted PDF can
be interactive or non-interactive, based on the system configuration
redirectURL (string type): (Optional) The URL to which
the user is redirect to after successful submission of the correspondence.
Important: The post process that you create needs
to be short-lived. To set the postprocess type:
Select and right-click on the post-process.
Choose Configure -> Advanced
In the Type drop-down list, choose short-lived.
Note: When you select the process in the Letter Template Editor
of the Manage Assets user interface, you can select from processes
that use at least one of the above input variables. The output variable
is optional.
Creating the processThe process that you bind to a letter template is called
when the final correspondence is submitted. You can create a process
that archives the letter, prints it, sends it via email, or that
uses any of the other services available in Workbench.
When you create the process in Workbench, use the following input
variables:
inXMLDoc (xml type): The data submitted from the
final correspondence.
inPDFDoc (document type): A rendering of the selected
letter template and XML, or portfolio template and XML.
Also use this output variable:
Note: When you select the process in the Letter Template Editor
of the Manage Assets user interface, you can select from processes
that use these input and output variables.
When the process is ready, deploy it using Workbench or Adobe
LiveCycle Administration Console.
About the submitted data XMLAs mentioned above, on submitting the correspondence, the
postprocess is called with the letter PDF and the corresponding
data XML. The data XML submitted to the postprocess also has additional
metadata corresponding to the submitted letter, such as the letter
name, submitted time (modificationDate), and so on. The metadata
is located in the ICC Control Data section, under the <icc:meta>
node. For example, the following is the structure of the XML data submitted
to the postprocess:
<DataRoot>
...
...
<!-- the usual XML data here -->
...
<!-- ICC Control Data -->
<icc:icc>
...
... <!-- this section would contain data corresponding to the selected modules -->
...
<!-- Metadata section -->
<icc:meta>
<!-- Any additional incoming metadata, that may have been sent from DC, and already present in the XML -->
<letter>[Letter name]</letter>
<modificationDate>[Letter submit date]</modificationDate>
<!-- Any other custom attributes/metada sent from DC via the "cm_" rule, will have entries in the XML here -->
</icc:meta>
</icc:icc>
</DataRoot>
Redirection on submitIf you want to extend the application to allow redirection
to a custom location (URL), you can design a process that performs
a set of operations and returns the redirect URL as a response.
A successful submit returns an XML with the following structure
as its response::
<iccSubmitResponse>
<redirect>{url}</redirect>
</iccSubmitResponse>
If the postprocess returns a URL, that URL is returned in the
response as shown above. Otherwise, the <redirect> element
is either not specified or empty. The caller is responsible for
validating the URL for security purposes. If a redirect URL is returned,
the user is then redirected to the custom location, which could be
a signature application that would let the user sign the finished
letter. You can add a tag such as "requireSignature", which you
key from in the customized version of the Letter service. To determine
whether a redirect is necessary, provide the ability to capture
a signature immediately after submitting a filled letter.
Submitting additional metadataIf necessary, you can customize the Create Correspondence
user interface to send additional metadata to the postprocess called
after submitting the letter. If the Submit servlet is called with
(request) parameters whose names start with "cm_", then those attributes
are added to the <icc:meta> section, under nodes
with the name following the string after cm_ and
the value of the node as the value of the parameter.
For example, if a request parameter cm_agent=Mark Robinson is
sent to the servlet, the <icc:meta> node
would have a child node <agent>Mark Robinson</agent>,
as shown in this example:
Example:
<DataRoot>
...
...
<!-- the usual XML data here -->
...
<!-- ICC Control Data -->
<icc:icc>
...
... <!-- this section would contain data corresponding to the selected modules -->
...
<!-- Metadata section -->
<icc:meta>
<!-- Any additional incoming metadata, that may have been sent from DC, and already present in the XML -->
<letter>SampleLetter</letter>
<modificationDate>2010-08-28T08:55:59</modificationDate>
<agent>Mark Robinson</agent>
<!-- Any other custom attributes/metada sent from DC via the "cm_" rule, will have entries in the XML here -->
</icc:meta>
</icc:icc>
</DataRoot>
Tools usedThis scenario uses Workbench to create the process, and
the Manage Assets user interface to bind the process to a letter
template.
Best practices/tips and tricksFollowing are”best practices” to be followed when creating
postprocesses: If the correspondence being submitted is
used for reloading at a later time, then archive the XML data passed
to the postprocess to a relevant location. The archive can be a
CRX repository or any other content store that can later be referenced
from the Create Correspondence application to reload the correspondence.
Do not modify the submitted XML data If modified, take care
to ensure that the schema is kept intact.
|
|
|