Técnicas de Test Extremo a la vieja usanza….

Dentro del ámbito industrial/empresarial el uso de dispositivos móviles o PDA requieren de unos requisitos que por naturaleza no llegan, ni de largo, los típicos dispositivos que llevamos, hoy en dia, en nuestro bolsillos, en términos de duración de bateria, soporte contra caídas, lluvia o ambientes “sucios” de partículas.


Los dispositivos rugerizados se catalogan mediante el estándard IP (Ingress Protection) el cual:




  • evalúa de un 0 a un 6 el soporte a la dispersión de partículas sólidas (aka polvo), siendo 0 algo así como No Protección y 6 Dust Tight, el cual certifica que un dispositivo puede trabajar en ambientes muy cargados de partículas.


  • por otro lado, evalúa de un 0 a un 8 el soporte de agua, siendo 0 No Protección y 8 Protección a Inmersión completa. 

Para las PDAs industriales la típica certificación es IP54 o IP64, la cual permite la protección contra el polvo y las salpicaduras de agua. Además, estos dispositivos soportan la caída sobre hormigón desde 1,20 metros.


Por lo visto, además de la terminología y estandarización – hay más -, las pruebas que realizan los fabricantes están basadas en los principios de Pirron, al estilo empírico extremo, y si no mirad el siguiente video sobre el motorola (Symbol) MC9090 que he encontrado, (puestos a filosofar), causalmente.


 

Usando ActiveSync (& WDC) con Certificados de Seguridad de Exchange

Conectando con un emulador y configurarlo con Exchange a través de ActiveSync


Si configuramos un emulador de Windows Mobile 6 para conectarlo a través de ActiveSync (o Windows Device Center) a un servidor Microsoft Exchange, los típicos pasos a seguir serían:


1.       Abrir/Conectar Device Emulator Manager con el emulador deseado.


2.       Configurar ActiveSync o WDC para aceptar conexiones DMA.


3.       “Colocar en la base” [AKA Cradle] el emulador a través del Device Emulator Manager.


4.       En el asistente de configuración de la conexión, cuando nos pide la información de conectividad con Exchange indicar:


a.       Nombre del servidor Exchange en FQDN. (p.e. servidorEXCH.midominio.com)


b.      Uso de SSL


c.       Nombre de usuario/contraseña válida para el dominio activo.


d.      Elementos a sincronizar (correo, contactos, tareas…)


5.       Una vez configurado, si ante la primera sincronización obtenemos el siguiente error:



6.       Nos dirigimos al emulador, y en la información de estado (status) de ActiveSync de la última sincronización veremos el código de error en “View support code” dónde encontraremos el código de error exacto. En el caso que el error haga referencia a la ausencia de un certificado, el código será: 0x80072F17 cuya descripción es:
Unspported Digital Certificate installed. If you installed a digital certificate that supports wildcards from a certifying digital certificate provider, this certificate will install however using the certificate is not supported.

a.       NOTA: Otro tipo de error muy común en entornos corporativos (Sobre todo con ISA Server) es el 0x85010008:
Proxy authentication is required for HTTP communication or protocol to proceed.
En este caso se debe configurar el proxy a través de Configuration/ Connections / Proxy / HTTP -> Menu / Edit y probar hacer un ping al servidor en cuestión. (Para hacer un ping desde WinMobile utilizar la utilidad de
Alejandro Mezcua para hacer un ping desde .NET Compact Framework)


7.       Para solucionar el error del punto 6, deberemos crearnos un certificado digital, instalarlo en el emulador.


Creando certificados digitales en xml para Windows Mobile 5.0 y superior



SSLChainSaver 2.0 es una herramienta creada por Scott Yost, cuyo objetivo es el de diagnosticar y/o reparar problemas de conectividad vía SSL desde Windows Mobile.


Una vez nos descargamos SSLChainSaver y la instalamos, encontraremos el ejecutable SSLChainSaver.exe en C:Program FilesMicrosoft SSL ChainSaver, por defecto.


1-      Abrimos una sesión con la línea de comandos.


2-      Nos ubicamos en el path target: C:Program FilesMicrosoft SSL ChainSaver


3-      Ejecutamos lo siguiente:
C:Program FilesMicrosoft SSL ChainSaver>sslchainsaver mail.company.com




4-      Importante en el punto anterior:


a.       Conocer (obviamente) el servidor de Exchange y…


