Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

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”


core.license_mode


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.

  • PI Trace Facility. Guarda el contexto en la BD de PI y las trazas en el ECC: core.tf_bean=localejbs/com.realtech.adapter.orch.modules.trcfac.SapPITraceFacilityBean
  • Trace Facility. Guarda el contexto y las trazas en el ECC (Deprecado/NoUsar): core.tf_bean=localejbs/com.realtech.adapter.orch.modules.trcfac.SapTraceFacilityBean
  • SII Trace: Trace Facility para SII, realizando la escritura de las trazas en el log del Dashboard de SII: core.tf_bean=localejbs/com.realtech.adapter.orch.modules.trcfac.SIITraceFacility30Bean

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:

  • 0: ALL
  • 100: DEBUG
  • 200: INFO
  • 300: WARNING
  • 400: ERROR
  • 500: CRITICAL
  • 600: SUCCESS
  • 1000: CONTEXT
  • 1001: START PROCESS
  • 1002: END PROCESS (Recomendado para un entorno productivo con alta volumetría)

Optimizaciones de traza para SII:

  • 150: Log técnico envía trazas (excepto debug), log funcional sólo 400 y 1002.
  • 1003: Log técnico no envía nada, log funcional sólo 400 y 1002.
  • 9999: No envía los técnico ni log funcional, para comunicaciones síncronas.
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:

  • “single”: Comportamiento antiguo, realizando una llamada por traza a guardar. No recomendado.
  • “module”: se realiza una llamada por traceStack, evitando así realizar múltiple llamadas. Comportamiento por defecto, desde 2017, si no se especifica valor 


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érico. No en el adaptador de FACE.



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:

  • 0: Borrar siempre contexto.
  • 1: No borrar contexto (Valor por defecto).
  • 2: Borrar contexto sólo en caso de finalización correcta.

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:

  • X: Persistir payload siempre (Valor por defecto).
  • -: No persistir los payload siempre.

También es posible configurarlo a nivel de módulo (Consultar cada uno de ellos).



 

core.aapp_tr_level

 Traza del adaptador:

  • 0 no traza
  • 500   success y sin payload
  • 1000    completa ----Valor Por defecto----

...