Propuesta de valor
¿Cómo comunicarse con Webcenter Content desde una aplicación Java Enterprise Edition?
Primeramente, vamos a hacer una pequeña introducción explicando qué es RIDC y cuáles son sus características. RIDC (Remote Intradoc Client) es una API nativa de Java que proporciona comunicación con Webcenter Content. Esta API provee un Wrapper para manejar las conexiones, la seguridad y las distintas especificaciones del protocolo.
Algunas de las principales características de esta API son las siguientes:
- Se puede establecer una comunicación a través del protocolo HTTP o una conexión Intradoc.
- Existe una serie de parámetros de configuración del lado del cliente para establecer dicha comunicación (tamaño del pool de conexiones, tiempos de espera etc.)
- Para todas las peticiones HTTP se requiere el uso de credenciales.
- La invocación de los servicios de la API se realiza a través de un objeto Databinder.
- Los recursos para realizar la invocación deben ser cerrados una vez finalizada la conexión ya que RIDC agrupa las conexiones.
- Esta API permite comunicación SSL con Webcenter Content.
Hasta aquí la parte teórica, a partir de ahora explicaremos cómo crear un cliente y distintos ejemplos de algunos de los principales servicios que provee la API.
Ejemplo práctico de llamada a un servicio
En primer lugar, para poder utilizar la API hay que añadir a las dependencias del proyecto en cuestión el JAR que contiene todas las librerías que se puede encontrar en la página oficial de Oracle, donde se descargan sus productos.
En este ejemplo se va a trabajar con una conexión Intradoc. Para inicializar un cliente sería de la siguiente manera:
Para invocar cualquier servicio se usa un objeto DataBinder, a través del cliente que se haya creado. No se trata de otra cosa que un mapa, cuyo primer elemento que se le va a configurar es el nombre del servicio al que se quiere llamar.
A continuación se muestra un ejemplo de cómo llamar a un servicio. En este caso se trata de una consulta a través del servicio ‘GET_SEARCH_RESULTS’.
Este DataBinder que se obtiene del objecto ServiceResponse contiene la respuesta a la petición del servicio de Webcenter Content. A continuación, en el código se muestra cómo el resultado de la query se obtiene de un objeto ResultSet llamado ‘SearchResults’.
Una vez obtenido este conjunto de resultados, se puede iterar por cada una de las rows.
Cómo crear un cliente y distintos ejemplos de algunos de los principales servicios que provee la API RIDC. Comunicación con Webcenter Content.#StepForwardClick to tweet
|
Servicios Check-in & Check-out
Una vez explicado cómo se realiza una petición de un servicio cualquiera, vamos a explicar con mayor profundidad dos de los servicios que más se utilizan dentro de la API, ya que se corresponden a dos de las acciones principales dentro de Webcenter Content.
1. CHECK – IN
Es el proceso por el cual un usuario sube un contenido a Webcenter Content, y para ello debe tener los permisos necesarios. El contenido se compone de una serie de matadatos y un Primary file, que no es más que el archivo que se quiere almacenar.
Este servicio se denomina ‘CHECKIN_UNIVERSAL’ y tiene diversos parámetros a configurar:
En primer lugar, todos los metadatos obligatorios en cualquier contenido: dDocName, dDocTitle, dDocAccount etc. Aunque por ejemplo, en el caso del dDocName puede no ser necesario, si en Webcenter Content se ha definido la secuencia automática de identificadores únicos. Posteriormente, se añadirán todos los metadatos customizados que se deseen.
Por último, se añade el archivo que actuará como Primary File del contenido, pasando el InputStream del archivo, el nombre del mismo y el boolean de si el archivo está disponible en ese momento.
Variantes que hay a la hora de subir contenidos:
- Subir un contenido sin ningún primary file, es decir, solo metadatos. Para ello, se debe añadir al mapa de parámetros la siguiente clave-valor: dataBinder.putLocal("createPrimaryMetaFile","1");
Y respecto al genérico, eliminar la línea donde se añade el primary file. De este modo, Webcenter content generará automáticamente un archivo de extensión htm, que actuará como un primary file dummy.
- Subir un contenido con un primary file y un alternate file. En este caso, habrá que añadir un nuevo archivo con respecto al ejemplo principal. See añade la línea de código:
dataBinder.addFile("alternateFile", new TransferFile(inputStream, filename, inputStream.available()));
De esta forma, se obtendrá un archivo principal y el alternate actuará como rendition web del principal. Por defecto, el primary y el alternate file no pueden tener la misma extensión a no ser que se añada una propiedad para ello en el archivo config.cfg.
2. CHECK – OUT
Se trata de un proceso por el cual el usuario bloquea un contenido para que otros usuarios no puedan revisarlo. Solo un usuario al mismo tiempo puede realizar este proceso. Así se evita que exista conflictos en caso de que dos usuarios quisieran modificar un contenido a la vez.
Este servicio se denomina ‘CHECKOUT_BY_NAME’ y como parámetro obligatorio se pasa únicamente el dDocName (Identificador único) del contenido en cuestión.
La conexión con Webcenter Content se puede realizar de manera rápida y flexible a través de la API RIDC, lo que permite a los usuarios finales interaccionar con el gestor de contenidos de una manera sencilla y transparente. Los usuarios pueden realizar cualquier acción sin necesidad de estar familiarizados con la herramienta de gestión de contenidos.
¿Te ha resultado interesante?
Solicita más información
