nb29 dsi arq nor manual de utilidades de la … · que la arquitectura diseñada para el proyecto...

MANUAL DE UTILIDADES DE LA ARQUITECTURA.

Fecha: 06/04/2010 Referencia:

EJIE S.A.

Mediterráneo, 3

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

Control de documentación

Título de documento: Manual de Utilidades de la Arquitectura.

Histórico de versiones

Código:

Versión: 2.0

Fecha: 06/04/2010

Resumen de cambios:

Cambios producidos desde la última versión

Primera versión.

Control de difusión

Responsable:

Aprobado por:

Firma: Fecha:

Distribución:

Referencias de archivo

Autor: Antonio Gallego.

Nombre archivo: NB29_DSI_ARQ_NOR_Manual de Utilidades de la Arquitectura (2.0).doc

NB29_DSI_ARQ_NOR_Manual de Utilidades de la Arquitectura (2.0).doc ii/47

Contenido

Capítulo/sección Página

1 Introducción. 1

2 INTERMEDIARIO DE NEGOCIO. 2

2.1 Descripción. 2

2.2 API: 3

2.3 Configuración: 4

2.3.1. Configuración de acceso a un EJB: 6

2.3.2. Configuración de acceso a un JPD: 6

2.3.3. Configuración de acceso a un WebService: 7

2.4 Uso 7

2.4.1. Acceso a un EJB 7

2.4.2. Acceso a un JPD 8

2.4.3. Acceso a un WebService 8

2.5 Elementos comunes: 9

2.5.1. Decoradores: T49ebAuditFlujo y T49ebAuditFlujoWS 9

2.5.2. Propiedad: simulPath 9

3 GESTIÓN DE EXCEPCIONES 11

3.1 Descripción. 11

3.2 API: 12

3.3 Configuración 15

3.4 Guía de Uso 15

4 ACCESO A FICHEROS DE PROPIEDADES. 16

NB29_DSI_ARQ_NOR_Manual de Utilidades de la Arquitectura (2.0).doc iii/47


4.2 API: 16

4.3 Ejemplo de uso: 16

5 GESTIÓN DE BASES DE DATOS. 18


5.2 API: 18


5.4 Ejemplo: 19

6 GESTOR DE LOGS 21


6.2 API: 21


6.4 Ejemplo: 26

7 USO Y GESTIÓN DE CACHÉS 27


7.2 API: 28


7.3.1. Regiones: 30

7.3.2. Auxiliares: 31


8 CAMPOS LOB DE BASE DE DATOS 33


8.2 API. 33

9 FECHAS 37


9.2 API: 37

NB29_DSI_ARQ_NOR_Manual de Utilidades de la Arquitectura (2.0).doc iv/47

9.3 Configuración 37


10 CONSTANTES COMUNES 37

11 OTRAS UTILIDADES 37

NB29_DSI_ARQ_NOR_Manual de Utilidades de la Arquitectura (2.0).doc 1/47

1 Introducción.

Este documento está orientado a los equipos de diseño y construcción de las aplicaciones que conforman en nuevo Sistema General de Industria. Pretende ser una guía de uso y configuración de las utilidades técnicas que la Arquitectura diseñada para el proyecto ofrece a las aplicaciones.

Todas estas utilidades técnicas se reúnen en torno a un mismo código de aplicación (t49eb), que distribuye un API con todos los procesos comunes reutilizables en todas las aplicaciones del sistema.

En la documentación de este código de aplicación (javadoc) se pueden eencontrar todas las clases y métodos utilizables con más información.


2 INTERMEDIARIO DE NEGOCIO.

2.1 Descripción.

T49ebBusinessObjectFactory:

El Intermediario de Negocio, o Business Delegate, es el elemento encargado de intermediar entre cualquier componente de la arquitectura y la interfaz remota que presente cualquier otro elemento. Permite acceder a interfaces de tipo EJB, WebService y JPD.

El intermediario de negocio es de tipo programático por lo que hay que configurar cada interfaz invocado y se basa en el siguiente patrón:

sd Patrón

BusinessObjectFactoryObjetoInvocador InterfazRemota

BusinessObjectFactory:= getInstance(String appName)

InterfazRemota:= create(Class InterfazRemota.class)

String resultadoServicio:= servicioUno(String parametrosServicio)

• ObjetoInvocador : Clase desde la que se tiene la necesidad de invocar a una interfaz remota de otro elemento de la arquitectura.

• BusinessObjectFactory : Factoría de interfaces remotas, previamente, en la primera instanciación del objeto se ha cargado la configuración de todas las interfaces definidas en el fichero de configuración.

• InterfazRemota : Interfaz en la que se tienen definidos todos los servicios a los que se tiene acceso. Por ejemplo: en el caso de un EJB se trata del Bean Remoto del EJB incluido en el jar de despliegue.

El intermediario de negocio incorpora además una serie de facilidades:

- Permite simular servicios.


- Permite añadir comportamientos de entrada y salida a las peticiones. Decoradores de comportamiento.

2.2 API:

T49ebBusinessObjectFactory: Clase de entrada al Business Delegate.

� public static T49ebBusinessObjectFactory getInstance (String appName)

Descripción: Recupera una instancia de la factoría de interfaces definidas para la aplicación recibida como parámetro. En la primera invocación se recupera la configuración incluída en el fichero services.xml dentro de la carpeta “/config/codApp/services.xml “ donde se definen la localización, tipo y configuración extra necesaria para acceder a las interfaces..

o String appName : Código de la aplicación.

Resultado: T49ebBusinessObjectFactory � Factoría de interfaces de la aplicación.

Errores: Cuando se produce un error lanza una excepción de tipo T49ebUtilException.

� public static T49ebBusinessObjectFactory getInstanceWS (String appName, String nombreProveedor)

Descripción: Recupera una instancia de la factoría de interfaces definidas para la aplicación recibida como parámetro, en la que sólo se incluye la interfaz para acceder al servicio web cuyo nombre de proveedor se especifica por parámetro de entrada.


o String nombreProveedor: Nombre del proveedor especificado en el archivo services.xml para el servicio web que se desea utilizar.

Resultado: T49ebBusinessObjectFactory � Factoría con la interfaz del servicio web que se va a utilizar.


� public Object create (Class businessInterface)

Descripción: Recupera la interfaz de acceso que se pasa como parámetro, así mismo establece la conexión con el componente y asocia los decoradores configurados en el services.xml para dicha interfaz.

o Class businessInterface : Clase de la intefaz que se va a utilizar.

Resultado: Object � Interfaz de acceso remoto.


T49ebWSInterfaz: Clase interfaz de acceso a Servicios Web.

� public String runService (String b29Seguridad, String metodo, String[] paramNames, String[] paramTypes, String[] paramValues)

Descripción: Método de invocación a métodos de Servicios Web. Utiliza la URL del WSDL que se ha especificado en el archivo de configuración del servicio (services.xml) para realizar la llamada.

o String b29Seguridad : Objeto de seguridad de la NB29, con información del usuario y de la operación que se está realizando.

o String metodo : Método del Web Service que se desea invocar.


o String [] paramNames : Array de nombres de parámetros de entrada del método al que se desea invocar.

o String[] paramTypes : Array de tipos de objetos java de cada uno de los parámetros del método. Están definidos en la clase de constantes comunes T49ebConstantes.

o String[] paramValues : Array de valores de cada uno de los parámetros del método al que invocamos.

Resultado: Object � Interfaz de acceso remoto.

Errores: Cuando se produce un error lanza una excepción de tipo T49ebWSException

2.3 Configuración:

El Intermediario de Negocio cuenta con un fichero donde se configuran los parámetros de conexión a cada una de las interfaces que usa cada una de las aplicaciones del sistema NB29. El intermediario de negocio es una librería que ha de ser incluida dentro de cada uno de las aplicaciones de la arquitectura que necesiten acceder a negocio. Cada aplicación tiene una configuración independiente del elemento intermediario.

Situación del fichero de configuración:

/config/codApp/services.xml

El fichero de configuración es un XML con el siguiente esquema asociado:


- B29Servicios : Colección de servicios a los que se tiene acceso dentro de una aplicación de la arquitectura.

o B29Servicio : Definición de un servicio.

Atributos:

