AEM
Forms can be invoked by using the AEM Forms Java API. When using
the AEM Forms Java API, you can use either the Invocation API or
Java client libraries. Java client libraries are available for services
such as the Rights Management service. These strongly typed APIs
let you develop Java applications that invoke AEM Forms.

The Invocation API are classes that are located in the com.adobe.idp.dsc package.
Using these classes, you can send an invocation request directly
to a service and handle an invocation response that is returned.
Use the Invocation API to invoke short-lived or long-lived processes
that were created by using Workbench.

The recommended way to programmatically invoke a service is to
use a Java client library that corresponds to the service as opposed
to the Invocation API. For example, to invoke the Encryption service,
use the Encryption service client library. To perform an Encryption
service operation, invoke a method that belongs to the Encryption
service client object. You can encrypt a PDF document with a password
by invoking the EncryptionServiceClient object’s encryptPDFUsingPassword method.

The Java API supports the following features:

RMI transport protocol for remote invocation

VM transport for local invocation

SOAP for remote invocation

Different authentication, such as user name and password

Synchronous and asynchronous invocation requests

Adobe
Developer website

The Adobe Developer website contains
the following articles that discuss invoking AEM Forms services
using the Java API:

Including AEM Forms Java library
files

To
programmatically invoke a AEM Forms service by using the Java API,
include required library files (JAR files) in your Java project’s
classpath. The JAR files that you include in your client application’s
classpath depend on several factors:

The AEM Forms service to invoke. A client application
can invoke one or more services.

Service-specific JAR files

The following table lists the JAR files that are required
to invoke AEM Forms services.

File

Description

Location

adobe-livecycle-client.jar

Must always be included in a Java client
application’s class path.

<install directory>/sdk/client-libs/common

adobe-usermanager-client.jar

Must always be included in a Java client
application’s class path.

<install directory>/sdk/client-libs/common

adobe-utilities.jar

Must always be included in a Java client
application’s class path.

<install directory>/sdk//client-libs/<app
server>

adobe-applicationmanager-client-sdk.jar

Required to invoke the Application Manager
service.

<install directory>/sdk/client-libs/common

adobe-assembler-client.jar

Required to invoke the Assembler service.

<install directory>/sdk/client-libs/common

adobe-backup-restore-client-sdk.jar

Required to invoke the Backup and Restore
service API.

<install directory>/sdk/client-libs/common

adobe-barcodedforms-client.jar

Required to invoke the barcoded forms service.

<install directory>/sdk/client-libs/common

adobe-convertpdf-client.jar

Required to invoke the Convert PDF service.

<install directory>/sdk/client-libs/common

adobe-distiller-client.jar

Required to invoke the Distiller service.

<install directory>/sdk/client-libs/common

adobe-docconverter-client.jar

Required to invoke the DocConverter service.

<install directory>/sdk/client-libs/common

adobe-contentservices-client.jar

Required to invoke the Document Management service.

<install directory>/sdk/client-libs/common

adobe-encryption-client.jar

Required to invoke the Encryption service.

<install directory>/sdk/client-libs/common

adobe-forms-client.jar

Required to invoke the Forms service.

<install directory>/sdk/client-libs/common

adobe-formdataintegration-client.jar

Required to invoke the Form Data Integration
service.

<install directory>/sdk/client-libs/common

adobe-generatepdf-client.jar

Required to invoke the Generate PDF service.

<install directory>/sdk/client-libs/common

adobe-generate3dpdf-client.jar

Required to invoke the Generate 3D PDF service.

<install directory>/sdk/client-libs/common

adobe-jobmanager-client-sdk.jar

Required to invoke the Job Manager service.

<install directory>/sdk/client-libs/common

adobe-output-client.jar

Required to invoke the Output service.

<install directory>/sdk/client-libs/common

adobe-pdfutility-client.jar

Required to invoke the PDF Utilities or
XMP Utilities service.

<install directory>/sdk/client-libs/common

adobe-reader-extensions-client.jar

Required to invoke the Acrobat Reader DC
extensions service.

<install directory>/sdk/client-libs/common

adobe-repository-client.jar

commons-codec-1.3.jar

Required to invoke the Repository service.

<install directory>/sdk/client-libs/common

<install directory>/sdk/client-libs\thirdparty

adobe-rightsmanagement-client.jar

namespace.jar

jaxb-api.jar

jaxb-impl.jar

jaxb-libs.jar

jaxb-xjc.jar

