Esta transacción gestiona los «servicios» de las transacciones.

La lista de tareas se elabora leyendo todas las entradas del flujo de trabajo (de la tabla WFE) que están esperando a que cualquiera de los servicios marcados sean ejecutados por esta instancia del Administrador de tareas (consulte también la descripción general de Flujo de trabajo). La transacción correspondiente a una entrada de la lista de tareas, que está lista para su ejecución, se «abre». A continuación, se ejecutan todos los servicios de esta transacción, si están marcados para ejecutarse por esta instancia del «Administrador de tareas» y están «esperando» su ejecución, o estarán esperando a que se ejecuten tras la finalización satisfactoria de otros servicios en la misma transacción (así se optimizan las recargas necesarias de las transacciones).

Se pueden iniciar varias instancias del Administrador de tareas con el interruptor «-I <nombre del archivo ini>» en la línea de comandos del sistema en tiempo de ejecución. Las instancias se pueden iniciar con diferentes ajustes (por ejemplo, qué servicios están habilitados). Es útil tener una instancia separada del Administrador de tareas que maneje los mensajes SWIFT salientes, si esto es necesario por razones técnicas.

Los servicios que pueden aceptar parámetros adicionales, como los nombres de impresora y directorio, tienen un panel independiente en el que se pueden introducir estos valores adicionales (para obtener más información, consulte el apartado siguiente).

Importante: Los gerentes que se ejecutan en el modo de primer plano siempre deben iniciarse manualmente. 

Servicios que comienzan con «SRVPD» (p. ej., SRVPDS, SRVPDP y SRVPDA) y SRVCOM se denominan servicios de «polling».