- nombreProveedor: Nombre lógico del proveedor de servicios. Se trata de un nombre identificativo para el servicio y para el programador. En el caso de un servicio web, será además el que se especifique al intanciar el intermediario.

- transaccionCliente: Indica si se quiere iniciar o no una transacción en el cliente. (true/false). Se recomienda el uso de false.

- interfaz: Clase con la interfaz de acceso al proveedor de servicios.

- claseDelegate: Clase del delegate sobre la que se ha definido la interfaz. Hasta el momento puede ser de varios tipos EJB, JPD, WS,…, aunque esta colección podría ir creciendo con el tiempo.

- [0,n]B29Property: Array de propiedades libres del servicio. En función del tipo de servicio al que se desea acceder, se configurarán las siguientes:

o Acceso a un EJB:

� jndi; Nombre JNDI del EJB al que se desea acceder.

� url; URL de acceso del EJB. Protocolo t3 del servidor en el que se encuentra. Aunque se se encuentra en la misma máquina no hace falta, se recomienda especificarlo para una mejor gestión de los servicios (traspasos entre entornos).

� claseHome; Clase de la Home del EJB.

� simulPath; Path donde se almacenarán los archivos de simulación.

o Acceso a un JPD: Las mismas que en un EJB.

o Acceso a un WebService:

� url; URL de acceso del http al servicio web..

� simulPath; Path donde se almacenarán los archivos de simulación.

o Acceso a un JPD: Las mismas que en un EJB.

- B29Decorador: Incorpora el comportamiento deseado a la invocación. Escritura de trazas, seguridad, etc, etc. Implementa un método de pre-invocación al servicio y otro de post-invocación.

Atributos:

o className: Nombre de la clase del decorador. Existen dos decoradores principales y obligatorios para la trazabilidad de los servicios (com.ejie.t49eb.utils.negocio.decorador.decoradores.T49ebAuditFlujo y com.ejie.t49eb.utils.negocio.decorador.decoradores.T49ebAuditFlujoWS).

o [0,n]B29Property; Array de propiedades libres del decorador. Por defecto, ninguna.


Especificación de configuración de un servicio :

<B29Servicio nombreProveedor =" nombreProveedor" � En los WS, el nombre con el que se instanciará el delegate

interfaz =" bean class name � Nombre del bean remoto del ejb claseDelegate =" com.ejie.t49eb.utils.negocio.delegates.T49ebEjbDelegate" transaccionCliente =" false/true "> � Normalmente será false <com:B29Property name =" url " value =" url del EJB "/> * Opcional � Si está en diferente máquina. <com:B29Property name =" jndi " value =" jndi del EJB "/> <com:B29Property name =" claseHome " value =" clase del home remoto definido para el EJB"/> �Clase de la home remota. <com:B29Property name =" simulPath " value =" C:\datos\simulados\REI\ "/> * Opcional � Si se quiere simular las operaciones del proveedor de servicios. <B29Decorador className =" com.ejie.t49eb.utils.negocio.decorador.decoradores. T49ebAuditFlujo "/> �Decorador necesario para el funcionamiento del Dele gate.

</ B29Servicio >

2.3.1. Configuración de acceso a un EJB:

Independientemente de la configuración de acceso necesaria para el funcionamiento del intermediario de negocio, es necesario disponer en la parte invocadora del cliente del EJB, a partir de la versión 2.0 de EJBs (el jar generado para el despliegue del EJB).

<B29Servicio nombreProveedor =" REI " interfaz =" com.ejie.t49cb.rei.interfaces.T49cbRei " claseDelegate =" com.ejie.t49eb.utils.negocio.delegates.T49ebEjbDele gate " transaccionCliente =" false "> <propiedad name =" jndi " value =" ejb.T49cbRei "/> <propiedad name =" url " value =" t3://webldes51,webldes52:7231 "/> <propiedad name =" claseHome " value =" com.ejie.t49cb.rei.interfaces.T49cbReiHome "/> <propiedad name =" simulPath " value =" C:\datos\simulados\REI\ "/> <B29Decorador className =" com.ejie.t49eb.utils.negocio.decorador.decoradores. T49ebAuditFlujo "/>

</ B29Servicio >

La claseDelegate será siempre la aportada por la arquitectura (com.ejie.t49eb.utils.negocio.delegates.T49ebEjbDelegate)

2.3.2. Configuración de acceso a un JPD:

La misma configuración que en el caso de un EJB, pero cambiando la clase Delegate por la correspondiente de acceso a JPDs (com.ejie.t49eb.utils.negocio.delegates.T49ebJpdDelegate)


2.3.3. Configuración de acceso a un WebService:

Para acceder a un WebService no hace falta tener ningún cliente del mismo en la aplicación invocadora, ya que el propio intermediario se encarga de realizar la invocación.

<B29Servicio nombreProveedor =" NORA_WS interfaz =" com.ejie.t49eb.utils.negocio.interfaces.T49ebWSInte rfaz " claseDelegate =" com.ejie.t49eb.utils.negocio.delegates.T49ebWSCLDel egate " transaccionCliente =" false "> <propiedad name =" url " value =" http://www.integracion.jakina.ejiedes.net/t17iApiWS War/t17iApiWS?WSDL "/> <propiedad name =" simulPath " value =" C:\datos\simulados\NORA\ "/> <B29Decorador className =" com.ejie.t49eb.utils.negocio.decorador.decoradores. T49ebAuditFlujoWS "/>

</ B29Servicio >

En el caso del acceso a un WebService, la clase interfaz y la clase Delegate serán siempre las aportadas por la arquitectura.

- Interfaz: com.ejie.t49eb.utils.negocio.interfaces.T49ebWSInterfaz

- Clase Delegate: com.ejie.t49eb.utils.negocio.delegates.T49ebWSCLDelegate

2.4 Uso

El intermediario de negocio hace que el acceso a cualquiera de las interfaces remotas de la arquitectura, sea cual sea la tecnología utilizada para exponer el servicio, se haga de la misma manera y de la forma más optimizada posible, sin que el desarrollador tenga que tener conocimiento de las características de la conexión, requisitos de configuración, etc.

Sea cual sea el tipo técnico de interfaz presentada por un servicio, la implementación de acceso es siempre la misma.

2.4.1. Acceso a un EJB

Ejemplo de uso del Intermediario de Negocio para el acceso a un EJB. Una vez configurado el servicio en el archivo de configuración (services.xml) y haber incluído el cliente correspondiente en las librerías de la aplicación (/lib), el código a utilizar para realizar la invocación sería el siguiente:

T49ebBusinessObjectFactory delegate = T49ebBusiness ObjectFactory.getInstance( codApp); //Instancia del Delegate definido para el código de aplicación que se pasa como parámetro. Lee el archivo services.xml y carga toda s las interfaces

T49cbGex fachada = (T49cbGex)delegate.create(T49cbG ex.class); //Se selecciona la clase interfaz que se va a utilizar

try {

String resultado = fachada.grabarEntrada(this._b29S eguridad,


entradaETDoc.xmlText(), abreExped, distribucion ); //Se invoca al método correspondiente

} catch (RemoteException e) {

throw new T49ebBOException( this._b29Seguridad, idSistema, mensajeError, e, T49ebBOException.SYSTEM_ALERT); //Se captura una posible exception de tipo Remote y se lanza la excepción de negocio correspondiente

}

2.4.2. Acceso a un JPD

Ejemplo de uso del Intermediario de Negocio para el acceso a un JPD. Una vez configurado el servicio en el archivo de configuración (services.xml) y haber incluído el cliente correspondiente en las librerías de la aplicación (/lib), el código a utilizar para realizar la invocación sería el siguiente:

T49ebBusinessObjectFactory delegate = T49ebBusiness ObjectFactory.getInstance( codApp); //Instancia del Delegate definido para el código de aplicación que se pasa como parámetro. Lee el archivo services.xml y carga toda s las interfaces

Q99vCommonUtilitiesFacadeP fachada = (Q99vCommonUtilitiesFacadeP)delegate.create(Q99vCom monUtilitiesFacadeP.class); //Se selecciona la clase interfaz que se va a utilizar

try {

String resultado = fachada.getXML(this._b29Segurida d, this._codMaestro); //Se invoca al método correspondiente

} catch (RemoteException e) {

throw new T49ebBOException( this._b29Seguridad, idSistema, mensajeError, e, T49ebBOException.SYSTEM_ALERT); //Se captura una posible exception de tipo Remote y se lanza la excepción de negocio correspondiente

}