relaxngDatatype.jar

xsdlib.jar

Required to invoke the Rights Management
service.

If AEM Forms is deployed on JBoss, include all these
files.

<install directory>/sdk/client-libs/common

JBoss-specific
lib directory

adobe-signatures-client.jar

Required to invoke the Signature service.

<install directory>/sdk/client-libs/common

adobe-taskmanager-client-sdk.jar

Required to invoke the Task Manager service.

<install directory>/sdk/client-libs/common

adobe-truststore-client.jar

Required to invoke the Trust Store service.

<install directory>/sdk/client-libs/common

Connection mode and J2EE application JAR files

The following table lists the JAR files that are dependant
upon the connection mode and the J2EE application server on which
AEM Forms is deployed.

File

Description

Location

activation.jar

axis.jar

commons-codec-1.3.jar

commons-collections-3.1.jar

commons-discovery.jar

commons-logging.jar

dom3-xml-apis-2.5.0.jar

jaxen-1.1-beta-9.jar

jaxrpc.jar

log4j.jar

mail.jar

saaj.jar

wsdl4j.jar

xalan.jar

xbean.jar

xercesImpl.jar

commons-httpclient-3.1.jar

if AEM Forms is invoked using the SOAP mode, include these JAR files.

<install directory>/sdk/client-libs/thirdparty

jbossall-client.jar

if AEM Forms is deployed on JBoss Application Server, include this JAR file.

The size of jbossall-client.jar is significantly lesser in JBoss 5.1.0. This is because JBoss 4.2.1 jbossall-client.jar packages all the classes required to connect to JBoss 4.2.1 server. However, JBoss 5.1.0 jbossall-client.jar does not package any classes. This jar file contains a classpath reference to various client jar files used by the JBoss client applications.

When writing AEM Forms API-based programs where AEM Forms is running on JBoss 5.2.1, you must place jbossall-client.jar and all the referenced jars in a single folder and then include jbossall-client.jar in the classpath.

Required classes will not be found by the classloader if jbossall-client.jar and the referenced jars are not co-located.

JBoss client lib directory

If you deploy your client application on the same J2EE application server, you do not need to include this file.

jacorb.jar

jnp-client.jar

if AEM Forms is deployed on JBoss Application Server, include this JAR file.

JBoss client lib directory

If you deploy your client application on the same J2EE application server, you do not need to include this file.

wlclient.jar

if AEM Forms is deployed on BEA WebLogic Server®, then include this JAR file.

WebLogic-specific lib directory

If you deploy your client application on the same J2EE application server, you do not need to include this file.

com.ibm.ws.admin.client_6.1.0.jar

com.ibm.ws.webservices.thinclient_6.1.0.jar

if AEM Forms is deployed on WebSphere Application Server, include these JAR files.

(com.ibm.ws.webservices.thinclient_6.1.0.jar is required for web service invocation).

WebSphere-specific lib directory ([WAS_HOME]/runtimes)

If you deploy your client application on the same J2EE application server, you do not have to include these files.

Upgrading JAR files

If you are upgrading from LiveCycle to AEM Forms, it is recommeded
that you include the AEM Forms JAR files in your Java project’s
class path. For example, if you are using services such as the Rights
Management service, you will encounter a compatibility issue if
you do not include AEM Forms JAR files in your class path.

Assuming that you are upgrading to AEM Forms. To use a Java application
that invokes the Rights Management service, include the AEM Forms
versions of the following JAR files:

Setting connection properties

You
set connection properties to invoke AEM Forms when using the Java
API. When setting connection properties, specify whether to invoke
services remotely or locally, and also specify the connection mode
and authentication values. Authentication values are required if
service security is enabled. However, if service security is disabled,
it is not necessary to specify authentication values. (See Disabling
Service Security.)

The connection mode can either be SOAP or EJB mode. The EJB mode
uses the RMI/IIOP protocol, and the performance of the EJB mode
is better than the performance of the SOAP mode. The SOAP mode is
used to eliminate a J2EE application server dependency or when a
firewall is located between AEM Forms and the client application.
The SOAP mode uses the https protocol as the underlying transport
and can communicate across firewall boundaries. If neither a J2EE application
server dependency or a firewall is an issue, it is recommended that you
use the EJB mode.

To successfully invoke a AEM Forms service, set the following
connection properties:

