miércoles, 18 de enero de 2017

Cómo hacer un buen RFP de Gestión Documental


Muchas compañías se enfrentan a tener que hacer un RFP de Gestión Documental. Algunas tienen plantillas de RFPs (Request For Proposal) que reutilizan, otras empiezan de cero.

De una u otra forma, sacar un RFP implica mucho trabajo:

  • Previo a la elaboración del RFP
  • En la elaboración del RFP
  • Durante la selección del adjudicatario

Ya que los equipos técnicos o de negocio tienen que enfrentarse a tanto trabajo, como mínimo habría que esperar que dicho trabajo diera su fruto: Escoger la herramienta que mejor satisfaga las necesidades que nos llevan a querer afrontar un RFP de Gestión Documental.

Sin embargo, la realidad es que muchas empresas fracasan tratando de encontrar ese proveedor que les brinde el mayor beneficio posible dentro de una inversión asumible. ¿Por qué? Bajo mi punto de vista, porque no consiguen transmitir a los proveedores las verdaderas necesidades del negocio.

Muchas empresas fracasan tratando de encontrar ese proveedor que les brinde el mayor beneficio posible dentro de una inversión asumible. ¿Por qué? Bajo mi punto de vista, porque no consiguen transmitir a los proveedores las verdaderas necesidades del negocio.

Investigando sobre este tema, me he encontrado con artículos interesantes, por ejemplo, el de Carrie Hane, que habla de 5 razones que hacen que los RFPs den pena:


  1. No se enfocan en el problema(s) que hay que resolver
  2. Es una lista de requerimientos
  3. Se publica sin haber investigado antes
  4. Piden cosas que no se pueden comprar con el presupuesto disponible
  5. Piden cosas ideas innovadoras, valores añadidos, etc.


Leyendo esta lista, tuve la sensación de que Hane se dedica a las ventas y ha tenido que responder a unos cuantos RFPs. Para mí, especialmente las 3 primeras son las que determinan el fracaso de un concurso.

Ya que quiero escribir este artículo en positivo, voy a describir de acuerdo con mi experiencia, las 3 cosas que debe hacer cualquier equipo de trabajo que hacer un buen RFP de Gestión Documental, en lugar de deciros que no hacer.


1. Averigua y pon por escrito por qué necesitas un gestor documental

Uno no compra –o no debería- comprar/alquilar un gestor documental porque toda empresa necesita tener una gestión documental y punto.

Un proyecto basado en un criterio como ese está destinado a ser relegado cada que salga una necesidad más imperiosa en la empresa.

Se adquiere un software de gestión documental porque se tiene una necesidad concreta:


  • Legal, auditorias, calidad. (compliance)
  • Un proceso en el que se pierde dinero o donde hay margen claro de optimización y ahorro de costes.
  • Tenemos ya un gestor documental que en cualquier momento colapsa.
  • La seguridad de la información está en riesgo.


Esa necesidad tiene que estar bien definida y justificada. Pero no ya sólo de cara a la defensa interna del proyecto, sino porque si esto no está claro y no conseguimos transmitirlo a aquellos a los que invitemos a participar en el RFP, estos proveedores no van a poder ayudarnos a resolver nuestro problema.

Si la necesidad que nos lleva a elaborar el RFP no está clara y no conseguimos transmitirla a aquellos a los que invitemos a participar en el RFP, estos proveedores no van a poder ayudarnos a resolver nuestro problema.

La mayoría de equipos se centran en la búsqueda de funcionalidad concreta, mi recomendación, centraros en ver cómo una herramienta puede resolver vuestro problema.


2. Conviértete en un Comprador Informado

Hay decisiones que se pueden tomar de acuerdo con sensaciones: compro una Coca-Cola porque tengo sed y ganas de Coca-Cola. Una Coca-Cola, como mucho nos va a costar 3 euros (en un aeropuerto), así que el no detenernos a pensar si comprar una Coca-Cola es o no una buena decisión es un riesgo asumible.