Estos servicios se pueden volver a intentar tantas veces como se desee hasta que se haya alcanzado la condición necesaria «hecho» («D'one»). Para todos los demás servicios, un estado de 'R'etry' para una transacción debe ser un evento raro y transitorio. Por lo tanto, para cualquier servicio sin contaminación, la entrada del flujo de trabajo se establece en el estado 'E'rror', si se da un estado de reintento por tercera vez.

Si un servicio devuelve un «error» diez veces consecutivas, se genera un «evento» para este servicio y el servicio se detiene automáticamente. Esto se debe a que el sistema supone que hay un problema técnico (por ejemplo, en caso de que se interrumpa la conexión Swift) con este servicio. Intenta evitar que demasiadas entradas del flujo de trabajo pasen al estado de error, ya que esto provocaría un trabajo manual adicional después de restablecer la conexión.

Las estadísticas de los servicios ejecutados se actualizan internamente después de cada ejecución de un servicio en la tabla SYB siempre que la lista de entradas del flujo de trabajo se actualice desde la tabla WFE.

Si los servicios SRVPDS o SRVPDA reconocen que la transacción ha sido rechazada o enviada para su corrección, la entrada del flujo de trabajo actual se establece en 'C'ancel y cualquier entrada WFE abierta o en espera (con la excepción de SRVCLN) se establece en 'S'kip, de modo que 'SRVCLN' se convierte en el siguiente servicio en espera.

La ejecución correcta de cualquier servicio y el último intento de los servicios de sondeo se marcan dentro de la entrada del flujo de trabajo.

Para errores, cancelaciones y reintentos en servicios que no son de sondeo, se envía un mensaje de notificación al usuario responsable y se crean dos entradas de eventos:

• para el servicio
• para la transacción

La información del evento del flujo de trabajo (Tabla WFE) y los eventos adicionales de la transacción (Tabla EVT con objetos de tipo TRN) se mueven de la Tabla WFE o EVT a un bloque de texto dentro del registro de transacción (TRN\EVTTXT) por parte de Service SRVCLN. Esto se hace para mantener el tamaño de las mesas WFE y EVT pequeñas.

Cuando un servicio se detiene automáticamente (es decir, si un servicio se cancela después de 10 errores consecutivos), se envía un mensaje de notificación al usuario administrador (ADMUSR), si se ha definido.

Si el administrador de tareas se ejecuta en segundo plano en un entorno Unix, acepta los siguientes comandos a través de IPC (por ejemplo, enviada por la transacción SYSMGR que se ejecuta en el mismo sistema)

El periodo de reinicio siempre se mide en relación con la última hora de inicio del administrador. Si la carga es alta, el resultado es un tiempo de espera general bajo durante el cual el administrador está inactivo.

Por lo tanto, una carga baja crea un mayor tiempo de espera del gerente (para poder utilizar más recursos en procesos interactivos a favor de un mejor rendimiento).

Los archivos de mensajes generados por los servicios salientes suelen almacenarse en subdirectorios de la partición «Datos».

Por lo tanto, los nombres de ruta relativos para definir los directorios de salida están relacionados con la partición «Datos». Si, por razones organizativas, es necesario, también se pueden definir nombres de ruta absolutos. También es posible utilizar el prefijo «db:» (archivos en bases de datos).

Además, es posible establecer la ubicación del archivo de mensaje con una regla específica del cliente «GetOutDirRel».

Nota: Un archivo puede incluir más de un mensaje. En caso de que se produzca un error en este archivo al procesar el contenido del mensaje, pero otros mensajes ya se hayan procesado correctamente en este archivo, el archivo se moverá a 
 * «arc» (arco) (para archivar los mensajes procesados correctamente) 
 * y copiado a «error» (para mensajes que no se han procesado correctamente).

Si el mensaje se va a almacenar en un directorio específico del cliente, se debe marcar la casilla de verificación «Separar directorio por entidad».

Si se marca esta casilla, un nuevo nivel con el nombre de la clave externa de la entidad <ETYEXTKEY> (por ejemplo, «HAMBURG») se añade debajo de los directorios de salida (xxxOUT).

Por lo tanto, los mensajes se dirigirán inmediatamente a carpetas de la entidad específica del cliente correspondiente. Lo mismo se aplica a los archivos/mensajes erróneos. Este nivel también tendrá subdirectorios «arco» y «error» (mensajes archivados y erróneos).

El servicio de impresión de documentos SRVPRT gestiona todas las impresiones de documentos salientes. Por lo general, hay varias instancias de SRVPRT, que permiten al usuario imprimir diferentes copias (original, copia de archivo, copia del cliente) en diferentes momentos dentro del flujo de trabajo.

El panel «Imprimir» contiene los ajustes de impresión para el «Administrador de tareas» y se aplica a todos los servicios que requieren impresión. Los detalles sobre la solicitud y los formularios técnicos se pueden encontrar en la documentación del . Impresión

Si la opción «Crear archivos Postscript» está activada, se crea un archivo PostScript que se envía (junto con el nombre de impresora seleccionado) al script «tdprtcmd» (resp. TDPRTCMD.BAT) para ser reenviado a la cola de impresoras o para pasarlo al dispositivo de salida respectivo. Ordenadas por impresoras, todas las solicitudes se fusionan en un archivo PostScript, de modo que todas las impresiones pertenecientes a una transacción se imprimen una tras otra. El archivo PostScript se envía mediante el script «bin/unix/tdprtcmd» a la cola de impresión Unix (resp. al script TDPRTCMD.BAT para su posterior procesamiento en Windows).

Si se selecciona la opción «Impresión de Windows Server», en instalaciones de Client Server con un servidor que se ejecuta bajo Windows, el usuario puede imprimir en impresoras Windows «conocidas» por el servidor.

Con mensajes estructurados como SWIFT, DTA o allNETT, al seleccionar «Ambos» en la lista de selección «Formato» para la cuadrícula «Formularios técnicos» significa que tanto el formato sin procesar como PrettyPrint se imprimen. En el caso de mensajes no estructurados, como cartas, télex o faxes, esta selección solo hace que se imprima el formulario formateado.

Al reenviar el mensaje a través de la transacción, se añade una Reenviando Mensajes - Posible Duplicidad frase al texto del encabezado que indica los mensajes, por ejemplo, como «copia» o «duplicado». Este término puede introducirse libremente en la parte inferior del panel «Imprimir» en el campo «Duplicar».

Algunos mensajes salientes se pueden enviar a través de la serie MQ. Por lo tanto, es necesario configurar esta interfaz.

Deben definirse los siguientes campos:

Si no se rellena uno de los parámetros opcionales, todos los parámetros opcionales se toman de las variables de entorno del MQSERVER.

Los códigos de error de la serie MQ se pasarán 1:1.

Puede encontrar más información sobre estos códigos de error en la documentación de la serie MQ.

Algunos mensajes salientes pueden enviarse a través de Kafka. Por lo tanto, es necesario configurar esta interfaz.

Deben definirse los siguientes campos:

Algunos mensajes salientes pueden enviarse a través de FTP. Por lo tanto, es necesario configurar esta interfaz.

Deben definirse los siguientes campos:

El mensaje para Target2 (T2 RTGS) y SWIFT XML se puede enviar utilizando XMLv2 Envelope.

Cuando se selecciona XMLv2 Envelope, se necesita una configuración adicional.

Administrador de Tareas
Servicios
Imprimir
Liberación
Firmas
Verificar Estado de Límite
Antecesores
Compromiso
SWIFT Send
TradeConnect Send
Check for pending ACK's
Limpiar
TARGET
Target2
SWIFT XML
DTA Import L/C
DTA Export L/C
DTA Guarantees
Finalizar Orden
Eliminar Liquidación Temporal
Bolero
Email Send
Fax
Fecha de Ejecución
DTAUS / IZV
Compliance check
Externo
Document Generation Send
Export Bookings
allNETT
Enviar Actualizaciones de Estado
RIVO
Verificar Documentos
SEPA
SIC / EuroSIC
EuroSIC
Texto
TELEX Out
Activos Vendidos
Respuesta Financiación

(Para fines de servicios individualizados, véase descripción del flujo de trabajo

Si un mensaje de puntuación saliente tiene la etiqueta 23 X rellenada (es decir, el mensaje tiene archivos adjuntos), todos los archivos adjuntos en el servicio se empaquetan en un archivo .zip con el nombre indicado en la etiqueta 23X, y este archivo se coloca luego en el directorio configurado en «Additional configuration for FileAct (Additional configuration for FileAct (SCORE attachments)» listo para el transporte.

Si el formato está configurado como «SWIFT Alliance Lite», este archivo se enviará automáticamente por correo a través de FileAct; de lo contrario, el inicio del transporte debe implementarse adecuadamente en la regla específica del cliente para el envío de mensajes («SendMessageCust»).

Si es necesario enviar mensajes Swift a través de la serie MQ, es necesaria la siguiente definición:

La casilla de verificación «Enviar sobre MQ» debe estar marcada y deben definirse los siguientes campos:
«Gerente»
«Cola»
«CCSID»

La conexión MQ puede definirse de dos formas:
con la variable de entorno MQSERVER
o marcando la casilla «Set MQ Connection» y especificando los tres campos
«Canal»
«Tipo»
«Conexión»

Si es necesario utilizar la encriptación SSL, se debe marcar la casilla «Usar SSL», se deben especificar el «repositorio de claves» y el «cifrado».

Deben especificarse los siguientes campos al utilizar la interfaz Kafka
Archivo Ini: Archivo Ini con los ajustes del productor
Topic: El tema al que se envía el archivo rápido
Encabezado: Claves de encabezado y valores de encabezado
Teclas: Valores clave

Los archivos de mensajes generados por los servicios salientes suelen almacenarse en subdirectorios de la partición «Datos».

Por lo tanto, los nombres de ruta relativos para definir los directorios de salida están relacionados con la partición «Datos». Si, por razones organizativas, es necesario, también se pueden definir nombres de ruta absolutos. Al hacerlo, también es posible el uso del prefijo n 'db:' (archivos en bases de datos).

Los mensajes técnicos (p. ej. SWIFT) que pertenezcan a un contrato se reenviarán al destinatario como un archivo adjunto al mensaje de TradeConnect. Al marcar la casilla de verificación «Enviar mensajes técnicos formateados», se formateará dicho mensaje técnico y se adjuntará como PDF.

El texto del encabezado se utilizará como texto de encabezado para todos los archivos adjuntos generados como documentos PDF (por ejemplo, cartas reenviadas o mensajes SWIFT). Esto garantiza que los documentos no se confundirán con los originales cuando se muestren o impriman.

Este panel se utiliza para mantener/eliminar datos usando el servicio SRVCLN.

Para los sistemas de producción, se recomienda activar las siguientes opciones:

• Actualización de archivos + tablas: la información de las tablas WFE, TRS y EVT que se requiere para el historial se guardará automáticamente en TRN\EVTTXT. Si estos datos no se eliminan rápidamente en los sistemas de producción, se producirán tiempos de respuesta más lentos (debido a que la tabla de WFE se llena en particular).
• Eliminar eventos (EVT): la información de la tabla EVT necesaria para el historial se guardará automáticamente en . TRN\EVTTXT Después de la eliminación, solo la evaluación de dicha información a través del acceso directo a la base de datos es más difícil.
• Delete Before-Image files (BIM) (Eliminar archivos de imagen previa): estos datos ocupan mucho espacio y, una vez que se ha completado una transacción, solo se necesitarían para el análisis de errores, si es que se han realizado.
• Borrar archivos de datos de transacción (DAT): estos datos ocupan mucho espacio y, una vez que se ha completado una transacción, solo se necesitarían para el análisis de errores, si es que se han realizado.

Sin embargo, la eliminación de los archivos de visualización debe realizarse con cuidado:

• Borrar archivos de visualización (DSP): los archivos de visualización NO deben eliminarse porque el contenido de los formularios de pantalla que se muestran en «Detalles» de las transacciones se almacenan aquí (dependiendo del espacio disponible, los archivos de visualización se eliminarán después de un cierto periodo de tiempo (> 12 meses) o cuando se archiven los contratos antiguos).

Las casillas de verificación “Mant. archivos y tablas”, y «Eliminar archivos de imagen previa (.BIM)» y «Eliminar archivos de datos de transacción (.DAT)» están marcados por defecto.

Para obtener una descripción detallada de la configuración del terminal Bolero, consulte Configuration of outgoing messages.

Este servicio comprueba la corrección de los mensajes SWIFT y allNETT.
Si un mensaje SWIFT no es correcto, por ejemplo, es demasiado largo, esta transacción se enviará a corrección.
Los mensajes XML de AllNETT se comprobarán comparándolos con su correspondiente definición xsd. Si la comprobación falla o no se puede encontrar el archivo xsd, la entrada del flujo de trabajo de esta transacción se establecerá como error. Esta validación se puede activar o desactivar con la casilla de verificación «Validación de AllNETT XML».

Si se marca «Archivo independiente», todos los documentos se imprimen por separado, no se incluyen en un archivo para cada cola de impresión/impresora.