2.4.3. Acceso a un WebService

Ejemplo de uso del Intermediario de Negocio para el acceso a un Servicio Web. Previamente deberemos haber configurado el servicio en el archivo de configuración (services.xml). El código a utilizar para realizar la invocación sería el siguiente:

T49ebBusinessObjectFactory delegate=T49ebBusinessObjectFactory.getInstance( codApp," nombreProveedor"); //Instancia del Delegate definido para el código de aplicación que se pasa como parámetro. Lee el archivo services.xml y carga el servicio cuyo nombr e de proveedor se especifica

T49ebWSInterfaz interfaz = (T49ebWSInterfaz)bDelega te.create(T49ebWSInterfaz.class); //Se selecciona la clase interfaz que se va a utili zar, en el caso de los Servicios Web siempre es la misma

try {


//Se instancian los arrays con los nombres, los val ores, y los tipos de los parámetros

String[] arrayParams = new String [] {"b29Seguridad ", "listaConceptosETDocumentStr"};

String[] arrayValues = new String [] {this.b29Segur idad, concepto.xmlText()};

String[] arrayTypes = new String [] {T49ebConstante s.WS_TIPO_STRING, T49ebConstantes.WS_TIPO_STRING};

String resultadoWS = null;

resultadoWS = interfaz.runService(this.b29Seguridad , "calcularConceptoPago", arrayParams, arrayTypes, arrayValues); //Se invoca al método runService, pasándo como parámetros los arrays anteriores y el método d el WS correspondiente

} catch (Throwable e) {

throw new T49ebBOException( this._b29Seguridad, idSistema, mensajeError, e, T49ebBOException.SYSTEM_ALERT); //Se captura una posible exception y se lanza la excepción de negocio corres pondiente

}

NOTA; Debemos conocer previamente la lista de parámetros y el método del web service al que queremos invocar.

2.5 Elementos comunes:

2.5.1. Decoradores: T49ebAuditFlujo y T49ebAuditFlu joWS

Los decoradores permiten añadir funcionalidad extra al comportamiento base del Intermediadrio de Negocio. Las clases T49ebAuditFlujo y T49ebAuditFlujoWS son las encargadas de apuntar en el Visor de Sucesos las invocaciones que se realizan entre los diferentes sistemas de la NB29. Esto permite poder tracear todas las transacciones realizadas y tener una visión más exacta de posibles problemas, rendimientos y errores que se puedan producir.

Estos decoradores se deben utilizar siempre en todos los servicios configurados para cada sistema.

2.5.2. Propiedad: simulPath

En el caso de incorporar esta propiedad dentro de la definición de un proveedor de servicios todos los servicios que se invoquen a través de dicha interfaz estarán simulados. La forma de actuar del simulador es la siguiente.

1. Comprueba si el path de simulación existe. En caso de no existir lanza un error y ejecuta el servicio sin simulación.

2. Comprueba si existe un fichero xml cuyo nombre debe de corresponderse con el nombre del servicio a invocar (nombreServicio.xml), en caso de no existir lo indica por consola y ejecuta el servicio en real, es decir, llama al proveedor de servicios para ejecutarlo.

3. Si el fichero existe recoge los datos y los carga en el resultado.


4. Si el fichero no existía, tras la ejecución en real carga el fichero de simulación, para futuras interacciones y retorna el resultado.

ad pruebas

inicio

if existssimulPathif existssimulPath

if existssimul fichif existssimul fich

returnSimulData

final

loadSimulFich realInv ocation

createSimulFich

realInv ocation

returnRealData

[no]

[no]

Esquema de funcionamiento de la simulación


3 GESTIÓN DE EXCEPCIONES

3.1 Descripción.

Package com.ejie.t49eb.utils.exception:

Librería java que contiene el catálogo de todas las excepciones de la arquitectura.

Se ha creado una excepción específica para los diferentes componentes y capas que componen la arquitectura. Cada una de las excepciones hereda de T49ebException , que a su vez hereda de javax.ejb.EJBException e implementa java.io.Serializable.

Todas las excepciones tienen un comportamiento común. En caso de recibir un objeto B29Seguridad como primer parámetro del constructor de la excepción se notifica la excepción al visor de sucesos, donde se podrá consultar el detalle del error producido, utilizando la configuración de trazas definida en el archivo de configuración de la aplicación.

Cada aplicación y cada sistema debe tener un juego de clases con variables constantes para definir los errores específicos que puede lanzar (codAppErrores.java). El patrón que seguirán estos errores será el siguiente:

T49ebException

T49ebBOException

T49ebDAOException

T49ebUtilException

T49ebWSException

T49ebEAVException

T49ebNORAException

T49ebDocumentumException

T49ebPasarelaPagosException

T49ebXLNETSException

EJBException, Serializable


public static final String APP_DESCRIPCIONERROR = "COD_ERROR | descrip ción del error.";

Ejemplos:

public static final String INT_FALLO_GENERICO = "INT_00000 | Fallo gen erico: ";

public static final String INT_INTERFAZ_NO_ENCONTRADO = "INT_00005 | El interfaz necesario en el cliente no está presente: ";

public static final String INT_CLASE_NO_ENCONTRADA = "INT_00006 | La cl ase necesaria en el cliente no está presente: ";

3.2 API:

T49ebBOException:

� public T49ebBOException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en la capa de negocio de los sistemas de la NB29.

o String b29Seguridad : Elemento de seguridad de la arquitectura, si es null no se notifica al visor de sucesos, si es un objeto válido si se notifica. El objeto es un string que se corresponde con B29SeguridadDocument.

o String idSistema : Identificador del sistema donde se lanza el error.

o String error : codigoError | mensaje del error. Cada sistema, y cada aplicación es responsable de mantener un catálogo de errores que cumplan este formato.

o Throwable e : Excepción que ha producido el error.

o int tipo : Puede ser funcional o de sistema.

� public T49ebDAOException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en la capa de acceso a base de datos de los sistemas de la NB29.






� public T49ebUtilException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en las utilidades de la arquitectura.







� public T49ebWSException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el los servicios Web.






� public T49ebEAVException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el adaptador de Platea.






� public T49ebXLNETSException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el adaptador de XLNETS.







� public T49ebNORAException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el adaptador de NORA.






� public T49ebDocumentumException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el adaptador de Dokusi.






� public T49ebPasarelaPagosException (String b29Seguridad, String idSistema, String error, Throwable e, int tipo)

Descripción: Constructor de la clase de excepción destinada a encapsular los errores producidos en el adaptador de Pasarela de Pagos.







3.3 Configuración

De cara a poder tracear en al visor de sucesos las excepciones producidas en el sistema, cada aplicación deberá especificar en el archivo de configuración (/config/codApp/codApp.properties) las siguientes propiedades:

################################################### ########################

# VISOR DE SUCESOS #

# Esta configuracion tiene que estar en todos las a plicaciones SGI. #

################################################### ########################

log4j.category.JMSTraceLogger=ERROR

log4j.InitialCtxt=weblogic.jndi.WLInitialContextFac tory

log4j.JMSConnectionFact=tramitacion1.tramitacion1JM SFactory

log4j.JMSTraceQueue=t49ab.t49abJMSQueue

log4j.URL=t3://webldes51,webldes52:7231

3.4 Guía de Uso

(Beatriz)


4 ACCESO A FICHEROS DE PROPIEDADES.

4.1 Descripción.

T49ebConfig.java:

Clase java que permite acceder a las variables almacenadas en los ficheros de propiedades de las aplicaciones, proporcionando un rendimiento óptimo de acceso.

4.2 API:

� public static String getProperty (String propertyPath, String property)

Descripción: Permite acceder a una propiedad a partir del nombre de la propiedad y del path donde se encuentra la propiedad.

o String propertyPath : Directorio donde se encuentra el fichero de propiedades de aplicación. Path relativo al classPath.

o String propiedad : Propiedad de la que se quiere recuperar el valor.

Resultado: String � String con el valor de la propiedad, en caso de no existir la propiedad devuelve un null.

Errores: Cuando se produce un error lanza una excepción de tipo T49ebUtilException

� public static Properties getProperties (String propertyPath)

