Hooks

Buenas, estamos trabajando en la integración de Guaraní 3 con el campus virtual y el actual sistema de facturación. La cuestión es que nuestro modelo es un poco más complejo que lo planteado en los web services de G3, con la exposición de comisiones y cursos virtuales. Nosotros necesitamos poder impactar en nuestros sistemas ante diferentes eventos. Tales como la aceptación de una inscripción, el rechazo de la misma, la aplicación de una licencia, entre otros. Nuestra inquietud o duda llega en el cómo implementar dicha solución. Evaluamos consultar estas tablas regularmente, pero lo vimos desprolijo y poco confiable, más que nada porque muchas de las tablas no mantienen un registro histórico con fechas, y usar el esquema de auditoria nos parecía más desprolijo aún. Por otro lado, evaluamos la posibilidad de insertar hooks mediante código, extendiendo las clases pertinentes para agregar nuestras llamadas. Tampoco nos pareció de lo más prolijo, ya que implica un riesgo alto de conflicto si el código original cambiase. Como último recurso se nos ocurrió agregar triggers propios a las tablas involucradas de modo de capturar estos eventos en nuestras propias tablas. Nos gustaría saber su opinión con respecto a este asunto, desde ya muchas gracias y saludos!

Hola Pablo, nosotros tuvimos un problema similar, y lo solucionamos creando reglas ( http://documentacion.siu.edu.ar/wiki/SIU-Guarani/Version3.11.0/personalizaciones/requisito_proceso).

Con estas reglas generamos requisitos (Requisitos->Administrar Requisitos), y a dichos requisitos los configuramos para diferentes puntos de control. Hay que fijarse en el código de la operación para ver que punto de control se controla en un momento dado, para configurar los requisitos adecuadamente.

En nuestro caso, por ejemplo, para el control de pagos en inscripción a examen, el requisito simplemente llama a una api de un sistema externo, que le devuelve el resultado si el alumno está habilitado a inscribirse en un examen o no.

Espero haber sido de ayuda.

Saludos.

Hola Agustín. Y estas reglas y requisitos por lo que veo los tuvieron que crear en el core, es decir no van en la carpeta de personalizacion no?
Además nuestro inconveniente es que si, por ejemplo, queremos capturar el momento en que una inscripción se acepta se nos complica porque el control del requisito es previo a la misma.
También por lo que estuvimos viendo en el código, no en todos los eventos del Sistema realizan esta validación de requisitos. Algunos simplemente realizan controles adhoc y ejecutan la acción, no dejando lugar a poder enlazarlo a algún requisito. Gracias por responder, saludos!

A las reglas no nos hizo falta agragarlas al core. Las pusimos dentro de personalizaciones/php/nucleo/_lib/reglas, pero tuvimos que agregar las referencias a las clases en personalizacones/php/guarani_autoload_clases_nuevas.php

La forma menos conflictiva con las actualizaciones que se me ocurre es en donde necesites que se realice un control, podrías personalizar la función y forzar el control, es decir, por ejemplo si supieramos que el momento en que una inscripción se acepta es en la función guardar() de la clase ci_inscripcion.php, y al requisito lo pegamos en el punto de control alumno_operacion, podríamos hacer lo siguiente:

class ci_inscripciones_pers extends ci_inscripciones {

function guardar() {
    //Ejecutamos guardar de la clase padre
    parent::guardar();

   $ptos_control_a_validar = array(guarani_punto_de_control::alumno_operacion);
$params = array('alumno'		=> $datos_alumno['alumno'],
					'persona'		=> $datos_alumno['persona'],    
					'plan_version'	=> $datos_alumno['plan_version'],    
					'fecha'			=> guarani_fecha::get_hoy(),
					'propuesta'		=> $datos_alumno['propuesta']);

    $retorno = guarani::validador_puntos_de_control($pto_control_a_validar, $params)->controlar();

}

}

Esto valdría la pena sólo si el requisito se implementa en varios lugares… si sólo se hace en ese punto, no se si sería mejos directamente hacer una llamada a una api y listo.

Saludos.

Entiendo, lamentablemente en el caso de la aceptación de la inscripción la función en común va más abajo y es una llamada al act_inscripciones. Es una opción extender esta función, haciendo que llame al parent y luego a nuestra API. Pero nos sigue pareciendo poco prolijo y riesgoso, ya que esta función podría modificarse en el core ante una actualización. De todas formas gracias por el código de ejemplo. Saludos!

Hola Pablo, nosotros tenemos la misma problemática con el campus virtual. Actualmente tenemos un script que se ejecuta todas las noches y que pasa la información de Guarani al Campus, pero no es para nada eficiente y no tenemos la info online. También justamente estos días estuvimos pensando en la idea de agregar triggers a las tablas de Guarani y que mediante dblink se conecte a la base del Campus para actualizar las tablas, en nuestro caso la información es unidireccional, de Guarani a Campus, por lo que también consideramos viable esa alternativa. No tenemos nada formalizado aún.
Saludos!