Sin embargo, cuando sacamos un RFP de Gestión Documental, normalmente estamos hablando de presupuestos superiores a 50.000 euros. 17.000 Coca-colas. Merece la pena, antes de sacar un RFP, enterarnos de qué queremos comprar y qué hay en el mercado.

Algunas cosas que se pueden hacer:


  • Buscar comparativas de productos
  • Mirar pricing públicos
  • Pedir presupuestos
  • Leer artículos de expertos en Gestión Documental
  • Preguntar a empresas de nuestro sector u otro que ya hayan pasado por un proceso de selección de gestión documental.
  • Probar demos de productos o pedir demostraciones.


La idea es que antes de sacar el RFP sepamos:


  • En qué rango de precio nos movemos
  • A quienes queremos invitar o qué productos nos gustan o encajan.


3. En lugar de lista de requisitos, haz una lista de casos de uso

Un 80% de las funcionalidades que se piden en un RFP no son críticas para los usuarios.
Un 80% de las funcionalidades que se piden en un RFP no son críticas para los usuarios. Además, tienen el problema de que la funcionalidad se define en una línea y cada cual interpreta dicha línea como buenamente puede o quiere. Esto pasa especialmente cuando la lista de requisitos viene en un Excel. En este caso, ni siquiera nosotros como proveedores, tenemos el espacio suficiente para explicar nuestra interpretación de dicha funcionalidad, así que ni cliente ni proveedor pueden tener la certeza de haber llegado a entenderse.

Mi recomendación es explicar casos concretos de uso: “Necesitamos recopilar documentación e información de Prevención de Blanqueo de Capitales de nuestros posibles compradores. Necesitamos saber en cada momento, qué nos falta recibir para que la documentación esté completa. Recibimos los documentos por correo electrónico”.

Este es un caso de uso –muy resumido, por supuesto- pero que va a dar una idea clara al proveedor de cuál es la necesidad. Es su trabajo explicarte cómo su herramienta puede ayudarte a solucionar ese reto tecnológico que tienes.


4. Pídele al proveedor que te ayude a ver cómo otros clientes suyos han solucionado problemas como el tuyo

Creo que uno de los retos más importantes al que se enfrentan las personas que realizan un RFP, es que no tienen claro cómo pueden solucionar con una herramienta problemas concretos que tienen.

Uno de los retos más importantes al que se enfrentan las personas que realizan un RFP, es que no tienen claro cómo pueden solucionar con una herramienta problemas concretos que tienen.

No saben qué puede hacer la herramienta o si lo que están planteando es factible.

Ante estos casos, lo mejor que se puede hacer, es explicarle al proveedor el problema y preguntarle: ¿Tienes un cliente al que le hayáis ayudado a resolver un problema como el nuestro?

Las referencias normalmente se piden para evaluar la seriedad y fiabilidad del proveedor. Yo os invito a pedir referencias para comprender cómo una herramienta puede solucionar un problema concreto.

Espero que este artículo os haya resultado de interés y fácil lectura.

Hasta la próxima. 









Instalación automática de tu proyecto personalizado desde Athento Rhombus



Rhombus es la interfaz gráfica desde la cual es posible personalizar Athento ECM: Añadir tipos documentales, flujos de trabajo, añadir metadatos, construir listas de valores predefinidos para metadatos, modificar la apariencia del gestor documental, definir traducciones, etc.

Hasta la pasada versión, Rhombus era capaz de generar un fichero ZIP con las personalizaciones de Athento ECM que los usuarios podían subir de forma manual a la plataforma para su instalación.

En esta nueva versión, Rhombus incorpora conexión directa con el gestor documental. Sólo hace falta definir la URL de Athento y credenciales de acceso con permisos de Administración. Con esta nueva funcionalidad, desde el botón “Instalar”, los usuarios pueden desplegar la nueva funcionalidad en el gestor documental, que además, se instala con su propia versión de plugin.

En el siguiente vídeo se puede ver en acción la nueva funcionalidad del producto: http://recordit.co/aAJYEj9foz

