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

lunes, 21 de noviembre de 2016

Autenticación en Athento ECM


La autenticación contra el gestor documental ha sido diseñada de modo desacoplable. Por defecto, el método de autenticación usado para hacer peticiones a la API es el de BasicAuthentication.  Sin embargo, el gestor documental permite el uso de distintos mecanismos de autenticación entre los que están:
  • oAuth.
  • SAML (addon).
  • 2 Steps -dos pasos- (con SMS por ejemplo) (Addon).
  • Trusted (por ejemplo, para hacer cosas como que las peticiones de una IP en particular no tenga que autenticarse).
  • Open ID (addon).
  • Kerberos.
  • CAS.
  • NTLM.
  • Redirección a un sistema remoto de gestión de identidades -IdM-(SSO servers, Open Id, portales, ...).
Algunos de los sistemas de gestión de identidad -IdM- soportados son:
  • Active Directory server.
  • Open ID (compatible con Google, Twitter, Facebook, GitHub, ect.).
  • IdM SAML compatibles, on premise o SAAS, como LastPass, One Login, ClearTrust, ...
  • IdM Kerberos compatibles.
  • Shibboleth Servers (Gestión Federada de Identidad).
  • SSO Servers (ejemplo: CAS Server, Site Minder).
También es posible definir accesos “no autenticados” de dos tipos:
  • Usuario anónimo: permite que un usuario inicie sesión automáticamente como un usuario llamado "anónimo", para el cual se han establecido algunos permisos específicos. El nombre de ese usuario es configurable y permite simular un acceso "sin autenticar" a la plataforma.
  • URLs no autenticadas: permite definir una lista de patrones de URL para las que no se requiere la autenticación. De esa manera es posible hacer, por ejemplo, que una página web específica publique documentos que se encuentran dentro de la plataforma sin necesidad de autenticación, mientras que otras otras páginas servidas por la plataforma envían al usuario a la página de inicio de sesión.

Ejemplo de autenticación con BasicAuthentication


A continuación, vamos a ver un ejemplo de autenticación con BasicAuthentication para llamadas a servicios web.
Para autenticar los servicios descritos a continuación es necesario establecer el usuario y contraseña que serán incluidas mediante BasicAuthentication en las cabeceras de la petición.
Ejemplo en el cliente POSTMAN para Chrome:
Además, para poder realizar correctamente todas las peticiones a servicios, es necesario introducir la siguiente cabecera:
Content-Type: application/json+nxrequest
Ejemplo en el cliente POSTMAN para Chrome:
Ejemplo de petición autenticada con la cabecera:
En el artículo sobre el Addon de Seguridad de Athento ECM os contamos las funcionalidades que este addon añade a la gestión de usuarios y al componente de autorización.

Caso de Uso: Clasificación Automática de Documentos Legales

miércoles, 16 de noviembre de 2016

Uso de bases de datos NoSQL orientada a documentos con Athento ECM


Aunque el uso de bases de datos relacionales como Postgre combinada con el uso de Elastic Search ha demostrado robustez y grandes prestaciones en cuanto a escalabilidad y manejo de volúmenes importantes de datos, cada vez más compañías se preocupan por el crecimiento de sus documentos y metadatos y cómo esto les puede afectar en materia de rendimiento. Por ello, la compatibilidad con sistemas noSQL es un tema que capta el interés de muchos CTOs y CIOs.

Las bases de datos NoSQL son sistemas de almacenamiento de datos que se caracterizan por ofrecer prestaciones de rendimiento altas para el manejo de volúmenes masivos de información. Son un concepto diferente a las bases de datos relacionales porque, por ejemplo, cada documento puede ser almacenado sin seguir un esquema fijo de datos. Algunas veces puede contener unos datos y otras veces otros, o pueden incluso contener toda la información relativa a un documento en un mismo registro en lugar de tener la información en distintas tablas como suele pasar en SQL. Esto va a evitar que tengamos que hacer JOINs que son supremamente costosos en materia de rendimiento. Estas bases de datos noSQL son clusterizables, por lo que podemos seguir añadiendo nodos a medida que vayan creciendo los volúmenes de datos. Estos nodos pueden ser consultados al mismo tiempo.

Características como las anteriores lo que permiten al final es que la velocidad de respuesta cada vez que le preguntemos algo al Sistema sea aceptable para los usuarios y aplicaciones que se conectan a él.

Athento ECM, gracias al DBS de Nuxeo (Document-Based Storage) permite el almacenamiento de documentos en un almacenamiento orientado a documentos, como NoSQL.

Su primer implementación está disponible para MongoDB. La plataforma soporta las siguientes versiones de MongoDB:
  • 2.8 
  • 3.0 
  • 3.2 (A partir de la 8.2)
La plataforma ofrece soporte nativo para MongoDB desde el 2014. Esta integración permite indexación full-text, queries enriquecidas, replicación, alta disponibilidad, etc. La integración con MongoDB ofrece herramientas para el procesamiento de grandes volúmenes de datos almacenados en el repositorio.

Prueba ahora 30 días gratis de Athento y accede a Athento ECM (Gestión Documental) y a Athento SE (Captura de Documentos). 

Prueba 30 días gratis Athento

AddThis