La aplicación debe implementar la interfaz de de devolución de llamada NotificationDelivery para determinar cómo se manejan las notificaciones en la aplicación.
El motor de flujo de trabajo invocará el método deliverNotification de la clase de implementación curam.util.workflow.impl.NotificationDelivery para procesar la notificación. El motor pasará a este método de aplicación la lista de destinos de asignación determinada por la estrategia de asignación y los detalles de la notificación necesaria.
La propiedad de aplicación curam.custom.notifications.notificationdelivery define qué implementación de la interfaz NotificationDelivery utilizará el motor de flujo de trabajo para procesar la notificación.
El método deliverNotification de esta clase de implementación está sobrecargado. Esto se debe a que los diferentes tipos de estrategia de asignación devuelven los destinos de asignación en formatos distintos. No obstante, esto es un detalle de implementación del que no tienen que preocuparse los desarrolladores de clases personalizadas de entrega de notificaciones, sobre todo porque el procesamiento de negocio de todas las versiones del método debería ser el mismo.
package curam.util.workflow.impl;
...
public interface NotificationDelivery {
boolean deliverNotification(
final NotificationDetails notificationDetails,
final Object allocationTargets);
boolean deliverNotification(
final NotificationDetails notificationDetails,
final Map allocationTargets);
boolean deliverNotification(
final NotificationDetails notificationDetails,
final String allocationTargetID);
...
}
Para paliar este problema, curam.core.sl.impl.DefaultNotificationDeliveryAdapter proporciona un mecanismo más cómodo de implementar un programa de resolución de trabajo. Esta clase implementa los distintos métodos y convierte sus parámetros de entrada en listas de destino de asignación, permitiendo a los desarrolladores de lógica personalizada de entrega de notificaciones extender esta clase e implementar un método que se invoca independientemente del origen de los destinos de asignación.
package curam.core.sl.impl;
...
public abstract class DefaultNotificationDeliveryAdapter
implements curam.util.workflow.impl.NotificationDelivery {
public abstract boolean deliverNotification(
final NotificationDetails notificationDetails,
final AllocationTargetList allocationTargets);
...
}
Además de esta clase de adaptador, la aplicación se distribuye con una implementación de entrega de notificaciones que ya va lista para utilizarse. Dicha clase se denomina curam.core.sl.impl.DefaultNotificationDelivery y también sirve de ejemplo de cómo extender el adaptador.
Las estrategias de entrega de notificaciones se listan en la tabla de códigos DELIVERYMECHANISM. La adición de una nueva estrategia consiste simplemente en extender esta tabla de códigos con una nueva estrategia (por ejemplo, SMS) e implementar una estrategia de entrega que reconozca este código y lleve a cabo la lógica adecuada. Sin embargo, y puesto que la clase de entrega de notificaciones se establece mediante una única propiedad de aplicación, la sustitución de la clase curam.core.sl.impl.DefaultNotificationDelivery inhabilitaría los mecanismos de entrega que ya van preinstalados. Si el objetivo es ampliar, y no sustituir, los mecanismos de entrega preinstalados, las clases personalizadas deberían extender curam.core.sl.impl.DefaultNotificationDelivery de modo que se conserve la funcionalidad original. La clase curam.core.sl.impl.DefaultNotificationDelivery se ha implementado teniendo esto en cuenta.
package curam.core.sl.impl;
public class DefaultNotificationDelivery
extends DefaultNotificationDeliveryAdapter {
public boolean deliverNotification(
NotificationDetails notificationDetails,
AllocationTargetList allocationTargetList) {
return selectDeliveryMechanism(
notificationDetails, allocationTargetList);
}
protected boolean selectDeliveryMechanism(
NotificationDetails notificationDetails,
AllocationTargetList allocationTargetList) {
boolean notificationDelivered = false;
if (notificationDetails.deliveryMechanism.equals(
curam.codetable.DELIVERYMECHANISM.STANDARD)) {
notificationDelivered = standardDeliverNotification(
notificationDetails, allocationTargetList);
} else if (
...
return notificationDelivered;
}
...
}
La clase curam.core.sl.impl.DefaultNotificationDelivery implementa el método deliverNotification del adaptador abstracto, pero delega de forma inmediata la identificación del mecanismo a utilizar a un método protegido. Las subclases pueden sobrescribir el método protegido selectDeliveryMechanism para identificar los mecanismos de entrega personalizados y llevar a cabo las operaciones adecuadas tal y como se muestra en el ejemplo siguiente:
public class CustomNotificationDeliveryStrategy
extends DefaultNotificationDelivery {
protected boolean selectDeliveryMechanism(
NotificationDetails notificationDetails,
AllocationTargetList allocationTargetList) {
boolean notificationDelivered = false;
boolean superNotificationDelivered = false;
superNotificationDelivered = super.selectDeliveryMechanism(
notificationDetails, allocationTargetList);
if (notificationDetails.deliveryMechanism.equals(
curam.codetable.DELIVERYMECHANISM.CUSTOM)) {
notificationDelivered = customDeliverNotification(
notificationDetails, allocationTargetList);
}
return (superNotificationDelivered || notificationDelivered);
}
}
Tenga en cuenta que el método selectDeliveryMechanism de la clase personalizada delega en primer lugar en la superclase antes de ejecutar su propia lógica. Al extenderse la funcionalidad de esta forma, se permite que las clases personalizadas invoquen el mecanismo de entrega preinstalado sin tener que conocer los códigos específicos que reconoce la clase padre. Este enfoque también facilita las actualizaciones, ya que si una versión futura de Cúram soporta más mecanismos de entrega preinstalados, no tendrá que cambiarse una clase personalizada implementada como se muestra aquí para valerse de la nueva funcionalidad.
El distintivo booleano que devuelve la función de entrega anterior se utiliza para indicar al motor de flujo de trabajo si la notificación se ha entregado a al menos un usuario del sistema. Si no ha sido así, el motor entregará un registro de auditoría de flujo de trabajo en el que se detalle este hecho.