Esta funcionalidad nos permite además, como se ve en el vídeo testear de forma rápida la nueva funcionalidad añadida a la plataforma.


lunes, 9 de enero de 2017

Escalabilidad de Athento

"Se entiende por escalabilidad a la capacidad de adaptación y respuesta de un sistema con respecto al rendimiento del mismo a medida que aumentan de forma significativa el número de usuarios del mismo. Aunque parezca un concepto claro, la escalabilidad de un sistema es un aspecto complejo e importante del diseño."
Esta es la definición de escalabilidad que ofrece la Junta de Andalucía. Si bien, en materia de gestión documental y escalabilidad, no se puede considerar únicamente el número de usuarios, sino que además, han de considerarse otros aspectos que también pueden afectar la capacidad de respuesta del gestor documental, como por ejemplo, el número de documentos o la cantidad de peticiones que hacen vía API.
En el caso de Athento, el escalamiento de la herramienta se puede llevar a cabo en dos sentidos, como veremos a continuación.
  • Horizontalmente: Se consigue incrementando los recursos con los que trabajan las instancias de Athento, es decir, se crece aumentando nodos de Athento, MongoDB o Elastic como se muestra en la parte inferior de la siguiente imagen.
Queue Management.png
  • Verticalmente: En este caso, se añaden instancias o nodos de Athento. Es decir, se clusteriza el sistema. Estos nodos trabajan con balanceadores de carga que permiten distribuir el trabajo entre los distintos nodos. El clúster se puede ampliar según se requiera.
Screen Shot 2016-11-30 at 21.16.24.png

En el caso de Athento cloud, las ampliaciones del clúster se pueden considerar el uso de varios datacenters, de modo que si las peticiones van a llegar desde distintas zonas geográficas, se pueda distribuir el trabajo de acuerdo con la proveniencia de dichas zonas geográficas. Los nodos se distribuirán en el entorno cloud de manera que cubran de forma óptima las comunicaciones. En otras palabras, el balanceo de carga se puede derivar a los distintos nodos de cada data center según la región.

martes, 3 de enero de 2017

La nueva normativa de firma electrónica en Europa



El eIDAS que se hizo efectivo el pasado julio, tiene como objeto regular la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado de la Unión Europea

La idea es potenciar la transformación digital, eliminado la desconfianza de los ciudadanos en la realización de transacciones comerciales por medios electrónicos.

La desconfianza, en particular debida a la inseguridad jurídica percibida, hace que los consumidores, las empresas y las administraciones públicas duden a la hora de realizar transacciones por vía electrónica y adoptar nuevos servicios.

Este reglamento va a reemplazar las leyes de 28 naciones en materia de firmas electrónicas.

Industrias como la banca, las aseguradoras, las empresas de telecomunicaciones y otras que prestan servicios intracomunitarios se van a ver muy beneficiadas con esta normativa. El reglamento va a echar abajo barreras de identificación electrónica, firma digital, aceptación de usuarios, etc., que habían sido detectadas en el pasado y que ocasionaban que los procesos electrónicos no pudieran ser 100% paperless o que las empresas tuvieran cierto recelo en este sentido.

Procesos como los de Customer Onboarding, en los que los clientes tienen que aceptar y firmar contratos para acceder a un producto o a la prestación de un servicio, se van a beneficiar de la desaparición de barreras a la firma y aceptación electrónica por parte de los consumidores. Al eliminar la logística asociada al papel (transporte, digitalización, archivo, procesamiento), van a ver también sus tiempos y costes reducidos.

Athento en este sentido cuenta con el caso de éxito de Barclaycard, que redujo su proceso de customer onboarding para la venta de tarjetas de crédito de 14 a 4 días. En este caso, la firma de documentos se realiza desde tablets y los documentos no se generan en papel durante el proceso.

El gestor documental, cuenta con diversas posibilidades a la hora de firmar documentos, su plugin de firma básica es una buena forma de empezar para cualquier empresa.

Registro de Entrada con Athento

miércoles, 14 de diciembre de 2016