Descripción: Permite recuperar todas las propiedades asociadas a una aplicación a partir del path donde se encuentra el fichero de propiedades.

o String propertyPath : Directorio donde se encuentra el fichero de propiedades de aplicación. Path relativo al classPath.

Resultado: Properties � Colección de propiedades asociadas a la aplicación.


4.3 Ejemplo de uso:

Fichero de propiedades: /config/codApp/codApp.properties

ClassPath del servidor …;/config/;….

Contenido del fichero de propiedades:

ds.dataSourceNoXA= codApp.codAppDataSourceNOXA

ds.dataSourceXA= codApp.codAppDataSource


Código:

String propertyPath = "/codApp/codApp.properties";

String dataSourceNoXA = T49ebConfig.getProperty(pro pertyPath, "ds.dataSourceNoXA");

String dataSourceXA = t49ebConfig.getProperty(prope rtyPath, "ds.dataSourceXA");


5 GESTIÓN DE BASES DE DATOS.

5.1 Descripción.

T49ebConectorJDBC:

Se implementa en un componente que encapsula la gestión de las conexiones a BD.

Permite obtener una conexión del pool de conexiones del servidor de aplicaciones así como cerrar una conexión (devolución al pool de dicha conexión para que se pueda reutilizar).

5.2 API:

� public static Connection getConnection (String dataSource)

Descripción: Devuelve una conexión del pool a partir del nombre del dataSource recibido como parámetro.

o String dataSource : DataSource que identifica al pool del cuál se obtendrá la coneción.

Resultado: Connection � Conexión a la Base de Datos.


� public static void closeAll (Connection con, Statemenr stmt, ResultSet rs)

Descripción: Cierra el resultset, el statement y la conexión pasados como parámetro.

o Connection con : Conexión a cerrar.

o Statement stmt : Statement a cerrar.

o ResultSet rs : ResultSet a cerrar.

Resultado: void �

� public static void closeAll (Connection con, PreparedStatemenr pstmt)

Descripción: Cierra la conexión y el preparedStatement pasados como parámetro.


o PreparedStatement pstmt : PreparedStatement a cerrar.

Resultado: void �

� public static void closeAll (Connection con, PreparedStatemenr pstmt, ResultSet rs)

Descripción: Cierra el resultset, el preparedStatement y la conexión pasados como parámetro.


o PreparedStatement pstmt : PreparedStatement a cerrar.

o ResultSet rs : ResultSet a cerrar.

Resultado: void �


5.3 Configuración:

No dispone de configuración propia, pero si existen una serie de normas a cumplir para homogeneizar los desarrollos contra la base de datos.

Para que el componente de Gestión de BD permita la obtención de conexiones del pool a partir de un datasource, es necesario que tanto el datasource como el pool de conexiones estén definidos en el servidor de aplicaciones.

Por razones de rendimiento es aconsejable disponer de un pool que contenga conexiones no transaccionales (para operaciones de consulta principalmente) y otro que contenga conexiones transaccionales.

Así mismo se dispondrá de datasources vinculados al pool de conexiones transaccional y no transaccional.

Además, en el archivo de configuración de la aplicación (/config/codApp/codApp.properties) deberán especificarse los dataSources.

ds.dataSourceXA= codApp. codAppDataSourceXA

ds.dataSourceNOXA= codApp.codAppDataSource

5.4 Ejemplo:

Ejemplo de obtención de una conexión no transaccional mediante la invocación al método correspondiente del componente Gestor de BD, pasándole como parámetro el nombre del datasource. Comentar que el ejemplo que parece a continuación sería el esqueleto estándar de cualquier objeto DAO padre que resida en el sistema NB29:

public class CodAppXXXDAO { private static T49ebLogger log = (T49ebLogger)T49e bLoggerFactory.getLogger( appName, CodAppXXXDAO.class); private String b29Seguridad =null; private String dataSource =null; /** * Constructor de la clase */ protected CodAppXXXDAO (String b29Seguridad, boole an trans) { this.b29Seguridad=b29Seguridad; try { this.dataSource=(trans)? T49ebConfig.getProperty( com.ejie.t49cb.constantes.T49cbConstantes.CONF IG_PATH, T49cbDaoConstantes.DATASOURCE_XA): T49ebConfig.getProperty( com.ejie.t49cb.constantes.T49cbConstantes.CONF IG_PATH, T49cbDaoConstantes.DATASOURCE_NOXA); if (this.dataSource == null){ //TRATAMIENTO DEL ERROR } } catch (T49ebUtilException e) { //TRATAMIENTO DE LA EXCEPTION


} } /** * Método que obtiene la conexion de base de datos */ protected Connection obtenerConexion() throws T49e bDAOException { try { return T49ebConectorJDBC.getConnection(this.data Source); }catch (SQLException e) { //TRATAMIENTO DEL ERROR } } /** * Método que obtiene información de la base de da tos */ public String obtenerDatos() throws T49ebDAOExcept ion { Connection con = this.obtenerConexion(); PreparedStatement pstmt = null; try { pstmt = con.prepareStatement(sql); pstmt.executeUpdate(); return T49ebConectorJDBC.getConnection(this.data Source); }catch (SQLException e) { //TRATAMIENTO DEL ERROR }finally { T49ebConectorJDBC.closeAll(con, pstmt); } }


6 GESTOR DE LOGS

6.1 Descripción.

T49ebLogger.java y T49ebLoggerFactory.java

Para la Gestión de las trazas de la aplicación, se utiliza la herramienta open source Log4j desarrolada bajo el proyecto Jakarta Apache.

Log4j consiste en un conjunto de APIs que permiten a los desarrolladores controlar la salida de sus mensajes y hacia donde son direccionados. Es completamente configurable en tiempo de ejecución utilizando archivos externos de configuración. Para obtener información detallada se puede consultar la dirección : http://logging.apache.org/log4j/docs/documentation.html

6.2 API:

T49ebLoggerFactory:

Factoría a partir de la que se obtienen las instancias de la clase Logger que gestiona las trazas.Tiene un hashmap en el que se almacenan las instancias asociadas a una determinada categoría. Esto permite la reutilización de una misma instancia de Logger para la escritura de las trazas de una misma categoría.

� public static Logger getLogger (String nombreAplicacion, Class clase)

Descripción: Devuelve la instancia de un Logger para una categoría determinada. Sólo hay una instancia de la clase Logger por categoría.

o String nombreAplicacion : Código de la aplicación.

o Class clase: Clase para la que se genera el Logger.

Resultado: Logger � El objeto Logger para la categoría.

Errores: Cuando se genera un error escribe una traza en la salida del servidor indicando que no está configurado el sistema de trazas.

T49ebLogger:

Clase (que extiende org.apache.log4j.Logger) que controla el log en el sistema.

� public boolean isEnabled ()

Descripción: Comprueba que el sistema de log esté habilitado para la categoría en curso.

Resultado: booelan � Indicando si el sistema de log está habilitado o no.

� public void debug (Object objMensaje)

Descripción: Escribe una traza de nivel DEBUG

o Object objMensaje: Mensaje a escribir.

Resultado: void�

� public void debug (String idUsuario, String idAplicacion, Object objMensaje)


Descripción: Escribe una traza de nivel DEBUG incluyendo el id de usuario y el id de la aplicación (codApp) que recibe como parámetros.

o String idUsuario: Identificador del usuario conectado.

o String idAplicacion: Código de Aplicación.


Resultado: void�

� public void debug (String b29Seguridad, Object objMensaje)

Descripción: Escribe una traza de nivel DEBUG, pero incluyendo datos de seguridad tales como el id de flujo de la operación que se está ejecutando, el identificador del usuario conectado y el código de la aplicación.

o String b29Seguridad: String xml con el objeto B29SeguridadET.


Resultado: void�

� public void info (Object objMensaje)

Descripción: Escribe una traza de nivel INFO


Resultado: void�

� public void info (String idUsuario, String idAplicacion, Object objMensaje)

Descripción: Escribe una traza de nivel INFO incluyendo el id de usuario y el id de la aplicación (codApp) que recibe como parámetros.




Resultado: void�

� public void info (String b29Seguridad, Object objMensaje)

Descripción: Escribe una traza de nivel INFO, pero incluyendo datos de seguridad tales como el id de flujo de la operación que se está ejecutando, el identificador del usuario conectado y el código de la aplicación.



Resultado: void�

� public void warn (Object objMensaje)

Descripción: Escribe una traza de nivel WARNING


Resultado: void�

� public void warn (String idUsuario, String idAplicacion, Object objMensaje)


Descripción: Escribe una traza de nivel WARNING incluyendo el id de usuario y el id de la aplicación (codApp) que recibe como parámetros.




Resultado: void�

� public void warn (String b29Seguridad, Object objMensaje)

Descripción: Escribe una traza de nivel WARNING, pero incluyendo datos de seguridad tales como el id de flujo de la operación que se está ejecutando, el identificador del usuario conectado y el código de la aplicación.



Resultado: void�

� public void error (Object objMensaje)

Descripción: Escribe una traza de nivel ERROR


Resultado: void�

� public void error (String idUsuario, String idAplicacion, Object objMensaje)

Descripción: Escribe una traza de nivel ERROR incluyendo el id de usuario y el id de la aplicación (codApp) que recibe como parámetros.




Resultado: void�

� public void error (String b29Seguridad, Object objMensaje)

Descripción: Escribe una traza de nivel ERROR, pero incluyendo datos de seguridad tales como el id de flujo de la operación que se está ejecutando, el identificador del usuario conectado y el código de la aplicación.



Resultado: void�

� public void fatal (Object objMensaje)

Descripción: Escribe una traza de nivel FATAL


Resultado: void�

� public void fatal (String idUsuario, String idAplicacion, Object objMensaje)


Descripción: Escribe una traza de nivel FATAL incluyendo el id de usuario y el id de la aplicación (codApp) que recibe como parámetros.




Resultado: void�

� public void fatal (String b29Seguridad, Object objMensaje)

Descripción: Escribe una traza de nivel FATAL, pero incluyendo datos de seguridad tales como el id de flujo de la operación que se está ejecutando, el identificador del usuario conectado y el código de la aplicación.



Resultado: void�

6.3 Configuración:

Aspectos a tener en cuenta a la hora de realizar la configuración del Sistema de Trazas para un código de aplicación (archivo logconfig.xml):

La configuracion consta de:

1. appenders (salida de trazas)

La salida de las trazas puede ser a un fichero (normal o rotatorio), a consola, tabla de base de datos, colas jms, etc.

En un principio utilizaremos el appender File, de tal forma que las trazas saldrán a un fichero.

Cada appender puede determinar un formato de mensaje de salida.

2. categorias (gestores de trazas) que utilizan diversos appenders.

Podemos determinar categorias asociadas a toda la aplicación o a modulos particulares hasta el nivel de jerarquía que se desee.

La característica additivity es un flag que determina si las trazas correspondientes a dicha categoría se dirigen a los appenders de las categorias padre, ademas de a su appender correspondiente.

Es decir, si se tiene una categoria llamada 't49eb' (toda la aplicacion) y otra llamada 't49eb.utils.negocio' con additivity="false", las trazas de t49eb.utils.negocio se dirigiran al appender declarado en el elemento category correspondiente.

Sin embargo, si additivity="true", se dirigiran a "t49eb" y a "t49eb.utils.negocio" (a ambas).

En principio, partiremos con una única categoria para la aplicacion, que llamaremos "t49eb".

Si se desea añadir una categoria, bastara que copie el tag 'category',cambiando el nombre de la categoria (usar SIEMPRE el de la jerarquía de paquetes JAVA, t49eb.mnnnNombre(.paquete.clase), y se puede determinar hasta el nombre de la clase, si se desea).

Ejemplo de fichero de configuración para la Gestión de trazas de una aplicación.


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.ap ache.org/log4j/">

<appender name="Fichero" class="org.apache.log4j.F ileAppender">

<param name="File" value="/datos/codApp/trazas_co dApputils.log"/>

<param name="Append" value="false"/>

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern" value="%t %-5p % c{2} - %m%n"/>

</layout>

</appender>

<appender name="FicheroRolling" class="org.apache. log4j.RollingFileAppender">

<param name="File" value="/datos/codApp/trazas_co dApputils.log"/>

<param name="Append" value="true"/>

<param name="MaxFileSize" value="2kb"/>

<param name="MaxBackupIndex" value="10"/>


<param name="ConversionPattern" value="%t %c{2} - %m%n"/>

</layout>

</appender>

<appender name="Consola" class="org.apache.log4j.C onsoleAppender">


<param name="ConversionPattern" value="%d %-5p [ %t] %C{2} (%F:%L) - %m%n"/>

</layout>

</appender>

<category name="codApp" additivity="false">

<priority value="info"/>

<appender-ref ref="FicheroRolling"/>

</category>

<category name="com.ejie.test.junit " additivity=" false">

<priority value="debug"/>

<appender-ref ref="FicheroRolling"/>

</category>

</log4j:configuration>


Niveles de prioridad

Log4J tiene por defecto 5 niveles de prioridad para los mensajes de logs:

� DEBUG: Se utiliza para escribir mensajes de depuración, este log no debe estar activado cuando la aplicación se encuentre en producción.

� INFO: Se utiliza para mensajes similares al modo "verbose" en otras aplicaciones. � WARN: Se utiliza para mensajes de alerta sobre eventos que se desea mantener constancia, pero que

no afectan el correcto funcionamiento del programa. � ERROR: Se utiliza en mensajes de error de la aplicación que se desea guardar, estos eventos afectan al

programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.

� FATAL : Se utiliza para mensajes críticos del sistema, generalmente luego de guardar el mensaje el programa abortará.

Adicionalmente a estos niveles de log, existen 2 niveles extras que solo se utilizan en el archivo de configuración, estos son:

� ALL : este es el nivel más bajo posible, habilita todos los logs. � OFF: este es el nivel más alto posible, deshabilita todos los logs.

Cada uno de los métodos está sobrecargado dos veces en el objeto T49ebLogger, de forma que se tienen tres métodos para cada nivel de trazado, con la siguiente signatura (se toma como ejemplo debug):

a) public void debug(Object objMensaje)

b) public void debug(String idUsuario,String idAplicac ion,Object objMensaje)

c) public void debug(String t49ebSeguridad, Object obj Mensaje){

6.4 Ejemplo:

Forma de utilizar el Gestor de Logs en la aplicación. En el código java se realizarán llamadas al sistema de trazas de la siguiente forma:

1. Se obtendrá una instancia de T49ebLogger haciendo uso de la factoría.

private T49ebLogger log = (T49ebLogger)T49ebLoggerF actory.getLogger ( "codApp", this.getClass());

2. Se llama al método correspondiente de T49ebLogger en función del nivel de traza que se quiera sacar (debug,info,warn,error,fatal).

if (log.isInfoEnabled ())

log.info(this._b29Seguridad, "Carga inicial Interm ediario de negocio.");

NOTA: Es necesario incluir siempre la condición antes de invocar al sistema de trazas, para evitar la evaluación de la expresión que conforma el mensaje en caso de que estén deshabilitadas.


7 USO Y GESTIÓN DE CACHÉS

7.1 Descripción.

T49ebCache.java:

Clase java que permite gestionar el acceso a las cachés definidas en la aplicación y a los elementos almacenados en las mismas. Hace uso de la utilidad de caché JCS de Jakarta. http://jakarta.apache.org/jcs/index.html

Texto recogido de apache:

JCS es un sistema de caché distribuido para aplicaciones JAVA. La intención de la aplicación es la de aumentar el rendimiento de las aplicaciones aportando diferentes soluciones para manejar información cacheada. Como todos los servicios de caché es muy útil para aplicaciones con un alto incide de lectura y bajo índice de modificación.

Antes de empezar a usar JCS es necesario entender una serie de conceptos básicos. Las diferencias entre “elementos”, “regiones” y “auxiliares”.

JCS es una caché sobre la que se pueden meter o sacar objetos o “elementos ”. Los elementos son referenciados a través de un ID, el funcionamiento es muy parecido al de una Hashtable.

Se puede pensar en JCS como una colección de Hashtables a las que se puede referenciar a cada una de ellas a través de un nombre. Cada hashtable de la colección se le denomina “región ”. Cada región tiene una configuración independiente de las demás.

Los “auxiliaries ” son añadidos opcionales los cuales pueden ser usados por una región:

- Caché indexada en disco.

- Caché TCP Lateral.

- Servidor de Caché Remoto.

Los servicios sobre los que sea interesante configurar “regiones” de caché lo han de decidir los diseñadores técnicos, así como de la configuración los “auxiliares”.

Tipos de caché: El uso de caché es muy recomendable en aquellos servicios cuyos resultados sean poco variables y muy consultados para lectura.

- Memoria (): Elementos poco o nada volátiles y cuya cantidad no sea muy elevada por región y el tamaño de cada elemento no sea superior a 1K.

- Disco (DC): Elementos poco volátiles y cuya recuperación sea costosa en tiempo (10 segundos o más) y la cantidad de elementos sea elevada (superior a 1k e inferior a 5k por elemento).

- Bases de datos (ORACLE): Elementos poco volátiles y cuya recuperación sea costosa en tiempo (10 segundos o más) y la cantidad de elementos sea elevada (superior a 5ks).

- Caché remota: (Desestimada ): Se recomienda su uso para elementos cacheables los cuales puedan ser modificados en fuentes distribuidas. Por ejemplo: Platea y NB29 podrían compartir una caché remota donde todos los datos de los expedientes residieran de forma desnormalizada, de forma que los consumidores recuperasen la información de esta caché distribuida y la modificadores de información pudieran actualizar sus sistemas y las cachés distribuidas. Por el momento su uso est.

Generalmente en la NB29 se utilizan siempre cachés en memoria .


7.2 API:

� public static JCS getCache (String appName, String region)

Descripción: Recupera el elemento JCS (caché) asociado a la aplicación y a la región recibidos como parámetros.


o String region : Nombre de la región de la caché definida para esa aplicación.

Resultado: JCS � Objeto que contiene los valores de dicha región de caché. Si no existe la región o la caché, devolverá null.

Errores: Si se produce algún error al recuperar la información solicitada, devolverá como parámetro de retorno un null.

Especificación de los métodos del objeto JCS:

� public Object get (Object name)

Descripción: Recupera el objeto especificado de la región de caché a la que hace referencia la instancia JCS (caché).

o Object name : Nombre del objeto a recuperar.

Resultado: Object � Objeto recuperado. Si no existe, devolverá null.

Errores: Si se produce algún error al recuperar la información solicitada, devolverá como parámetro de retorno un null.

� public void put (Object name, Object obj)

Descripción: Almacena el objeto especificado en la región de caché a la que hace referencia la instacia JCS (caché). Si ya existiera un objeto con el mismo nombre, será reemplazado.

o Object name : Nombre identificativo del objeto a almacenar.

o Object obj : Objeto que se desea almacenar.

Resultado: void�

Errores: Si se produce algún error al recuperar la información solicitada, se lanzará una excepción de tipo CacheException.

7.3 Configuración:

Todas aquellas aplicaciones que vayan a hacer uso de cachés deberán generar el archivo cache.ccf y almacenarlo en la carpeta /config/ de su código de aplicación:

/config/codApp/cache.ccf

Un ejemplo de este archivo es el siguiente:


################################################### ###########

################## REGIONES ####################### ###########

# REGION: CATMAESTROS

jcs.region.catMaestrosCache=

jcs.region.catMaestrosCache.cacheattributes=org.apa che.jcs.engine.CompositeCacheAttributes

jcs.region.catMaestrosCache.cacheattributes.MaxObje cts=100

jcs.region.catMaestrosCache.cacheattributes.MemoryC acheName=org.apache.jcs.engine.memory.lru.LRUMemory Cache

jcs.region.catMaestrosCache.cacheattributes.UseMemo ryShrinker=false

jcs.region.catMaestrosCache.elementattributes=org.a pache.jcs.engine.ElementAttributes

jcs.region.catMaestrosCache.elementattributes.IsEte rnal=false

jcs.region.catMaestrosCache.elementattributes.MaxLi feSeconds=86400

# REGION: FAMILIAS

jcs.region.familias=

jcs.region.familias.cacheattributes=org.apache.jcs. engine.CompositeCacheAttributes

jcs.region.familias.cacheattributes.MaxObjects=10

jcs.region.familias.cacheattributes.MemoryCacheName =org.apache.jcs.engine.memory.lru.LRUMemoryCache

jcs.region.familias.cacheattributes.UseMemoryShrink er=true

jcs.region.familias.elementattributes=org.apache.jc s.engine.ElementAttributes

jcs.region.familias.elementattributes.IsEternal=fal se

jcs.region.familias.elementattributes.MaxLifeSecond s=86400

# REGION: TOKEN DE APLICACION

jcs.region.seguridadEavAdapter=

jcs.region.seguridadEavAdapter.cacheattributes=org. apache.jcs.engine.CompositeCacheAttributes

jcs.region.seguridadEavAdapter.cacheattributes.MaxO bjects=2

jcs.region.seguridadEavAdapter.cacheattributes.Memo ryCacheName=org.apache.jcs.engine.memory.lru.LRUMem oryCache

jcs.region.seguridadEavAdapter.cacheattributes.UseM emoryShrinker=false

jcs.region.seguridadEavAdapter.elementattributes=or g.apache.jcs.engine.ElementAttributes

jcs.region.seguridadEavAdapter.elementattributes.Is Eternal=false

jcs.region.seguridadEavAdapter.elementattributes.Ma xLifeSeconds=180

################################################### ###########

################## AUXILIARY ###################### ###########

# DISK CACHE

jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.inde xed.IndexedDiskCacheFactory

jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliar y.disk.indexed.IndexedDiskCacheAttributes

jcs.auxiliary.DC.attributes.DiskPath=D:/TMP/cache


jcs.auxiliary.DC.attributes.MaxPurgatorySize=100000 00

jcs.auxiliary.DC.attributes.MaxKeySize=1000000

jcs.auxiliary.DC.attributes.MaxRecycleBinSize=5000

jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=3 00000

jcs.auxiliary.DC.attributes.ShutdownSpoolTimeLimit= 60

# ORACLE disk cache used for flight options

jcs.auxiliary.ORACLE=com.ejie.t49eb.utils.cache.aux iliary.disk.jdbc.T49ebJDBCDiskCacheFactory

jcs.auxiliary.ORACLE.attributes=org.apache.jcs.auxi liary.disk.jdbc.JDBCDiskCacheAttributes

jcs.auxiliary.ORACLE.attributes.database=t50ab.t50a bDataSource

jcs.auxiliary.ORACLE.attributes.tableName=T50ABEVT0 0

jcs.auxiliary.ORACLE.attributes.testBeforeInsert=fa lse

jcs.auxiliary.ORACLE.attributes.MaxPurgatorySize=50 000

jcs.auxiliary.ORACLE.attributes.allowRemoveAll=true

jcs.auxiliary.ORACLE.attributes.UseDiskShrinker=tru e

jcs.auxiliary.ORACLE.attributes.ShrinkerIntervalSec onds=86400

7.3.1. Regiones:

Regiones:

jcs.region.nombreRegion=AUXILIARES QUE PUEDE USAR. Si no se pone nada usa caché en memoria.

Regiones: Propiedades de la región: cacheattributes

Propiedad Descripción Req Defecto

MaxObjects Máximo número de elementos permitidos en memoria. Por defecto se usa memoria LRU.

SI n/a

MemoryCacheName Especifica el gestor de memoria que se quiere usar. N org.apache.

jcs.engine.

memory.lru.

LRUMemory

Cache

UseMemoryShrinker Es un elemento de la caché encargado de ir revisando en caché los elementos que han expirado su máximo tiempo de vida para eliminarlos de caché.

N false


MaxMemoryIdle

TimeSeconds

Solo se usa en caso de que se esté usando un shrinker . Si un elemento no ha sido accedido en el número de segundo indicado en la propiedad el elemento será enviado al auxiliar, si es que está accesible.

N -1

ShrinkerIntervalSeconds Solo se usa en caso de que se esté usando un shrinker . Esta opción de configuración indica la frecuencia con que el shrinker tiene que ejecutarse.

N 60

MaxSpoolPerRun Solo se usa en caso de que se esté usando un shrinker . Máximo número de elementos que pueden ser enviados al auxiliar por cada vez que se ejecuta el shrinker.

Regiones: Propiedades de los elementos: elementattr ibutes

Propiedad Descripción. Req PorDef

IsEternal Si un elemento está definido como eterno, nunca será eliminado al superar el tiempo máximo de vida del elemento. (MaxLifeSeconds)

N true

MaxLifeSeconds Si se especifica que los elementos de esta región no son eternos, se puede decidir el tiempo máximo de vida que se asocia a los elementos. Cuando se excede el tiempo indicado en esta propiedad se retira el elemento de la caché de forma pasiva (cuando el usuario intenta retirar el elemento de la caché). Si se ha configurado un shrinker los elementos pueden ser borrados de forma active.

N -1

7.3.2. Auxiliares:

7.3.2.1. ORACLE:

Propiedad Descripción. Req PorDef

MaxPurgatorySize El número máximo de elementos permitidos en la cola de elementos destinados a ser escritos en el auxiliar.

N 5000

database JNDI del datasource de la base de datos. SI

tablename Nombre de la tabla donde se escriben los elementos de caché.

SI


testBeforeInsert Si está a verdadero se realiza una comprobación en la base de datos para comprobar si un elemento ya existe por lo que en caso de existir lo actualizará. Se recomienda tener esta opción siempre a verdadero.

SI true

allowRemoveAll Esta opción tiene que ponerse siempre a false. Para evitar posibles borrados de la base de datos descontrolados.

SI false

UseDiskShrinker Elemento que permite eliminar los objetos obsoletos de la caché.

N True

ShrinkerIntervalSeconds Cada cuantos segundos tiempo tiene que lanzarse el Shrinker

N 300

7.4 Ejemplo de uso:

import com.ejie.b29.utils.cache.B29Cache; import org.apache.jcs.JCS; import org.apache.jcs.access.exception.CacheExcepti on; … JCS cacheMaestros = T49ebCache.getCache(" codApp",“catMaestrosCache”); //Recupera de la aplicación codApp la configuración de la región de nombre “catMaestrosCache” del fichero cache.ccf try { jcs.put(key, element); //inserta un ele mento en caché element = (String)jcs.get(key); //recup era un elemento de la caché }catch (CacheException e) { e.printStackTrace(); }


8 CAMPOS LOB DE BASE DE DATOS

8.1 Descripción.

T49ebBlob.java y T49ebClob.java:

Clases java de la arquitectura que nos permiten gestionar los campos de tipo CLOB y BLOB que tengamos en el modelo de datos de las aplicaciones.

8.2 API.

T49ebBlob.java:

� public T49ebBlob (String b29Seguridad,Connection con)

Descripción: Constructor de la clase.

o String b29Seguridad: Objeto de seguridad de la arquitectura.

o Connection con : Conexión a la base de datos..

� public void insertarBLOB (String blobNombreColumna, File blobValorColumna, String nombreTabla, String nombreCampoId, String valorCampoId)

Descripción: Inserta el fichero representado por el objeto File en el campo de la base de datos del registro correspondiente.

o String blobNombreColumna : Nombre del campo BLOB.

o File blobValorCoumna : Objeto File con el archivo a almacenar.

o String nombreTabla : Nombre de la tabla a la que pertenece el campo.

o String nombreCampoId : Nombre del campo Id.

o String valorCampoId : Valor del campo Id.

Resultado: void �

Errores: Si se produce algún error al transformar la fecha lanzará una excepción de tipo T49ebUtilException .

� public void insertarBLOB (String blobNombreColumna, String blobValorColumna, String nombreTabla, HashMap camposPK)

Descripción: Inserta un String en el campo de la base de datos del registro correspondiente.


o String blobValorCoumna : String con el contenido a almacenar.


o HashMap camposPK : Hash con los nombres y valores de los campos que representan la primary key del registro.

Resultado: void �



� public void insertarBLOB (String blobNombreColumna, byte[] blobValorColumna, String nombreTabla, HashMap camposPK)

Descripción: Inserta un String en el campo de la base de datos del registro correspondiente.


o byte[] blobValorCoumna : Array de bytes a almacenar.


o HashMap camposPK : Hash con los nombres y valores de los campos que representan la primary key del registro.

Resultado: void �


� public byte[] recuperarBLOBBytes (String blobNombreColumna, String nombreTabla, String nombreCampoId, String valorCampoId)

Descripción: Recupera el contenido de un campo BLOB de base de datos en un array de bytes.




o String valorCampoId : Valordel campo Id.

Resultado: byte[] � Array de bytes con el contenido del campo BLOB.


� public byte[] recuperarBLOBBytes (String blobNombreColumna, String nombreTabla, HashMap camposPK)

Descripción: Recupera el contenido de un campo BLOB de base de datos en un array de bytes.



o HashMap camposPK : HashMap con los nombres y valores que representan la primary key del registro.

Resultado: byte[] � Array de bytes con el contenido del campo BLOB.


� public static String convertirBlobToString (java.sql.Blob blob)

Descripción: Convierte el contenido del resultado de un campo BLOB en un String

o java.sql.Blob blob : Objeto que representa el campo de BD (rs.getBlob()).


Resultado: String � El contenido del campo.


� public static byte[] convertirBlobToByteArray (java.sql.Blob blob)

Descripción: Convierte el contenido del resultado de un campo BLOB en un array de bytes

o java.sql.Blob blob : Objeto que representa el campo de BD (rs.getBlob()).

Resultado: byte[] � El contenido del campo.


T49ebClob.java:

� public T49ebClob (String b29Seguridad,Connection con)

Descripción: Constructor de la clase.

o String b29Seguridad: Objeto de seguridad de la arquitectura.

o Connection con : Conexión a la base de datos..

� public void insertarCLOB (String clobNombreColumna, String clobValorColumna, String nombreTabla, String nombreCampoId, String valorCampoId)

Descripción: Recupera el contenido de un campo CLOB de base de datos en un array de bytes.

o String clobNombreColumna : Nombre del campo CLOB.

o String clobValorColumna : Valor a insertar en el campo CLOB.



o String valorCampoId : Valordel campo Id.

Resultado: void �


� public void insertarCLOB (String clobNombreColumna, String clobValorColumna, String nombreTabla, HashMap camposPK)

Descripción: Recupera el contenido de un campo CLOB de base de datos en un array de bytes.

o String clobNombreColumna : Nombre del campo CLOB.

o String clobValorColumna : Valor a insertar en el campo CLOB.


o HashMap camposPK : Hashmap con los nombres y valores que representan la PK..

Resultado: void �



� public static String clobToString (java.sql.Clob clob)

Descripción: Convierte el contenido del resultado de un campo CLOB en un String

o java.sql.Clob clob : Objeto que representa el campo de BD (rs.getClob()).

Resultado: String � El contenido del campo.



9 FECHAS

9.1 Descripción.

T49ebFecha:

Los datos que hacen referencia a las fechas en la arquitectura del SGI tienen una característica particular. Cómo regla general, en todos los campos de las entidades de transferencia que hacen referencia a una fecha, ésta estará representada como un timestamp (long), que hace referencia a los milisegundos transcurridos desde el 1 de Enero de 1970. Esto facilita el transporte del dato entre todas las capas de la arquitectura, la ordenación y cálculos de diferencias entre fechas y la representación de la misma fecha en diferentes formatos. En base de datos, estas fechas estarán almacenadas siempre en campos de tipo DATE.

Para poder tratar y gestionar este tipo de campos, la arquitectura aporta una clase que nos permite transformar las fechas al formato timestamp, o viceversa, transformar una fecha recuperada de la base de datos para presentarla en pantalla con la máscara que más se ajuste a las necesidades.

NOTA: Por regla general, en la capa de presentación, las fechas siempre estarán representadas con el mismo formato:

YYYY/MM/DD HH:MM:SS 2009/04/22 16:31:11

9.2 API:

� public static String parseToFechaFormateada (long timestamp, String mascara)

Descripción: Transforma un objecto long (timeStamp) que representa una fecha a la máscara de formato de fecha que reciba.

o long timeStamp : Long con la fecha.

o String mascara : Máscara de representación de la fecha (P.ej.: dd/MM/yyyy).

Resultado: String � La fecha formateada (P.ej.: 22/05/2009).

Errores: Si se produce algún error al transformar la fecha lanzará una excepción de tipo java.text.ParseException .

2009/04/22

CAMPO DATE

ET

19562135454000

ET

19562135454000


� public static String parseToTimeStamp (String fecha, String format)

Descripción: Transforma una fecha formateada en un objeto long (timestamp) que devuelve como un String.

o String fecha : Fecha que se quiere transformar.

o String mascara : Máscara con la que está representada la fecha.

Resultado: String � La fecha en formato timestamp.


� public static String parseToFechaFormateada (String timeStamp, String format)

Descripción: Transforma un objecto String (long) que representa una fecha a la máscara de formato de fecha que reciba.

o String timeStamp : Long con la fecha en formato String.

o String format : Máscara de representación de la fecha.

Resultado: String � La fecha formateada.


� public static String parseToFechaFormateadaBD (String timeStamp)

Descripción: Transforma un objecto String (long) que representa una fecha al String correspondiente para hacer uso del mismo en queries contra la base de datos.

o String timeStamp : Long con la fecha en formato String.

Resultado: String � La fecha formateada para una query (P.Ej.: TO_DATE ('16/11/2006 09:01:41', 'DD/MM/YYYY HH24:MI:SS')).


� public static String parseToFechaFormateadaBD (long timeStamp)

Descripción: Transforma un objecto long que representa una fecha al String correspondiente para hacer uso del mismo en queries contra la base de datos.

o log timeStamp : Fecha.

Resultado: String � La fecha formateada para una query (P.Ej.: TO_DATE ('16/11/2006 09:01:41', 'DD/MM/YYYY HH24:MI:SS')).


� public static String parseToTimeStampBD (java.aql.Timestamp timeStamp)

Descripción: Transforma un objecto TimeStamp recuperado de la base de datos (rs.getTimestamp()) en un String que representa la fecha en milisegundos.

o java.sql.Timestamp timeStamp : Fecha recuperada de la BD.

Resultado: String � La fecha recuperada en milisegundos.



� public static String parseToLongTimeStampBD (java.aql.Timestamp timeStamp)

Descripción: Transforma un objecto TimeStamp recuperado de la base de datos (rs.getTimestamp()) en un long que representa la fecha en milisegundos.

o java.sql.Timestamp timeStamp : Fecha recuperada de la BD.

Resultado: long � La fecha recuperada en milisegundos.


9.3 Configuración

No tiene ninguna configuración asociada.

9.4 Ejemplo de uso:

//AL CREAR UNA INSERT try {

pstmt.setTimestamp("CAMPO_BD", new Timestamp(Long.p arseLong(cabeceraET.getFechaInicio()))); } catch( NumberFormatException e ) { //Tratamiento de error… }


10 CONSTANTES COMUNES

T49ebConstantes:

En la clase T49ebConstantes están representadas todas aquellas constantes comunes a todas las aplicaciones del SGI. Dentro de la clase, estás constantes están agrupadas en tipologías. La lista de constantes reales puede verse en el javadoc de la aplicación. A continuación, se detalla la lista de tipos de constantes que existen:

• AccionesTelematicas: Identificadores de las distintas acciones telemáticas que existen en Platea para cada procedimiento.

• FormatoFechas: Diferentes formatos de fechas. Se utiliza para el parseo de las mismas.

• DireccionUbicacion: Constantes referidas a las direcciones y las ubicaciones

o TipoDireccion: Diferentes tipos de dirección (estatal, extranjera).

o Provincias: Códigos de las provincias del CAPV.

o TiposUbicacion: Diferentes tipos de ubicaciones (urbana…).

• Expedientes: Diferentes grupos de constantes relacionadas con los expedientes de industria.

o FlagsExpedientes: Lista de flags utilizados para la búsqueda de expedientes y sus datos.

o OrigenExpediente: Constantes referidas al origen de un expediente (presencial…)

o TiposInicio: Diferentes tipos de inicio de un expediente en el sistema de industria.

o TipoTramitacion: Identificadores de los tipos de tramitación del expediente.

o TiposHito: Constantes con el nemotécnico de los hitos de un expediente

• Documentos: Diferentes categorías de constantes referidas a los documentos

o FlagsDocusVisados: Lista de flags para la búsqueda de documentos visados en la zona de precarga.

o NaturalezaDocumento: Constantes con los valores de la naturaleza de un documento (papel, electrónico)

o OrigenDokusi: Diferentes orígenes de los documentos que se almacenan en el sistema de Dokusi.

o TiposDocumentos : Procedencia de los documentos de industria (entrada, salida)

o GeneracionPdf: Constantes necesarias para la generación de pdfs

• TareasTramites: Constantes referidas a los trámites y tareas de un expediente subdivido en categorías.

o EstadosTareas: Valores de los estados en el que puede estar una tarea en el expediente.

o TipologiasMensajesBuzon: Diferentes categorías de los tipos de tarea

o TiposTareasIndustria: Tipos de tarea que existen en la tramitación de un expediente en el departamento de industria.

o TareasHito: Diferentes tipos de las tareas-hito


o FlagsTareas: Lista de flags para obtener la información relacionada con los trámites y tareas del expediente.

o TiposTramites: Tipos de trámite que pueden encontrarse en un expediente.

• Procedimientos: Grupo de constantes relacionadas con los procedimientos.

o FlagsProcedimientos: Lista de flags necesaria para obtener información de los procedimientos.

o EstadosProcedimiento: Diferentes estados en el que puede estar un procedimiento

• EstadosEntradasConsolidar: Estados en los que se puede quedar una entrada presencial

• EstadosSalidasConsolidar: Estados en los que se puede quedar una salida

• TipoEnvio: Diferentes valores para los tipos de envío (comunicación, notificación)

• EstadosCenso: Estados en los que se puede encontrar un censo

• TiposSalida: Diferentes valores para la comunicación con el usuario (postal, telemática)

• Secciones: Constantes comunes a todas las secciones del sistema de industria.

o FlagsSecciones: Lista de flags para buscar información en las secciones

o MetodosSecciones: Nombre de los métodos comunes de las secciones

• Autorizaciones: Constantes referidas a las autorizaciones

o FlagsAutorizaciones: Lista de flags para la búsqueda de información en el sistema de autorizaciones.

o AccionesAutorizaciones: Diferentes acciones que puede tener una autorización

• Solicitudes: Constantes referidas a las solicitudes telemáticas

o FlagsSolicitudes: Lista de flags para la búsqueda de solicitudes telemáticas

o TiposPasos: Tipos de paso que pueden encontrarse en las solicitudes telemáticas

• FlagsBandejas: Lista de flags para la búsqueda en el sistema de bandejas

• NivelAlerta: Niveles de alerta necesario para el monitor de sistema

• TiposDatosWS: Tipos de los datos en las llamadas a los web service

• Terceros: Constantes referidas a información de los terceros

o TiposDocumentosIdentificativos: Diferentes tipos de documentos identificativos de los terceros

o TipoPersona: Identificadores de los tipos de persona (física, jurídica…)

• TiposAviso: Tipos de los avisos y alarmas

• TiposCertificados: Tipos de certificados de tarjetas admitidos en el sistema de industria

• ConstantesComunes: Constantes comunes al sistema de industria


11 OTRAS UTILIDADES

Lista de clases comunes de la aplicación T49eb. Para más información sobre los métodos y su uso, ver el javadoc del API.

NOMBRE CLASE DESCRIPCIÓN

T49ebBase64 Clase que para el tratamiento de codificación y decodificación en BASE64. Utilizada en procesos de firma y en entidades que transportan documentos.

T49ebBoolean Clase que nos permite tratar los datos de tipo Boolean y la base de datos.

T49ebDireccionCTUtils Clase de utilidades para obtener los valores de la entidad de transferencia de DireccionCT

T49ebEjgvDocument Clase para obtener información del EjgvDocument

T49ebFirmaUtils Clase con utilidades para el tratamiento de datos de firmas electrónicas-

T49ebConvertirHTML Clase que dado un xml y un xsl, lo convierte en HTML.

T49ebComparador Clase que se encarga de comparar dos objetos.

T49ebOrdenacion Clase que se encarga de ordenar un objeto por un campo seleccionado.

T49ebUtils Utilidades genéricas comunes a todas las aplicaciones.

T49ebValidar Clase con utilidades para validar ciertos datos como email, dni…

T49ebMensajeCTUtils Utilidades para tratar la información de la entidad de transferencia MensajeCT.

nb29 dsi arq nor manual de utilidades de la … · que la arquitectura diseñada para el proyecto...

Documents