b.      Exponerlo en FQND, sin /Exchange. (Por ejemplo la que utilizamos para acceder mediante OWA).


5-      Esta instrucción (punto 4) genera 2 archivos y una carpeta:

a.       Carpeta C:Program FilesMicrosoft SSL ChainSavermail.company.com con el archivo root.cer.b.      Dos archivos en C:Program FilesMicrosoft SSL ChainSaver                                                               i.      mail.company.com.wm5.xml -> Para Windows Mobile 5                                                             ii.      mail.company.com.wm6.xml -> Para Windows Mobile 6 y 6.1

6-      Renombramos  el archivo “mail.company.com.wm?.xml” (? -> según nuestra versión) a “_setup.xml”.


7-      Seguidamente lo empaquetamos en un CAB, por ejemplo, utilizando makecab utility:
C:Program FilesMicrosoft SSL ChainSaver>makecab /d compress=off _setup.xml correo.cab


8-      Copiamos el archivo cab, en este caso correo.cab, al dispositivo móvil  y lo ejecutamos.


9-      Nos aseguramos que en Configuration / Security / Certificates / Root aparece el certificado que hace referencia al servidor Exchange.


10-   Ahora ‘Quitamos de la base’ [Uncradle] y volvemos a ‘Colocar en la base’ el emulador a través de Device Emulator Manager.


11-   Tras sincronizar ya tendremos acceso al servidor Exchange a través de ActiveSync.


  

 

Uso de RAISERROR desde SQL y gestión de errores desde ADO.NET

Existen multitud de formas de manipular los errores o excepciones desde llamadas en código administrado a procedimientos almacenados (SP en adelante) a través de ADO.NET. Quizás la peculiaridad reside en la responsabilidad que le otorguemos a los SPs.


Desde la versión SQL Server  2005, y con el uso de TRY…CATCH podemos capturar y tratar un error de la siguiente forma.

BEGIN TRY

END TRY
BEGIN CATCH
 

END CATCH


Sin embargo la no debemos olvidar el cómo devolvemos/notificamos un error desde el TRY…CATCH a la llamada realizada desde código administrado.


Devolver el error como resultado


Una opción sería la de retornar la descripción de las propiedades del error producido como resultado como sigue:

BEGIN TRY

END TRY
BEGIN CATCH

SELECT  ERROR_NUMBER()  AS ErrorNumber,     
      ERROR_SEVERITY()  AS ErrorSeverity,
      ERROR_STATE()     AS ErrorState,
      ERROR_PROCEDURE() AS ErrorProcedure,
      ERROR_LINE()      AS ErrorLine,
      ERROR_MESSAGE()   AS ErrorMessage;
END CATCH

Esta forma devolverá una fila de 6 columnas. El principal problema reside en que para la clase que realiza la llamada al SP le constará como que se ha ejecutado correctamente. Además si la llamada se realiza mediante un DbCommand mediante ExecuteScalar únicamente se obtendrá el número de error (primera columna). Por otro lado si el objetivo del SP es el de insertar, eliminar o modificar un conjunto de datos lo único que deberíamos esperar del SP es que nos dijera, en el caso que ha ido correcto, el número de filas afectadas, si se da el caso. En mi opinión, esta es una mala opción y se debería obviar. Además su detección desde la aplicación cliente es confusa.


Devolver el error como mensaje y generar excepción


La opción más correcta elegante es mediante el uso de RAISERROR dentro del CATCH. Sin embargo, para comprender el funcionamiento de esta función deberíamos, en primer lugar, conocer la anatomía de un error en SQL Server.


Anatomía de un error


La información que obtenemos a través del SQL Server Management Studio, en forma de texto es la interpretación que  éste hace de la información enviada por SQL Server a través de varios componentes que establecen sus propiedades.


Message number – Cada error tiene un número identificativo. Los mensajes producidos por el usuario a través de RAISERROR tienen un valor por defecto de 50000. A partir de 50001 en adelante se pueden configurar mensajes de error específicos en sys.messages.

USE master
GO 
EXEC sp_addmessage @msgnum = 600001,
      @severity = 15,
      @msgtext =  ‘Indicated time %s is not allowed.
                        Transports services are only available from
                        09:00AM until 05:00PM.’
      , @lang =         ‘us_english’
      , @with_log =     ‘FALSE’
GO 
EXEC sp_addmessage @msgnum = 600001,
      @severity = 15,
      @msgtext =  ‘La hora %s indicada no es válida.
                        Los servicios únicamente estan disponibles
                        desde las 9h hasta las 17h.’
      , @lang =         ‘Spanish’
      , @with_log =     ‘FALSE’