¿Tener tus documentos y datos en Canadá?


En Athento, por norma general, recomendamos a nuestros clientes tener sus datos almacenados en la Unión Europea. Para nuestros clientes en Europa, la ley prácticamente nos obliga a ello, y nosotros estamos convencidos de que tener los datos en el territorio europeo y protegidos para leyes bastante restrictivas en materia de protección de datos es un valor más para nuestros clientes.

Sin embargo, muchos de nuestros posibles clientes en América Latina se cuestionan sobre si tener los datos tan lejos de sus instalaciones les va o no a generar problemas. Una de las mayores preocupaciones es por supuesto la latencia. En este sentido, nosotros no tenemos preocupación alguna, pues las tasas de latencia desde países como Brasil, Perú, Chile o Argentina son perfectamente adecuadas. Sin embargo, para aquellos clientes que insisten en tener sus datos cerca, ofrecemos trabajar con nuestro data center canadiense.

Ahora bien, la siguiente preocupación de nuestros clientes es por supuesto la seguridad de sus datos. Por ello, vamos hoy a introducir un poco la normativa y medidas de protección de datos en este país de Norte América.

Al escoger nuestro data center en Montreal, el cliente tiene la garantía de que Canadá cuenta con un marco normativo que vela por la protección de su información.

A continuación, se amplía la información sobre la normativa canadiense en materia de protección de datos. Canadá ostenta una de las regulaciones más potentes en materia de privacidad de datos en el mundo. Su sistema de protección de datos es lo suficientemente seguro como para que en diciembre de 2001 la Comisión Europea reconociese la adecuada protección de datos que ofrece el Canadian Personal Information Protection and Electronic Documents Act (PIPED Act) y autorizara la transferencia de datos entre Europa y Canadá. La decisión fue confirmada en 2006.

Canadá cuenta con dos leyes nacionales en relación a la privacidad y protección de datos:
  • Privacy Act: Esta ley limita la recolección, uso y publicación de datos personales por parte de los organismos del gobierno.
  • PIPED Act: Esta ley regula como el sector privado debe recolectar, usar y publicar datos de los usuarios.
En América Latina, Argentina, Perú, Uruguay y Colombia siguen el enfoque europeo en relación con las transferencias internacionales. Por lo general, sólo permiten la transferencia de datos desde sus territorios a países que ofrecen niveles adecuados de protección de datos personales, como los países de la Unión Europea. En el caso de la legislación colombiana, los legisladores de este país han tenido en cuenta las leyes canadienses en su regulación.

Puede consultar más sobre nuestra Política de Seguridad y Medidas de Seguridad.

Prueba Gratis Athento

lunes, 12 de diciembre de 2016

Cómo las integraciones vía API ayudan a las empresas a trabajar más rápido y mejor



De acuerdo con 2015 Enterprise Mobile App Trend Report de Apperian, de media, en las empresas los empleados usan cerca de 35 aplicaciones internas distintas. Aunque estas aplicaciones ayudan a los trabajadores a desempeñar mejor sus funciones, a la larga, también terminan generando efectos colaterales: 

  • Información duplicada
  • Información aislada en aplicaciones
  • Pérdida de trazabilidad de la información 
  • Costes asociados a mantener varios repositorios 

Las empresas pueden solucionar estos problemas mediante el uso de una interfaz de programación de aplicaciones (API) para conectar aplicaciones, compartir información y crear un ecosistema digital interconectado que permite una mejor gestión del conocimiento y operaciones más eficientes. 
Hoy en día, la mayoría de aplicaciones comerciales disponen de una API. Algunas más completas que otras, pero estas APIs permiten ejecutar desde otras aplicaciones tareas o funcionalidades frecuentes.

El sistema de gestión documental es también clave en esta tarea de crear un ecosistema digital interconectado, ya que posibilita que las aplicaciones de negocio deleguen en él el almacenamiento y gestión de los documentos con los que trabajan. 

Ventajas de centralizar los documentos en el gestor documental

