Modulo principal de la solución que orquesta los módulos a ejecutar secuencialmente. Permite la ejecución de una secuencia de módulos conservando el contexto entre cada uno de ellos.
...
MODULO | NOMBRE TÉCNICO | PARAMETROS | DESCRIPCIÓN |
orchestrator | localejbs/com.realtech.adapter.orch.modules.xi.ModuleOrchestratorPIBean | RT.modules | Listado de módulos que se ejecutarán. Ej:”funlog1; xmlcheck; checknif; verifysign; htmlvisor; funlog2; ocspcheck; funlog3; xmltransform; imxml; ack;” |
basic.bean | Path al bean de funciones básicas del orquestador. “localejbs/com.realtech.adapter.orch.modules.core.ext.BasicModuleBean” | ||
core.license | Path al fichero que contiene la licencia del conector. EJ: “/usr/sap/DX0/realtech.com/efact/license/license_29092011.lic” Para SII se ha definido un parámetro para no realizar validación de licencia, el valor en este caso será: “SII” | ||
Modo de tratamiento de licencia. Posibles valores: SAP (no es necesario configurarlo) o INT para validación interna. | |||
core.scenario | Texto que asociará la ejecución a un escenario (Emisión o Recepción). Ej: “EFACT_OUT” | ||
core.tf_bean | Path al bean de facilidad de traza.
Si no se especifica ninguno se instancia el DefaultTraceFacility que guardan el contexto en PI y se guardan las trazas en fichero (necesario especificar tf.dfilename y tf.dfilepath). El DefaultTraceFacility es recomendable usarlo en configuraciones síncronas ya que al no ser un EJB Statefull es mucho más rápido que cualquier otra opción. | ||
core.tf_level | Nivel de información en las trazas. Posibles valores:
Optimizaciones de traza para SII:
| ||
tf.write_logs_in_file | Indica si los logs técnicos se deben generar en fichero ("X"). En caso de especificar esta opción se deben especificar las propiedades tf.dfilename y tf.dfilepath. Cualquier otro valor los logs no se guardarán en fichero (ni en ningún otro sitio) por lo que no es necesario especificar las variables arriba indicadas. Solo está implementado para el SIILogTraceFacility y para el DefaultTraceFacility, TraceFacility que se ejecuta si no se especifica clase de traceFacility. | ||
tf.dfilename | Como alternativa al parámetro “tf_bean”, es posible dejarlo vacío y configurar un fichero dónde almacenar el log técnico (Especialmente útil para sistemas no SAP). Se genera un fichero por mensaje. Ej: “FacturaE.txt”. | ||
tf.dfilepath | Ruta dónde almacenar los anteriores ficheros. Ej: /PIJ/logs | ||
trace.sap_rfc_dest | Nombre del destino RFC dónde se enviarán las trazas. Ej: “DR6CLNT200” | ||
trace.sending_mode | Parámetro opcional para indicar el comportamiento a la hora de escribir trazas en el log. Los posibles valores son:
| ||
orchpi.dyn_conf[X] | Permite cargar de Dynamic Configuration al Contexto del orchestador, al HashMap de parametros de sessión. Se pueden definir n variables empezando por el 0. Si por ejemplo se define la siguiente propiedad: orchpi.dyn_conf[0]=urn:send:invoice&&&GUID El proceso recupera del Dynamic Configuration la propiedad GUID con namespace urn:send:invoice y la guarda con el nombre urn:send:invoice&&&GUID en el Contexto. Para recuperarla se debe acceder asi: xmltransform.param_value[0]=@S_PARAM{urn:send:invoice&&&GUID} Está implementado en el orchestadorPI (modulo de canal) y en el adaptador genéricoBPLUS. No en el adaptador de AAPP. | ||
core.external_uid | Parámetro para indicar que la instanciación del orquestrator se realice con un GUID externo en vez del mensaje de PI. Se recupera un guid del payload recibido mediante una expresión xpath. Ej: @XPATH{expresión} | ||
core.uid | Parámetro para indicar que la instanciación del orquestrator se realice con un GUID indicado en vez del generado aleatorio actual. Se recupera un guid del payload recibido mediante una expresión xpath. Ej: @XPATH{expresión} | ||
core.sii_eoio_queues | Parámetro para indicar si se utilizan colas EOIO para la comunicación con el modo SII. Ej: “X” o “-“. Un cambio en este parámetro requiere el reinicio de las aplicaciones asociadas a los consumers proxies del SII desde NWA - Start & Stop. | ||
core.eoio_tec_queue | En caso de utilizarse el parámetro “core.sii_eoio_queues”, se indicará el nombre de la cola para el log técnico. Ej: “DASHBOSIITECN001”. Un cambio en este parámetro requiere el reinicio de las aplicaciones asociadas a los consumers proxies del SII desde NWA - Start & Stop. | ||
core.eoio_fun_queue | En caso de utilizarse el parámetro “core.sii_eoio_queues”, se indicará el nombre de la cola para el log técnico. Ej: “DASHBOSIIFUNC001”. Un cambio en este parámetro requiere el reinicio de las aplicaciones asociadas a los consumers proxies del SII desde NWA - Start & Stop. | ||
core.reload_config | Parámetro que carga los parámetros de la configuración de los módulos con la configuración recibida por el Orchestrator en lugar de la persistida por contexto. Ej: “X” o “-“. Válido si solo hay una instancia del Orchestrator. | ||
core.not_final_status | Parámetro para cambiar el estado final utilizado por el orchestador (Necesario para instanciarlo en dos canales dentro del mismo excenario). Ej: “X” para indicar que no es estado final | ||
core.not_delete_context | Control de borrado del contexto tras una ejecución. Posibles valores:
Nota: El contexto se debe borrar cuando el producto se instala como adapatador o en escenarios síncronos. Si se instala como channel module asíncrono no se debe borrar ya que un fallo posterior en el adaptador provocaría reprocesamiento de todos los modulos al no haber contexto. Para el caso de channel module se pueden borrar los contextos manualmente usando el WS PiContextEJB, método deleteAll: borra los contextos anteriores a una fecha pasada por parámetro. | ||
core.reload_ctx_from_previous_instance | Parámetro para recargar el contexto con la configuración de los módulos en el Receiver cuando hay una instancia previa ejecutada en el Sender. Ej: “X” | ||
core.set_payload_to_context | Control de persistencia del payload en el contexto. Posibles valores:
También es posible configurarlo a nivel de módulo (Consultar cada uno de ellos). | ||
core.aapp_tr_level | Traza del adaptador:
|
...