|
There are various patterns in terms of how this integration
can be achieved:
URL-based invocation: One way to call the Create
Correspondence application from a custom portal is to prepare the
URL with the following request parameters: the identifier for
the letter template (using the cmLetterId parameter), or the
name of the Letter template (using the cmLetterName parameter)
the URL to the XML data fetched from the desired data source
(using the cmDataUrl parameter).
For
example, the custom portal would prepare the URL as http://<server>:<port>/content/cm/createcorrespondence.html?cmLetterId=<letter identifier>&cmDataUrl=<data URL>,
which could be the href from a link on the portal. If the portal
has the Letter template name at hand, then the URL could be http://<server>:<port>/content/cm/createcorrespondence.html?cmLetterName=<letter name>&cmDataUrl=<data URL>.
Note: It
is expected the data to call Create Correspondence has been saved/uploaded
at the given <data URL> before calling of
the Create Correspondence application. This could either be done
from the custom portal itself, or via a different backend process.
Calling
in such a way is not secure since the necessary parameters are passed along
as a GET request, by exposing the same (clearly visible) in the
URL.
Inline data-based invocation: Another (and a more
secure) way to call the Create Correspondence application could
be to simply hit the URL at http://<server>:<port>/content/cm/createcorrespondence.html,
while sending the parameters and data to call the Create Correspondence
application as a POST request (hiding them from the end user). This
also means that you can now pass along the XML data for the Create
Correspondence application inline (as part of the same request,
using the cmData parameter), which was not possible/ideal
in the previous approach.
|
|
|