Centralizar los documentos en el gestor documental y no en las aplicaciones de negocio nos permite tener un esquema más claro de integración, ya que en cuanto a documentos se trata, todas las aplicaciones han de dirigirse al gestor documental, ya sea para almacenar o para consultar. 

Los cambios que ocurren en los documentos en cada aplicación son recogidos en forma de metadatos, de manera que desde todas las aplicaciones se mantiene la misma información actualizada. 
Esto es lo que hemos comentado en otras ocasiones como Hub de Información

Otra buena práctica es desarrollar una capa intermedia de comunicación que permita unificar todas las integraciones y realizar cambios en un mismo lenguaje y bajo una misma lógica. Cada equipo técnico debe realizar un análisis del diseño de integración más adecuado, antes de acometer un proyecto de integración. 

En nuestro caso, todos los módulos de Athento (Athento ECM y Athento SE) disponen de una API REST que permite realizar casi cualquier tipo de tarea de gestión documental.




Prueba Gratis Athento

miércoles, 30 de noviembre de 2016

Integración de ManifoldCF y Nuxeo: federación de contenidos en distintos repositorios


Apache ManifoldCF es un proyecto Top-Level de Apache Software Foundation cuyo objetivo principal es proporcionar un framework Open Source que permita conectar distintos repositorios de contenidos como pueden ser Alfresco, Microsoft Sharepoint o Confluence con otros repositorios de salida, fundamentalmente motores de indexación como Apache Solr o ElasticSearch. En términos más sencillos, ManifoldCF nos permite conectar distintos repositorios entre sí.

Apache ManifoldCF puede concebirse, por tanto, como un crawler de repositorios. Los distintos conectores que ofrece el proyecto, tienen la capacidad de explorar todo el espacio de documentos de un determinado sistema siguiendo una estrategia de Incremental Crawling: de forma periódica y totalmente configurable, ManifoldCF ejecuta tareas de indexación que se encargan de recorrer los repositorios para comprobar si existen nuevos documentos a indexar o bien algunos de los ya indexados han sido modificados y necesitan ser indexados de nuevo.

Apache ManifoldCF también cuenta con un modelo de seguridad para los repositorios de salida que permite respetar las políticas de permisos de los repositorios de entrada o fuentes de información originales. Por cada conector de entrada que soporte nativamente algún tipo de modelo de permisos de acceso a los contenidos, ManifoldCF implementa un Conector de Autoridad que se encarga de extraer todos los permisos definidos para cada contenido y de indexarlos junto al mismo en los repositorios de salida. El objetivo de este proceso es mantener securizados los contenidos de todas las fuentes independientemente de que se federen en un mismo motor de búsqueda. En este sentido, ManifoldCF ofrece plugins tanto para ElasticSearch como para Apache Solr que solucionan para el integrador final la búsqueda securizada al filtrar automáticamente los resultados de búsqueda que un determinado usuario no puede obtener por no disponer de permisos suficientes.

A modo de ejemplo, algunos de los conectores de entrada incorporados actualmente en ManifoldCF son:
  • Alfresco.
  • Amazon S3.
  • CMIS.
  • Confluence y Jira.
  • DropBox.
  • Google Drive.
  • JDBC (Bases de datos).
  • Sharepoint.

Configuración de Conectores de Entrada
Configuración de Conectores de Salida

Búsqueda Federada

El principal caso de uso soportado por Apache ManifoldCF es la Búsqueda Federada dentro de una organización o empresa. Las empresas cuentan normalmente con información en diferentes repositorios de información distribuidos y no centralizados, por ejemplo, en un CMS, en uno o varios ECM, una base de datos, etc. Esta situación provoca que los usuarios finales tengan que conocer exactamente en qué sistema deben tratar de encontrar el recurso que están buscando. Es decir, las empresas aunque no lo quieran, terminan obteniendo silos de información que a la larga les impiden obtener verdadero conocimiento de sus datos y que les entorpece a la hora del trabajo diario.

