Enlazar datos de KMKey desde aplicaciones externas

Es frecuente la necesidad de enlazar o volcar datos de KMKey desde aplicaciones externas, como puede ser algún programa de gestión externo, una intranet, etc. Una forma de abordar esos casos es escribiendo código python y usando ZODB, pero ese es un camino poco conocido para la mayoría de técnicos, y que requiere un tiempo de aprendizaje elevado. Afortunadamente, hay un camino mucho más sencillo y que conocen la gran mayoría de los técnicos: el uso de SQL.

En primer lugar, necesitamos instalar el conector python-psycopg y el producto ZPsycopgDA, tal y como se explicó en http://kmkey-es.blogspot.com/2009/05/pasar-schemas-sql.html

Una vez hecho esto, vamos al ZMI (http://sitio/manage), a portal_schemas, y localizamos los schemas o schemas de los cuales queremos obtener información y los configuramos para que usen SQL. Por ejemplo, imaginemos que queremos obtener información de documentos de un sistema de calidad, iríamos a portal_schemas/kmkey_document, pestaña "SQL", pondríamos el nombre de nuestra conexión "db" y pulsaríamos el botón "Migrate to SQL". Si después de hacer eso visitamos nuestra base de datos PostgreSQL veremos que ha aparecido una tabla nueva de nombre "kmkey_document" que contiene información de los documentos existentes en KMKey.

A partir de aquí, se trata de atacar esa base de datos SQL desde nuestro entorno preferido (todos ellos dispondrán de un sistema de conexión a PostgreSQL). Siguiendo con el ejemplo, imaginemos que tenemos un expediente de gestión documental de ISO 9001 y que queremos obtener información de todos los documentos del punto 4 de la norma. Ejecutaríamos algo como:

select * from kmkey_document where proxy_path like 'workspaces/kmkey/iso-9001-san-nicolas/4-sistema-de-gestion-de/%';

Observemos que en el campo "file" llega una estructura de valores id#=#title#=#content_type#=#filename Con el filename podremos ir a buscar el físicamente el fichero que se encontrará típicamente en nuestro servidor bajo /var/zope/storages/kmkey/files/A/B/filename siendo A/B las dos primeras letras de filename

Las sentencias pueden ser todo lo elaborados que sea necesario, por ejemplo si queremos mostra únicamente la última versión de cada documento, quedaría algo como:

select * from kmkey_document d where proxy_path like 'workspaces/kmkey/iso-9001-san-nicolas/4-sistema-de-gestion-de/%' and current_revision = (select max(current_revision) from kmkey_document d2 where d.internal_docid = d2.internal_docid);

Como se puede observar, una de las ventajas de usar un sistema de código abierto es que no hay información oculta, y podemos integrarla fácilmente con el resto de entornos de la empresa

Patrones de trabajo avanzados

Anteriormente se documentó la forma de definir XML's básicos de patrones de trabajo. Puede
consultarse dicha entrada en: Comunidad KMKey en Español: XML para definir objetos en patrones

Ahora vamos a centrarnos en introducir funcionalidades más avanzadas, de forma que empecemos a usar todo el potencial de esta herramienta que son los patrones de trabajo.

Bloquear o desbloquear perfiles en una tarea

<task otros_atributos blocked_roles="role1,role2,roleN" />
<task otros_atributos non_blocked_roles="role1,role2,roleN" />

Nos permite bloquear o desbloquear explícitamente ciertos perfiles en una tarea del patrón. Corresponde al apartado de Perfiles Bloqueados de la pantalla de Equipo / Permisos cuando nos encontramos en un expediente ya creado. Los role1, role2, .. etc, corresponden al nombre interno
del perfil, que puede consultarse en el campo Perfil Relacionado de un grupo de permisos.

Asignar perfiles a usuarios o grupos concretos

<access usernames="username1,username2" roles="role1,role2"/>

<access groups="41718292,4343413" roles="role1,role2"/>

La nomenclatura es usernames="user1,user2" roles="role_para_user1,role_para_user2", manteniendo una concordancia de usuarios y perfiles.

La misma sintaxis puede usarse para asignar perfiles a usuarios o grupos dentro de una tarea concreta, usando la jerarquía del XML:

<task atributos_de_la_tarea>

<access usernames="username1,username2" roles="role1,role2"/>

<access groups="41718292,4343413" roles="role1,role2"/>

</task>

Uso de patrones de tareas distintos

El tag default_portal_type permite asociar un portal_type por defecto a un tag XML. El caso más típico es el de los tags task usados para la definición de tareas. Pero podemos desear que ciertas tareas se creen usando otro patrón de tareas, por ejemplo en casos que necesiten disponer de campos específicos en la definición de la tarea. En esos casos, se puede usar el atributo portal_type dentro del propio tag task para definir un patrón de tarea a utilizar distinto del establecido por defecto.

<?xml version="1.0" encoding="iso-8859-1" ?>

<objects xmlns:tal="http://xml.zope.org/namespaces/tal">

<default_portal_type tag="task" portal_type="KMKey Task" />

<task Title="Propuesta de Producto" planned_end="reference_date+120"
planned_start="reference_date+0" portal_type="kmkey_patron_tarea"
responsible="role:director_tecnologico" task_id="51" wbs="1"/>

<task Title="Diseño Preliminar" planned_end="reference_date+221" planned_start="reference_date+80" responsible="role:jefe_diseno" task_id="52" wbs="2"/>

</objects>

Uso de TAL para cambiar el patrón segun valores de los campos de Definición

Otra funcionalidad muy interesante es la de poder hacer uso del sistema de plantillas TAL para generar un XML dinámico de definición del patrón de trabajo. Se puede encontrar más información sobre la sintaxis del Template Attributes Language en la red, pero dejamos aquí un enlace a una guía introductoria: http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx

El uso de TAL nos permite, por ejemplo, condicionar ciertas tareas a determinados valores de campos de la Definición del expediente, o incluso hacer bucles para crear una tarea N veces. Hay que tener claro que las instrucciones TAL se ejecuta en primer lugar, generando un XML resultante que se procesa en segundo lugar, dando lugar a la generación del expediente. Veamos aquí un ejemplo de una tarea condicional:

<?xml version="1.0" encoding="iso-8859-1" ?>

<objects xmlns:tal="http://xml.zope.org/namespaces/tal" tal:define="project python:here['getKMProject'](here)">

<default_portal_type tag="task" portal_type="KMKey Task" />

<task task_id="1" Title="Proyecto + Geotécnico + Control de Materiales" responsible="role:tecnico-de-obra-oct" planned_hours="56" planned_start="parent['planned_start']-15"planned_end="parent['planned_start']-9" tal:condition="python:'Estabilidad' in project['categories']" />

</objects>

Subir el IVA en KMKey

Como algunos de vosotros sabreis, el gobierno español ha decretado subir los tipos de IVA a partir del próximo mes de julio de 2010, pasando a ser del 18%, 8% y 4% respectivamente. Este cambio quedará lógicamente incorporado en próximas versiones de KMKey, pero como la entrada en vigor es inminente, explicamos aquí los pasos a seguir para incorporar los nuevos tipos de IVA, sea cual sea nuestra versión de KMKey:

1) Entramos en el ZMI (http://url_de_nuestro_kmkey/manage)
2) Vamos al site kmkey, apartado portal_skins/custom
3) Creamos un objeto de tipo "Script (python)", escogiéndolo en el seleccionable de arriba a la derecha
4) Lo podemos llamar, por ejemplo "paga_y_calla", y pulsamos el botón "Add and Edit"
5) Escribimos o copiamos las siguientes linias de codigo:

voc = context.portal_vocabularies.kmkey_tax
voc.clear()
voc.set('18.0', '18 %')
voc.set('16.0', '16 %')
voc.set('8.0', '8 %')
voc.set('7.0', '7 %')
voc.set('4.0', '4 %')
voc.set('0.0', '0 %')
return 'Subida del IVA completada'

6) Pulsamos la pestaña "Test"

Y eso es todo, ya estamos preparados para pagar un 18% de IVA (o no)

Ordenar menús y filtros

Para ordenar la lista de menús tenemos una variable de site

menu_sort_item

entramos a zmi, damos de alta la nueva propiedad en el site (string) y le indicamos el nombre del campo por el cual queremos ordenar (title para alfabético, por defecto ordena por id)

Sistema de backups con xdelta

Un sistema de backups es a un entorno informático como la red anticaídas a un equilibrista, nos puede salvar la vida ante un tropezón. Un buen sistema debe permitir recuperar el estado de los datos lo más cercano posible al momento clave ante cualquier desastre, por improbable que parezca. Además debe permitir recuperar datos a una fecha más o menos lejana, sin mayores dificultades.

Para entornos de alta disponibilidad, y con datos muy críticos, la mejor opción sin duda es la replicación de bases de datos en vivo. Pero lo más habitual es que exista una tolerancia de un día, es decir, disponer siempre del backup de la noche anterior es suficiente. En estos casos, se puede optar por un sistema de backups incrementales, o por uno de backups siempre completos. El primero ahorra espacio, pero el segundo facilita una recuperación más rápida y simplifica los procesos de generación del backup. Existe una tercera vía, que es la de los backups completos y rotativos, más el uso de xdelta para ahorrar espacio, y ésa versión menos habitual es la que vamos a exponer aquí

xdelta es un software libre capaz de generar ficheros de diferencias a partir de dos ficheros binarios. También permite regenerar un fichero binario a partir de una versión antigua + un fichero de diferencias . Además se usará rsync para replicar usando poco ancho de banda. Para los usuarios de Debian, su instalación no puede ser más sencilla:

apt-get install xdelta rsync

Para implementar el sistema de backups, necesitamos un mínimo de 3 máquinas: los servidores de bases de datos, el servidor de backups y el servidor de réplicas remotas. El servidor de base de datos (pueden ser varios) y el de backups deben estar en el mismo datacenter, con una conexión LAN entre ellos. El servidor de réplicas remotas debe encontrarse en otra ubicación con una conexión dedicada SDSL o similar. A partir de aquí los pasos son:

1) En el servidor de backups, rotamos a diario 6 copias de seguridad de la semana, manteniendo una completa en daily.0 pero un diff binario respecto a la semanal en el resto.

rm -r daily.5
mv dailiy.4 daily.5
mv dailiy.3 daily.4
mv daily.2. daily.3
mv daily.1 daily.2
mv daily.0 dailiy.1
xdelta delta weekly.0/fichero daily.1/fichero daily.1/fichero.diff
rm daily.1/fichero
mkdir daily.0

2) En el servidor de base de datos, generamos a diario la copia completa en el disco local , y la replicamos sobre un servidor de backups (sobre daily.0)

3) Semanalmente, el servidor de backups convierte una copia diaria en una semanal:

cp -a daily.0 weekly.0

4) También semanalmente, el servidor de réplicas rota y copia las semanales mediante un rsync (cosa que sólo transfiere las diferencias de datos respecto a la semana anterior, en lugar de hacer una copia completa por línea):

rm -r weekly.4
mv weekly.3 weeky.4
mv weekly.2 weekly.3
mv weekly.1 weekly.2
cp -a weekly.0 weekly.1
rsync -av --timeout=180 -e "ssh -p 22" usuario@servidor_backups:/path/a/weekly.0 /path/a/weekly.0

Con este sistema podemos recuperar cualquier copia completa de la última semana, y copias semanales de todo el mes anterior. Si se considera necesario guardar más antiguedad, sólo hay que añadir una rotación mensual en el servidor de réplicas. Si hay problemas en el servidor de datos, podemos recuperar la copia nocturna del día anterior del servidor de backups, y si explotara el datacenter entero, tendríamos los datos recuperables con una máximo de una semana de antiguedad en el servidor de réplicas. Garantías más que suficientes para el 95% de los negocios. Y tus datos, ¿ están así de seguros ?

Widgets para mapas en KMKey

Hemos añadido a KMKey uns nuevo widget muy interesante. Hace uso de openlayers y openstreetmap para localizar ubicaciones a partir de campos de los expedientes, y mostrar completos mapas interactivos de las mismas, al más puro estijo google maps, pero asociados a nuestros expedientes de KMKey. No contentos con ello, el widget permite además añadir datos al mapa, como linias o polígonos que representen una parcela, una obra o un edificio. Estos datos son guardados como una capa propia, y se superponen a los provenientes de openstreetmap.

Para usar este widget es suficiente con ir al ZMI portal_layouts/nuestro_patron y añadir un widget del tipo "KMKey map widget". Debemos asociar 3 campos que previamente deben haberse creado en el portal_schemas/nuestro_patron. Por este orden, son longitud (float), latitud (float) y zoom (int). También nos da la posibilidad de configurar los ID's de los campos de calle, población y país a partir de los cuales llevar a cabo la localización de ubicaciones. Finalmente, nos pide laURL del servidor featureserver que se encarga de guardar los datos de la capa de modificaciones. Lo mejor para este servidor featureserver es instalarlo como CGI bajo el mismo dominio que estemos usando (las instrucciones de instalación de este software estan bien detalladas en featureserver.org)

Bueno, ¿ quien dijo que con software libre no se pueden tener soluciones profesionales ?

Soporte para IMAP y servidores con SSL

Hasta la fecha el sistema de recepción de mensajes a KMKey para su inclusión automática sólo era posible mediante una cuenta de correo accesible vía el protocolo POP3 sin cifrado SSL. Ahora se han implementado tanto el acceso a un buzón mediante el protocolo IMAP así como el uso de SSL en ambos protocolos para acceder a los mismos. En esta entrada se explicarán los pasos a seguir para configurar un site KMKey ya en funcionamiento para hacer uso de las nuevas funcionalidades.

En primer lugar, para usar un buzón IMAP habrá que sustituir el fichero KMKeyCore/utils/email_scan.py por el nuevo email_imap_scan.py. Los parámetros de configuración pop3_server, pop3_user y pop3_password, pese a su nombre, serán utilizados para el acceso vía IMAP al buzón. Estos parámetros son modificables desde la pestaña “Properties” del site en el Zope Management Interface (ZMI). Si dichas propiedades no existieran por no haberse configurado aún ningún servicio de correo, se pueden crear siguiendo estas instrucciones.

Una de las características del protocolo IMAP es que permite mútiples buzones para una misma cuenta. Eso hay que tenerlo en cuenta en el caso que los correos destinados al KMKey no lleguen a un buzón llamado INBOX. Lo usual es que sea así, pero si no fuera el caso basta con editar el script Python, buscar la declaración imap_folder = 'INBOX' y cambiarla por el valor adecuado.

Finalmente, para habilitar el acceso vía SSL al buzón, sea por el protocolo IMAP o el POP3, sólo hay que añadir una propiedad llamada pop3_ssl de tipo booleano en las propiedades del site vía ZMI. Aparecerá entonces una casilla seleccionable que, de estar marcada, hará que el script de captura de correo use el acceso cifrado al buzón.