Scénario : Création de post-processus

Comme expliqué plus haut, lors de l’envoi de la correspondance, le post-processus est appelé avec la lettre PDF et les données XML y correspondant. Les données XML envoyées au post-processus comprennent également des métadonnées additionnelles relatives à la lettre envoyée, comme le nom de la lettre, l’heure à laquelle elle a été envoyée (la date de modification), etc. Les métadonnées se trouvent dans la section ICC Control Data (données de contrôle ICC), sous le nœud <icc:meta>. Par exemple, ci-dessous se trouve la structure des données XML envoyées au post-processus :

<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>

Si vous souhaitez étendre l’application pour permettre la redirection vers un emplacement personnalisé (URL), vous pouvez élaborer un processus exécutant un ensemble d’opérations et renvoyant l’URL de redirection en réponse. Un envoi fructueux renvoie en réponse un fichier XML dont la structure est la suivante :

<iccSubmitResponse> 
    <redirect>{url}</redirect> 
</iccSubmitResponse>

Si le post-processus renvoie une URL, celle-ci est renvoyée en réponse comme expliqué ci-dessus : Sinon, l’élément <redirect> est soit vide soit non indiqué. L’appelant est responsable de la validation de l’URL en matière de sécurité. Lorsqu’une URL de redirection est renvoyée, l’utilisateur est redirigé vers l’emplacement personnalisé, qui peut être une application de signature permettant à l’utilisateur de signer la lettre terminée. Vous pouvez ajouter une balise, telle que requireSignature, que vous saisissez dans la version personnalisée du service Letter. Pour déterminer si une redirection est nécessaire, offrez la possibilité de signer une lettre terminée immédiatement après son envoi.

Si cela est nécessaire, vous pouvez personnaliser l’interface utilisateur de création de correspondance de manière à envoyer des métadonnées additionnelles au post-processus appelé après l’envoi d’une lettre. Si la servlet d’envoi Submit est appelée avec des paramètres (de demande) dont le nom commence par « cm_ », ces attributs sont ajoutés à la section <icc:meta> sous des nœuds dont le nom correspond aux chaînes de caractères apparaissant après cm_ et dont la valeur est celle du paramètre duquel ils tirent leur nom.

Par exemple, si un paramètre de demande cm_agent=Mark Robinson est envoyé à la servlet, le nœud <icc:meta> aura un nœud enfant nommé <agent>Mark Robinson</agent>, comme dans l’exemple ci-dessous :

Exemple :

<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>