DSC_DEFAULT_EJB_ENDPOINT: If you are using the EJB connection mode, this value represents the URL of the J2EE application server on which AEM Forms is deployed. To remotely invoke AEM Forms, specify the J2EE application server name on which AEM Forms is deployed. If your client application is located on the same J2EE application server, then you can specify localhost. Depending on which J2EE application server AEM Forms is deployed on, specify one of the following values:

JBoss: http://<ServerName>:8080 (default port)

WebSphere: iiop://<ServerName>:2809 (default port)

WebLogic: t3://<ServerName>:7001 (default port)

DSC_DEFAULT_SOAP_ENDPOINT: If you are using the SOAP connection mode, this value represents the endpoint to where an invocation request is sent. To remotely invoke AEM Forms, specify the J2EE application server name on which AEM Forms is deployed. If your client application is located on the same J2EE application server, you can specify localhost (for example, http://localhost:8080.)

The port value 8080 is applicable if the J2EE application is JBoss. If the J2EE application server is IBM® WebSphere®, use port 9080. Likewise, if the J2EE application server is WebLogic, use port 7001. (These values are default port values. If you change the port value, use the applicable port number.)

DSC_TRANSPORT_PROTOCOL: If you are using the EJB connection mode, specify ServiceClientFactoryProperties.DSC_EJB_PROTOCOL for this value. If you are using the SOAP connection mode, specify ServiceClientFactoryProperties.DSC_SOAP_PROTOCOL.

If you set this connection property to WebSphere, the java.naming.factory.initial value is set to com.ibm.ws.naming.util.WsnInitCtxFactory.

If you set this connection property to WebLogic, the java.naming.factory.initial value is set to weblogic.jndi.WLInitialContextFactory.

Likewise, if you set this connection property to JBoss, the java.naming.factory.initial value is set to org.jnp.interfaces.NamingContextFactory.

You can set the java.naming.factory.initial property to a value that meets your requirements if you do not want to use the default values.

Note: Instead of using a string to set the DSC_SERVER_TYPE connection property, you can use a static member of the ServiceClientFactoryProperties class. The following values can be used: ServiceClientFactoryProperties.DSC_WEBSPHERE_SERVER_TYPE, ServiceClientFactoryProperties.DSC_WEBLOGIC_SERVER_TYPE, or ServiceClientFactoryProperties.DSC_JBOSS_SERVER_TYPE.

DSC_CREDENTIAL_USERNAME: Specifies the AEM forms user name. For a user to sucessfully invoke a AEM Forms service, they need the Services User role. A user can also have another role that includes the Service Invoke permission. Otherwise, an exception is thrown when they attempt to invoke a service. If service security is disabled, it is not necessary to specify this connection property. (See Disabling Service Security.)

DSC_CREDENTIAL_PASSWORD: Specifies the corresponding password value. If service security is disabled, it is not necessary to specify this connection property.

DSC_REQUEST_TIMEOUT: The default request timeout limit for the SOAP request is 1200000 milliseconds (20 minutes). Sometime, a request can require longer time to complete the operation. For example, a SOAP request that retrieves a large set of records can require a longer timeout limit. You can use the ServiceClientFactoryProperties.DSC_REQUEST_TIMEOUT to increase the request call timeout limit for the SOAP requests.

note: Only SOAP-based invocations support the DSC_REQUEST_TIMEOUT property.

To set connection properties, perform the following tasks:

Create a java.util.Properties object
by using its constructor.

To set the DSC_DEFAULT_EJB_ENDPOINT connection
property, invoke the java.util.Properties object’s setProperty method
and pass the following values:

A string value that specifies the URL of the J2EE application
server that hosts AEM Forms

Bemærk:

If
you are using the SOAP connection mode, specify the ServiceClientFactoryProperties.DSC_DEFAULT_SOAP_ENDPOINT enumeration
value instead of the ServiceClientFactoryProperties.DSC_DEFAULT_EJB_ENDPOINT enumeration value.

To set the DSC_TRANSPORT_PROTOCOL connection
property, invoke the java.util.Properties object’s setProperty method
and pass the following values:

If you are using the SOAP
connection mode, specify the ServiceClientFactoryProperties.DSC_SOAP_PROTOCOL enumeration
value instead of the ServiceClientFactoryProperties.DSC_EJB_PROTOCOL enumeration value.

To set the DSC_SERVER_TYPE connection property,
invoke the java.util.Properties object’s setProperty method
and pass the following values:

You can use a com.adobe.idp.Context object
to invoke a AEM Forms service with an authenticated user (the com.adobe.idp.Context object represents
an authenticated user). When using a com.adobe.idp.Context object,
you do not need to set the DSC_CREDENTIAL_USERNAME or DSC_CREDENTIAL_PASSWORD properties.
You can obtain a com.adobe.idp.Context object when
authenicating users by using the AuthenticationManagerServiceClient object’s authenticate method.

The authenticate method
returns an AuthResult object that contains the results
of the authentication. You can create a com.adobe.idp.Context object
by invoking its constructor. Then invoke the com.adobe.idp.Context object’s initPrincipal method
and pass the AuthResult object, as shown in the
following code:

Context myCtx = new Context();
myCtx.initPrincipal(authResult);

Instead of setting
the DSC_CREDENTIAL_USERNAME or DSC_CREDENTIAL_PASSWORD properties,
you can invoke the ServiceClientFactory object’s setContext method
and pass the com.adobe.idp.Context object. When
using a AEM forms user to invoke a service, ensure that they have
the role named Services User that is required to
invoke a AEM Forms service.

The following code example shows
how to use a com.adobe.idp.Context object within
connection settings that are used to create an EncryptionServiceClient object.

Invoking scenarios

A client application running in its own JVM invokes clustered
AEM Forms instances.

Client application invoking a stand-alone
AEM Forms instance

The following diagram shows a client application running
in its own JVM and invoking a stand-alone AEM Forms instance.

In this scenario, a client application is running in its own
JVM and invokes AEM Forms services.

Bemærk:

This scenario is the invoking scenario on which
all Quick Starts are based.

Client application invoking clustered
AEM Forms instances

The following diagram shows a client application running
in its own JVM and invoking AEM Forms instances located in a cluster.

This scenario is similar to a client application invoking a stand-alone
AEM Forms instance. However, the provider URL is different. If a
client application wants to connect to a specific J2EE application
server, the application must change the URL to reference the specific
J2EE application server.

Referencing a specific J2EE application server is not recommended
because the connection between the client application and AEM Forms
is terminated if the application server stops. It is recommended
that the provider URL reference a cell-level JNDI manager, instead
of a specific J2EE application server.

Client applications that use the SOAP connection mode can use
the HTTP load balancer port for the cluster. Client applications
that use the EJB connection mode can connect to the EJB port of
a specific J2EE application server. This action handles the Load
Balancing between cluster nodes.

WebSphere

The
following example shows the contents of a jndi.properties file that
is used to connect to AEM Forms that is deployed on WebSphere.

Passing data to AEM Forms services
using the Java API

AEM Forms service operations typically consume
or produce PDF documents. When you invoke a service, sometimes it
is necessary to pass a PDF document (or other document types such
as XML data) to the service. Likewise sometimes it is necessary
to handle a PDF document that is returned from the service. The
Java class that enables you to pass data to and from AEM Forms services
is com.adobe.idp.Document.

AEM Forms services do not accept a PDF document as other data
types, such as a java.io.InputStream object or
a byte array. A com.adobe.idp.Document object can
also be used to pass other types of data, such as XML data, to services.

A com.adobe.idp.Document object is a Java serializable
type, so it can be passed over an RMI call. The receiving side can
be collocated (same host, same class loader), local (same host,
different class loader), or remote (different host). Passing of
document content is optimized for each case. For example, if the sender
and receiver are located on the same host, the content is passed
over a local file system. (In some cases, documents can be passed
in memory.)

Depending on the com.adobe.idp.Document object
size, the data is carried within the com.adobe.idp.Document object
or stored on the server's file system. Any temporary storage resources
occupied by the com.adobe.idp.Document object are
removed automatically upon the com.adobe.idp.Document disposal.
(See Disposing
Document objects.)

Sometimes it is necessary to know the content type of a com.adobe.idp.Document object
before you can pass it to a service. For example, if an operation
requires a specific content type, such as application/pdf,
it is recommended that you determine the content type. (See Determining
the content type of a document.)

The com.adobe.idp.Document object attempts to
determine the content type using the supplied data. If the content
type cannot be retrieved from the data supplied (for example, when
the data was supplied as a byte array), set the content type. To
set the content type, invoke the com.adobe.idp.Document object’s setContentType method.
(See Determining
the content type of a document)

If collateral files reside on the same file system, creating
a com.adobe.idp.Document object is faster. If collateral
files reside on remote file systems, a copy operation must be done,
which affects performance.

To prevent a memory leak in WebLogic while using
a com.adobe.idp.Document object, read the document
information in chunks of 2048 bytes or less. For example, the following
code reads the document information in chunks of 2048 bytes:

Creating documents

Create
a com.adobe.idp.Document object before you invoke
a service operation that requires a PDF document (or other document
types) as an input value. The com.adobe.idp.Document class
provides constructors that enable you to create a document from
the following content types:

A byte array

An existing com.adobe.idp.Document object

A java.io.File object

A java.io.InputStream object

A java.net.URL object

Creating a document based on a
byte array

The following code example creates a com.adobe.idp.Document object that
is based on a byte array.

Creating
a Document object that is based on a byte array

Document myPDFDocument = new Document(myByteArray);

Creating a document based on another
document

The following code example creates a com.adobe.idp.Document object that
is based on another com.adobe.idp.Document object.

Creating a document based on a
file

The
following code example creates a com.adobe.idp.Document object that
is based on a PDF file named map.pdf. This file is located
in the root of the C hard drive. This constructor attempts to set
the MIME content type of the com.adobe.idp.Document object
using the filename extension.

The com.adobe.idp.Document constructor that
accepts a java.io.File object also accepts a Boolean
parameter. By setting this parameter to true, the com.adobe.idp.Document object
deletes the file. This action means that you do not have to remove
the file after passing it to the com.adobe.idp.Document constructor.

Setting this parameter to false means that you
retain ownership of this file. Setting this parameter to true is
more efficient. The reason is because the com.adobe.idp.Document object
can move the file directly to the local managed area instead of
copying it (which is slower).

Creating
a Document object that is based on a PDF file

//Create a Document object based on the map.pdf source file
File mySourceMap = new File("C:\\map.pdf");
Document myPDFDocument = new Document(mySourceMap,true);

Creating a document based on an
InputStream object

The following Java code example creates a com.adobe.idp.Document object
that is based on a java.io.InputStream object.

Creating
a document based on an InputStream object

//Create a Document object based on an InputStream object
InputStream is = new FileInputStream("C:\\Map.pdf");
Document myPDFDocument = new Document(is);

Creating a document based on content
accessible from an URL

The following Java code example creates a com.adobe.idp.Document object
that is based on a PDF file named map.pdf. This file is located
within a web application named WebApp that is running
on localhost. This constructor attempts to set
the com.adobe.idp.Document object’s MIME content
type using the content type returned with the URL protocol.

The URL supplied to the com.adobe.idp.Document object
is always read at the side where the original com.adobe.idp.Document object
is created, as shown in this example:

Handling returned documents

Service operations that
return a PDF document (or other data types such as XML data) as
an output value return a com.adobe.idp.Document object.
After you receive a com.adobe.idp.Document object,
you can convert it to the following formats:

A java.io.File object

A java.io.InputStream object

A byte array

The following line of code converts a com.adobe.idp.Document object
to a java.io.InputStream object. Assume that myPDFDocument represents
a com.adobe.idp.Document object:

java.io.InputStream resultStream = myDocument.getInputStream();

Likewise, you can copy the contents of a com.adobe.idp.Document to
a local file by performing the following tasks:

Determining the content type of
a document

Determine the MIME type of
a com.adobe.idp.Document object by invoking the com.adobe.idp.Document object’s getContentType method.
This method returns a string value that specifies the content type
of the com.adobe.idp.Document object. The following
table describes the different content types that AEM Forms returns.

Disposing Document objects

When
you no longer require a Document object, it is
recommended that you dispose of it by invoking its dispose method.
Each Document object consumes a file descriptor
and as much as 75 MB of RAM space on your application’s host platform.
If a Document object is not disposed, then the
Java Garage collection process disposes it. However, by disposing
of it sooner by using the dispose method, you can
free the memory occupied by the Document object.

Invoking a service using a Java
client library

AEM Forms service operations can be invoked by using a
service’s strongly typed API, which is known as a Java client library.
A Java client library is a set of concrete classes that provide
access to services deployed in the service container. You instantiate
a Java object that represents the service to invoke instead of creating an InvocationRequest object
by using the Invocation API. The Invocation API is used to invoke
processes, such as long-lived processes, created in Workbench. (See Invoking
Human-Centric Long-Lived Processes.)

To perform a service operation, invoke a method that belongs
to the Java object. A Java client library contains methods that
typically map one-to-one with service operations. When using a Java
client library, set required connection properties. (See Setting
connection properties.)

After you set connection properties, create a ServiceClientFactory object that
is used to instantiate a Java object that lets you invoke a service.
Each service that has a Java client library has a corresponding
client object. For example, to invoke the Repository service, create
a ResourceRepositoryClient object by using its
constructor and passing the ServiceClientFactory object.
The ServiceClientFactory object is responsible
for maintaining connection settings that are required to invoke
AEM Forms services.

Although obtaining a ServiceClientFactory is
typically fast, some overhead is involved when the factory is first
used. This object is optimized for reuse and therefore, when possible,
use the same ServiceClientFactory object when you
are creating multiple Java client objects. That is, do not create
a separate ServiceClientFactory object for each
client library object that you create.

There is a User Manager setting that controls the lifetime of
the SAML assertion that is inside the com.adobe.idp.Context object
that affects the ServiceClientFactory object. This
setting controls all authentication context lifetimes throughout
AEM Forms, including all invocations performed by using the Java
API. By default, the time period in which a ServiceCleintFactory object
can be used is two hours.

Bemærk:

To explain how to invoke a service by using
the Java API, the Repository service’s writeResource operation
is invoked. This operation places a new resource into the repository.

You can invoke the Repository service by using a Java client
library and by performing the following steps:

Include client JAR files, such as the adobe-repository-client.jar,
in your Java project’s class path. For information about the location
of these files, see Including
AEM Forms Java library files.

Create a ResourceRepositoryClient object
by using its constructor and passing the ServiceClientFactory object.
Use the ResourceRepositoryClient object to invoke
Repository service operations.

Create a RepositoryInfomodelFactoryBean object
by using its constructor and pass null. This object
lets you create a Resource object that represents
the content that is added to the repository.

Create a Resource object by invoking the RepositoryInfomodelFactoryBean object’s newImage method
and passing the following values:

A unique ID value
by specifying new Id().

A unique UUID value by specifying new Lid().

The name of the resource. You can specify the file name of
the XDP file.

Cast the return value to Resource.

Create a ResourceContent object by invoking
the RepositoryInfomodelFactoryBean object’s newImage method
and casting the return value to ResourceContent.
This object represents the content that is added to the repository.

Invoking a short-lived process
using the Invocation API

You can invoke a short-lived process using the Java Invocation
API. When you invoke a short-lived process using the Invocation
API, you pass required parameter values by using a java.util.HashMap object.
For each parameter to pass to a service, invoke the java.util.HashMap object’s put method and
specify the name-value pair that is required by the service in order
to perform the specified operation. Specify the exact name of the
parameters that belong to the short-lived process.

Create a ServiceClient object by using its
constructor and passing the ServiceClientFactory object.
A ServiceClient object lets you invoke a service
operation. It handles tasks such as locating, dispatching, and routing
invocation requests.

Create a java.util.HashMap object by using
its constructor.

Invoke the java.util.HashMap object’s put method
for each input parameter to pass to the long-lived process. Because
the MyApplication/EncryptDocument short-lived process
requires one input parameter of type Document,
you only have to invoke the put method once, as
shown in the following example.

Create an InvocationRequest object by invoking
the ServiceClientFactory object’s createInvocationRequest method
and passing the following values:

A string value that
specifies the name of the long-lived process to invoke. To invoke
the MyApplication/EncryptDocument process, specify MyApplication/EncryptDocument.

A string value that represents the process operation name.
Typically the name of a short-lived process operation is invoke.

The java.util.HashMap object that contains
the parameter values that the service operation requires.

A Boolean value that specifies true, which
creates a synchronous request (this value is applicable to invoke
a short-lived process).

Send the invocation request to the service by invoking the ServiceClient object’s invoke method
and passing the InvocationRequest object. The invoke method
returns an InvocationReponse object.

Bemærk:

A long-lived process can be invoked by passing
the value false as the fourth parameter of the createInvocationRequest method.
Passing the value false creates an asynchronous request.

Retrieve the process’s return value by invoking the InvocationReponse object’s getOutputParameter method
and passing a string value that specifies the name of the output
parameter. In this situation, specify outDoc (outDoc is
the name of the output parameter for the MyApplication/EncryptDocument process).
Cast the return value to Document, as shown in
the following example.

Create a java.io.File object and ensure
that the file extension is .pdf.

Invoke the com.adobe.idp.Document object’s copyToFile method
to copy the contents of the com.adobe.idp.Document object
to the file. Ensure that you use the com.adobe.idp.Document object
that was returned by the getOutputParameter method.