i

Please enable JavaScript to view this site.

Una vez finalizado el proceso de actualización pueden ocurrir 3 situaciones:

 

Ejecución correcta.

Ejecución cancelada durante la validación.

Ejecución cancelada durante la actualización.

 

 

Ejecución Correcta

 

Cuando la actualización llega a una ejecución correcta, se podrá observar un archivo de log similar al siguiente ejemplo:

 

Chequeando si el sistema está detenido

Accede a http://127.0.0.1:8076/Deyel400ES/services

java.net.ConnectException: Connection refused

No pudo conectarse. Se asume que el sistema está detenido

 

************************************************************

*      Validación del contenido del archivo de entrada     *

************************************************************

 

Validando directorio 001.files...

Se ha validado correctamente el directorio 001.files

 

************************************************************

*      Validación del archivo de entrada finalizada        *

************************************************************

 

************************************************************

*                   Inicio de la actualización             *

************************************************************

 

Aplicando directorio 001.files...

Se ha aplicado correctamente el directorio 001.files

 

************************************************************

*             Actualización finalizada con éxito           *

************************************************************

 

El archivo de entrada y este mismo archivo de log encuentran en :

/apps/test/webapps/Deyel400ES/systemUpdates/20141007103705415

 

 

Entonces, se copia al ambiente de instalación la información necesaria como para mantener un historial de los cambios realizados. Se utiliza para ello una carpeta dentro del contexto de la aplicación, denominada systemUpdates. Dentro de esta carpeta se creará una nueva cuyo nombre será la fecha y hora de ejecución, y que contendrá al menos dos archivos:

 

Un archivo “INPUT_<archivo de entrada>” donde <archivo de entrada> es el archivo utilizado como entrada para la actualización.

Un archivo “OUTPUT_LOG.txt” que es una copia del archivo de log generado durante la ejecución.

 

Opcionalmente podrá existir un tercer elemento que será un directorio llamado generatedFiles el cual contendrá los archivos adicionales que generó el proceso de actualización.

 

 

Ejecución cancelada durante la validación

 

Si la ejecución canceló durante la validación del archivo de entrada,  se podrá ver un mensaje como el siguiente:

 

 Falló la validación. Verifique los <!> en el archivo de salida ubicado en…

 

Si esto sucede no se habrán realizado cambios en el sistema ya que el proceso encontró algún error que pudo ser validado antes de realizar cualquier acción y así evitar errores posteriores.
 

Deberá buscar las apariciones de <!> en el archivo de log (update_output_<timestamp>.txt) para poder encontrar los problemas, solucionar los mismos en el archivo de entrada y reintentar la actualización.

 

 

Ejecución cancelada durante la actualización

 

Esta situación puede deberse a un error no contemplado ya que una vez superada la etapa de validación sería poco común llegar a este estado. Pero igualmente se tiene en cuenta esta posibilidad.

Cuando esto ocurre se podrá ver en el log (update_output_<timestamp>.txt ) un mensaje como el siguiente:

 

**********************************************************

*            Actualización abortada por errores          *

**********************************************************

 

Luego del cual se podrá ver cual fue el último elemento del ZIP de entrada aplicado con éxito y cual fue el que falló.

En el momento de la falla se interrumpe la actualización.  

 

Todos los cambios que se aplicaron exitosamente antes de ocurrir el error se mantienen en el sistema.

El archivo que provocó el error y los subsiguientes no son procesados.

 

La razón de esto es porque hay operaciones de actualización que no pueden ejecutarse de forma transaccional (copia de archivos, sentencias SQL que modifican esquemas, etc) entonces se establece que cuando una actualización logra ejecutar parcialmente, esos cambios quedan en el sistema. Luego será necesario generar un nuevo archivo de entrada, que contenga los archivos que no se lograron aplicar en el primer intento.

 

 

 

Envianos tu comentario
Compartir en Twitter Compartir en Linkedin Enviar por Email Imprimir