¿Qué pasaría si pudiéramos acudir a un sólo lugar para buscar absolutamente toda la información de la empresa? Pasaría que seríamos empresas más rápidas y más efectivas :) Bien, pues esto es precisamente lo que nos permite ManifoldCF. Desde el punto de vista técnico, se trataría simplemente de configurar los conectores de entrada de los distintos repositorios de nuestra organización y un conector de salida como, por ejemplo, ElasticSearch. Una vez completada esta configuración, se definen las tareas periódicas de indexación. Al finalizar la primera ejecución de estas tareas (denominadas 'jobs' en ManifoldCF), nuestros contenidos distribuidos estarían indexados de forma federada en un mismo índice dentro de ElasticSearch y ya podríamos realizar búsquedas de forma global sobre todas nuestras fuentes de información. En este sentido, es importante recalcar que ManifoldCF indexa igualmente información de la fuente original de forma que los resultados de búsqueda puedan incorporar un enlace al contenido en su fuente original (por ejemplo, un enlace a un documento en DropBox).

Configuración de Tareas de Indexación

Migraciones de Contenido

Otro interesante caso de uso con ManifoldCF es la migración de contenidos. Nuestra experiencia como empresa dentro del mundo ECM nos dice que los procesos de migración entre repositorios son tan asiduos como costosos. Extraer ingentes cantidades de información de sistemas en uso desde hace años y replicarlas en otros sistemas usando los mismos modelos documentales y de permisos, es una tarea bastante tediosa y con tendencias a sufrir fugas de información. Actualmente, los conectores de salida de ManifoldCF están orientados a sistemas de indexación, pero su diseño es totalmente genérico para poder desarrollar conectores de salida también para repositorios, como los de entrada. Por ejemplo, podríamos implementar un conector de salida para Nuxeo usando su API REST de forma que los documentos de cualquier otro repositorio de entrada junto con sus metadatos y permisos pudieran ser almacenados en Nuxeo. De esta forma, podemos migrar contenidos de un repositorio a otro de forma automática.

Nuevo Conector de Nuxeo

Al igual que cualquier otro proyecto de Apache, ManifoldCF es desarrollado por una comunidad Open Source descentralizada que contribuye activamente en el mantenimiento y mejora del proyecto. Athento cuenta con miembros dentro de esta comunidad. Como integradores de Apache ManifoldCF, cuando necesitamos extenderlo o mejorarlo de alguna forma, contribuimos el resultado de vuelta al proyecto.

Igualmente, los proyectos de Apache están completamente abiertos a contribuciones 'externas' de cualquier tipo que permitan mejorar los proyectos. Y éste ha sido el caso del nuevo conector de Nuxeo que ha sido desarrollado por David Arroyo Escobar, estudiante de la Universidad de Sevilla, a través del programa Google Summer of Code de Google. El conector de Nuxeo es compatible con las versiones de Nuxeo LTS-2015 en adelante.

El conector de Nuxeo estará disponible en la próxima release de Apache ManifoldCF (2.6), planificada para finales de 2016. En estos momentos, nos encontramos finalizando los pasos necesarios para incorporarlo oficialmente como parte del código de ManifoldCF y que esté, de esta forma, disponible para todos los usuarios e integradores de Apache ManifoldCF.

Happy Crawling! :-)


Registro de Entrada con Athento

miércoles, 23 de noviembre de 2016

Mecanismos de Integración con Athento



Hemos visto en otras entradas cómo el ECM se puede usar como hub de información de la organización para centralizar en un único punto la documentación corporativa. Eso pasa por supuesto, por integrar las aplicaciones de negocio contra el gestor documental para que sean capaces de introducir y consultar información desde él entre otras operaciones. En esta entrada, veremos los dos principales Mecanismos de Integración con Athento.

Athento.js

Athento.js es un Javascript embebido en aplicaciones externas que permite exponer diversas funcionalidades del gestor documental:

  • Formularios de creación de documentos
  • Previsualización de documentos
  • Listado de documentos
  • Búsqueda de documentos, etc.
