Tipos de datos admitidos
Se admiten los siguientes tipos de datos al invocar servicios de AEM Forms mediante solicitudes REST:
-
Tipos de datos primitivos de Java, como cadenas y números enteros
-
com.adobe.idp.Document
tipo de datos -
Tipos de datos XML como
org.w3c.Document
yorg.w3c.Element
-
Objetos de colección como
java.util.List
yjava.util.Map
Estos tipos de datos se aceptan comúnmente como valores de entrada para los procesos creados en Workbench.
Si se invoca un servicio Forms con el método de POST HTTP, los argumentos se pasan dentro del cuerpo de la solicitud HTTP. Si la firma del servicio AEM Forms tiene un parámetro de entrada de cadena, el cuerpo de la solicitud puede contener el valor de texto del parámetro de entrada. Si la firma del servicio define varios parámetros de cadena, la solicitud puede seguir la notación
application/x-www-form-urlencoded
de HTTP con los nombres de parámetro utilizados como nombres de campo del formulario.Si un servicio de Forms devuelve un parámetro de cadena, el resultado es una representación textual del parámetro de salida. Si un servicio devuelve varios parámetros de cadena, el resultado es un documento XML que codifica los parámetros de salida en el siguiente formato:
<result> <output-paramater1>output-parameter-value-as-string</output-paramater1> . . . <output-paramaterN>output-parameter-value-as-string</output-paramaterN> </result>
NOTEEl valoroutput-paramater1
representa el nombre del parámetro de salida.Si un servicio de Forms requiere un parámetro
com.adobe.idp.Document
, el servicio solo se puede invocar mediante el método de POST HTTP. Si el servicio requiere un parámetrocom.adobe.idp.Document
, el cuerpo de la solicitud HTTP se convierte en el contenido del objeto de documento de entrada.Si un servicio de AEM Forms requiere varios parámetros de entrada, el cuerpo de la solicitud HTTP debe ser un mensaje MIME de varias partes, tal como se define en RFC 1867. (RFC 1867 es un estándar que utilizan los exploradores web para cargar archivos en sitios web). Cada parámetro de entrada debe enviarse como una parte independiente del mensaje multipart y codificarse en el formato
multipart/form-data
. El nombre de cada artículo debe coincidir con el nombre del parámetro.Las listas y los mapas también se utilizan como valores de entrada para los procesos de AEM Forms creados en Workbench. Como resultado, puede utilizar estos tipos de datos cuando utilice una solicitud REST. No se admiten matrices Java porque no se utilizan como valor de entrada para un proceso de AEM Forms.
Si un parámetro de entrada es una lista, un cliente REST puede enviarla especificando el parámetro varias veces (una vez para cada elemento de la lista). Por ejemplo, si A es una lista de documentos, la entrada debe ser un mensaje de varias partes formado por varias partes denominadas A. En este caso, cada pieza denominada A se convierte en un elemento de la lista de entrada. Si B es una lista de cadenas, la entrada puede ser un mensaje
application/x-www-form-urlencoded
que consta de varios campos llamados B. En este caso, cada campo de formulario denominado B se convierte en un elemento de la lista de entrada.Si un parámetro de entrada es un mapa y es el parámetro de entrada solo de servicios, cada parte o campo del mensaje de entrada se convierte en un registro de clave o valor en el mapa. El nombre de cada parte/campo se convierte en la clave del registro. El contenido de cada parte/campo se convierte en el valor del registro.
Si un mapa de entrada no es el parámetro de entrada solo de servicios, cada registro de clave/valor que pertenece al mapa se puede enviar utilizando un parámetro denominado como concatenación del nombre del parámetro y la clave del registro. Por ejemplo, se puede enviar un mapa de entrada denominado
attributes
con una lista de los siguientes pares clave/valores:attributesColor=red
attributesShape=box
attributesWidth=5
Esto se traduce en un mapa de tres registros:
Color=red
,Shape=box
yWidth=5
.Los parámetros de salida de los tipos de lista y asignación pasan a formar parte del mensaje XML resultante. La lista de resultados se representa en XML como una serie de elementos XML con un elemento para cada elemento de la lista. A cada elemento se le asigna el mismo nombre que al parámetro de lista de salida. El valor de cada elemento XML es una de dos cosas:
-
Una representación de texto del elemento de la lista (si la lista consta de tipos de cadena)
-
Dirección URL que señala al contenido del documento (si la lista consta de
com.adobe.idp.Document
objetos)El siguiente ejemplo es un mensaje XML devuelto por un servicio que tiene un único parámetro de salida denominado list, que es una lista de enteros.
<result> <list>12345</list> . . . <list>67890</list> </result>
En el mensaje XML resultante se representa un parámetro de mapa de salida como una serie de elementos XML con un elemento para cada registro del mapa. A cada elemento se le asigna el mismo nombre que a la clave del registro de mapa. El valor de cada elemento es una representación textual del valor del registro del mapa (si el mapa consiste en registros con un valor de cadena) o una dirección URL que señala al contenido del documento (si el mapa consiste en registros con el valorcom.adobe.idp.Document
). A continuación se muestra un ejemplo de un mensaje XML devuelto por un servicio que tiene un único parámetro de salida denominadomap
. Este valor de parámetro es un mapa que consta de registros que asocian letras concom.adobe.idp.Document
objetos.<result> http://localhost:8080/DocumentManager/docm123/4567 . . . <Z>http://localhost:8080/DocumentManager/docm987/6543</Z> </result>
Invocaciones asincrónicas
Algunos servicios de AEM Forms, como los procesos de larga duración centrados en el ser humano, requieren mucho tiempo para completarse. Estos servicios se pueden invocar asincrónicamente de forma no bloqueante. (Consulte Invocar procesos de larga duración centrados en el ser humano.)
Se puede invocar un servicio de AEM Forms asincrónicamente reemplazando services
con async_invoke
en la dirección URL de invocación, como se muestra en el ejemplo siguiente.
http://localhost:8080/rest/async_invoke/SomeService. SomeOperation?integer_input_variable=123&string_input_variable=abc
Esta URL devuelve el valor del identificador (en formato "text/plain") del trabajo responsable de esta invocación.
El estado de la invocación asincrónica se puede recuperar usando una URL de invocación con services
sustituido por async_status
. La dirección URL debe contener un parámetro job_id
que especifique el valor del identificador del trabajo asociado con esta invocación. Por ejemplo:
http://localhost:8080/rest/async_status/SomeService.SomeOperation?job_id=2345353443366564
Esta URL devuelve un valor entero (en formato "texto/sin formato") que codifica el estado del trabajo según la especificación del Administrador de trabajos (por ejemplo, 2 significa en ejecución, 3 significa completado, 4 significa fallido, etc.).
Si se completa el trabajo, la dirección URL devuelve el mismo resultado que si el servicio se hubiera invocado sincrónicamente.
Una vez completado el trabajo y recuperado el resultado, el trabajo se puede eliminar usando una URL de invocación con services
y se sustituye por async_dispose
. La dirección URL también debe contener un parámetro job_id
que especifique el valor del identificador del trabajo. Por ejemplo:
http://localhost:8080/rest/async_dispose/SomeService.SomeOperation?job_id=2345353443366564
Si el trabajo se elimina correctamente, esta dirección URL devuelve un mensaje vacío.