GO 

Severity level – Importante pues determinará el comportamiento del sistema en base a la severidad del error.



































TABLA 1: RAISERROR Severity Categories
Severity Range Error Number Info @@ERROR Logged As
1 hasta 9 In black NOT SET Informational
10 Not provided NOT SET Informational
11 hasta 14 In red SET Informational
15 In red SET Warning
16 In red SET Error
 

State – Los valores son de 1 a 127.  Se sabe que cada mensaje tiene un estado determinado pero Microsoft no lo ha documentado. Un estado 127 significa que el cliente se ha desconectado sin embargo esa información es trivial puesto que una severidad superior a 18 implica el mismo comportamiento nosotros.


Procedure – En qué objeto (contenedor del T-SQL) se ha producido.


Line – La línea en que se ha producido.


Message text – La descripción del error o mensaje.


Volvamos a la captura del error pero ahora utilizando RAISERROR:

BEGIN TRY     
   SELECT 1/0
END TRY
BEGIN CATCH

— Snippet de los BOL de SQL Server.
DECLARE @ErrorMessage NVARCHAR(4000);
DECLARE @ErrorSeverity INT;
DECLARE @ErrorState INT; 
SELECT     @ErrorMessage = ERROR_MESSAGE(),
    @ErrorSeverity = ERROR_SEVERITY(),
    @ErrorState = ERROR_STATE(); 
RAISERROR (@ErrorMessage, — Message text.
           @ErrorSeverity, — Severity.
           @ErrorState — State.
           ); 
END CATCH

Este es un ejemplo de control de error no esperado mediante RAISERROR. La peculiaridad reside que en desconocemos la severidad del mismo. Según la Tabal 1, si la severidad es inferior o igual a 10, desde la llamada cliente NO se producirá ninguna Excepcion. Sin embargo si es superior sí; ejemplo:

try
{   
   //lanzamos el SP
   
   res = dbCommand.ExecuteNonQuery();
}
catch (SqlException sqlex)
{   
   
//la severidad es superior a 10, luego entra aquí.
}
catch (Exception ex)
{
    //otra excepción no controlada a nivel de aplicación.
} 

El problema está que ante un error de severidad leve (10), como por ejemplo, un error 718 producido por:

708         No hay suficiente espacio de direcciones virtuales en el servidor o no hay suficiente memoria virtual en el equipo. Se ha usado la memoria reservada %1! veces desde el inicio. Cancele la consulta y vuelva a ejecutarla, reduzca la carga del servidor o cancele otras aplicaciones.

El SP se ejecutará correctamente sin embargo la única forma de obtener ese mensaje desde  ADO.NET es suscribiéndonos al evento InfoMessage del objeto DbConnection.

conexion.InfoMessageConnection += new System.Data.SqlClient.SqlInfoMessageEventHandler
                                                          (conexion_InfoMessageConnection);
 void conexion_InfoMessageConnection(object sender, System.Data.SqlClient.SqlInfoMessageEventArgs e){
{
      //aquí obtenemos el mensaje
      string res = e.Message;
} 

Para los errores de severidad 19 o mayor se exige que:


          En la llamada a RAISERROR se especifique la opción WITH LOG.


          Los autores pertenecen la función sysadmin.


Un ejemplo:


Esta  sentencia no dará error pero no guardará LOG en el visor de sucesos.


RAISERROR(‘esto es una prueba’,15,217)


Esta otra guardará una entrada en el visor de sucesos como Warning (TABLA 1)


RAISERROR(‘esto es una prueba’,15,217) WITH LOG


Esta es idéntica a las anteriores pero se procesa como Error no como Warning.


RAISERROR(‘esto es una prueba’,16,217)


RAISERROR(‘esto es una prueba’,16,217) WITH LOG


La siguiente sentencia NO funcionará:


RAISERROR(‘esto es una prueba’,19,217)

Sin embargo la siguiente si

RAISERROR(‘esto es una prueba’,19,217) WITH LOG


Los resultados en el visor de sucesos:

Error      08/05/2008 12:09:55       MSSQL$$$$$$$$$            17063    (2)
Advertencia       08/05/2008 12:05:46       MSSQL$$$$$$$$$            17063    (2)
Error      08/05/2008 12:05:12       MSSQL$$$$$$$$$            17063    (2)