El uso de los embebibles de Athento facilita las labores de integración y, además, tiene la ventaja de que cualquier cambio realizado en Athento será visible en todas las aplicaciones integradas sin tener que hacer ninguna modificación.

API REST

El repositorio proporciona una REST API completa accesible a través de HTTP / HTTPS. Esta API es la mejor manera de integrar de forma remota con el repositorio: portales, motores de flujo de trabajo, ESB, aplicaciones desarrolladas en JavaScript, Ruby, etc. La API REST está disponible en servidores Nuxeo en la siguiente URL: http: // localhost: 8080 / Nuxeo / api / v1 / *


En la siguiente URL encontrará ejemplos de llamadas a servicios web básicos de la plataforma:

https://athento.atlassian.net/wiki/pages/viewpage.action?pageId=43548711


El API provee de los siguientes endpoints:

Endpoints de recursos, para hacer CRUD sobre recursos 100% al estilo REST.

  • Variedad de recursos son accesibles:
  • Documentos (/nuxeo/api/v1/id/{docId} o /nuxeo/api/v1/path/{path}): CRUD en documentos (incluida la búsqueda paginada). 
  • Usuarios (/nuxeo/api/v1/user/{userId}): CRUD en usuarios. 
  • Grupos (/nuxeo/api/v1/group/{groupId}): CRUD en grupos de usuarios. 
  • Directorios (/nuxeo/api/v1/directory/{directoryId}): CRUD en directorios. 
  • Tipos documentales, esquemas de metadatos, facetas y definiciones (/nuxeo/api/v1/config/types|schemas|facets/{type|schema|facet}): Esto es útil cuando se están haciendo inmersiones remotas de la estructura del repositorio, etc.


Queries 

Accesibles desde (nuxeo/site/api/v1/query?query={query} o /nuxeo/site/api/v1/query/{page_provider_name}?queryParams={params_values}

Endpoint de comandos

Se utilizan para llamar un comando, por ejemplo, en una operación o cadena de operaciones desplegadas en el servidor. Esta es la principal forma de acceder a los servicios de la plataforma de forma remota. Más de 100 comandos están accesibles de esta manera para el procesamiento remoto de recursos. El framework de desarrollo hace muy fácil el añadir una operación personalizada para completar el API.

Endpoint de carga masiva

(/nuxeo/api/v1/automation/batch/upload}), permite subir conjuntos de ficheros antes de usarlos en una operación transaccional, como por ejemplo, actualizar el contenido de una lista de documentos, etc.

  • La API REST de Nuxeo ofrece funcionalidad adicional comparada con una API REST estándar:
  • Permite secuenciar la ejecución de un comando sobre un recurso. 
  • Contribuciones REST que permiten pedir más información cuando se reciben los recursos a través de algunos headers, con el objetivo de reducir el número de request a efectuar. 
  • Adaptadores web que “transforman” los recursos devueltos, por ejemplo, obtener las tareas de un documento o sus documentos relacionados.


Más información sobre la API REST de Nuxeo desde aquí:

Puedes consultar ejemplos sencillos de la API aquí

SDKs Disponibles

Para facilitar el uso de la API en la integración con Nuxeo, este provee varios SDK:
  • Java client 
  • JavaScript client 
  • iOS client 
  • Android client 
  • PHP client (implementación parcial) 
  • DART client

Puente SOAP

La plataforma incluye una implementación de JAX-WS para acceder a servicios SOAP. Concretamente, se usa Sun JAX-WS (Metro). Por defecto, los servicios SOAP incluyen:

  • Acceso de lectura al repositorio y a la gestión de usuarios. 
  • Acceso de lectura al módulo de Audit 
  • Bindings de CMIS
De cualquier manera, es fácil construir nuevos servicios SOAP sobre Nuxeo, ya que:


  • Ya tiene la infraestructura JAX-WS
  • Ya cuenta con el sistema de autenticación 
  • Provee la clase base para manejar repositorio y seguridad. 
  • Provee objetos JAXB para documentos, descriptores de seguridad, propiedades, etc.


Prueba Gratis Athento

AddThis