Archivo del Autor: Liarjo

Avatar de Desconocido

Acerca de Liarjo

....

Ejecutar Procesos DotNet de manera Controlada

Se me plantea la siguiente necesidad:

"… tenemos un proceso complejo de trasferencia de datos entre dos sistemas construido en una aplicación de consola dotnet. Como es muy compleja, no podemos tocarla, es decir es un Pragma[1] para nosotros. Necesitamos controlar la ejecución de este proceso, es decir que se ejecute y si hay errores se notifique a los administradores…… ¿Qué podemos hacer?…."

Bueno, al ser una aplicación dotnet, la cosa se pone simple. Si usted nunca se ha detenido a considerar que significa que dotnet use código administrado, prepárese porque aquí va a disfrutar una de las ventajas de este tipo de código.

La solución más simple para esto es hacer que una aplicación que llamaremos "Controlador" sea quien ejecute el "Pragama" que llamaremos en este Post "Proceso". La idea es que el Controlador ejecute el Proceso en su mismo AppDomain[2] utilizando las facilidades que el Framewok da para ello. Esto se muestra en el siguiente código. Específicamente se usa el método ExecuteAssembly[3].

 

static
void Main(string[] args)

{


string[] strArgumentoControl= new
string[1];

 

Console.WriteLine("Ejecutar?");

Console.WriteLine("Ingrese Argumento de Control: ");

strArgumentoControl[0] = Console.ReadLine();


try

{


AppDomain.CurrentDomain.ExecuteAssembly(

@"..\Proceso\bin\Debug\Proceso.exe",null,strArgumentoControl );

}


catch (Exception X)

{

Console.WriteLine("Error: " + X.Message);

 

}

Console.ReadLine();

}

Código 1

Lo que hace esto es ejecutar en el mismo dominio de aplicación el Proceso, que está implementado en Proceso.exe. El tercer argumento del método los argumentos que se le pasan al programa que se está ejecutando.

Hasta ahora nada muy impresionante, esto es lo bueno. Si en el Proceso.exe se levanta una excepción (aspecto que dotnet maneja muy bien) está es atrapada por el Try/Catch del Controlador. Esto es porque los dos programan son código administrado y pueden compartir la información de las excepciones.

Veamos el Proceso de ejemplo, está en el código 2. Dependiendo del argumento que se le pase Proceso levanta diferentes Excepciones o termina de manera exitosa. Fíjense que no se controlan excepciones aquí, la idea es que si el proceso falla por cualquier motivo sea el Controlador quien se haga cargo.

 

class
Program

{


static
void Main(string[] args)

{

Console.WriteLine("Ejecutando Proceso Controlado……………");


switch (args[0])

{


case
"1":


throw
new Exception("Error Tipo Uno");


case
"2":


throw
new Exception("Error Tipo Dos");


case
"3":


throw
new Exception("Error Tipo Tres");


case
"4":


int iCero = 0;

Double dNada;

dNada = 100 / iCero;


break;


default:

Console.WriteLine("Todo Bien :)");


break;

}

Console.WriteLine("Terminó Proceso Controlado……………");

}

}

Código 2

 

Eso es todo, esto puede ser mucho más sofisticado agregando lógica en Controlador para que distinga los tipos de excepciones, notificaciones, reintentos, etc…etc…

El Código de ejemplo pueden descargarlo desde Aquí

Referencias

[1] Pragma, Pragma a diferencia de un sistema, es algo que se usa "por los bordes" Es decir no se comprende su interior.

[2] AppDomain, http://msdn2.microsoft.com/en-us/library/system.appdomain.aspx

[3] ExecuteAssembly, http://msdn2.microsoft.com/en-us/library/system.appdomain.executeassembly.aspx

Proyecto Mini ESB DotNet Código Abierto, Buscando definiciones Iniciales

Como primer paso para poder poner en marcha este proyecto, voy a tratar de ordenar los comentarios recibidos hasta ahora. Las respuestas puestas aquí son para la discusión del equipo.

Aquí van los comentarios

C1.- ¿El proceso no es demasiado waterfall? ¿No sería mejor pensar en iteraciones rápidas e ir publicando todo en CodePlex desde el inicio? Me parece que es más dinámico y todo avance irá en función al feedback que se obtenga -más allá de los objetivos iníciales que se establezcan.

Tienes toda la razón en el proceso “WaterFall”. Mi idea era hacer un proyecto pequeño, de alcance limitado por lo que no pensé en varias iteraciones. La razón de esto es que además de hacer el software la mayoría de los miembros del equipo no ha trabajado en un proyecto así. Me refiero a un proyecto de código abierto, con un equipo distribuido, etc.

Ahora, podemos fijar objetivos más amplios para el ESB y ponerlo en varias iteraciones. Me parece una buena idea. (Propuesta 1)

C2.- Me confunde un poco la idea de un Enterprise Service Bus para empresas pequeñas. ¿Cuál es la funcionalidad que tienes en mente? No conozco demasiadas empresas pequeñas que tengan problemas de integración que justifiquen esto. ¿Tienes una lista de requerimientos de alto nivel?

La idea de hacer un USB para pequeñas empresas es justamente darles una herramienta para que puedan construir “funcionalidad compartida” para diferentes aplicaciones. Es decir Servicios.

La funcionalidad que tengo en mente es (Propuesta 2):

1.- Catalogo de Servicios: Publicar servicios.

2.- Un despachador implementado en un Pipe And Filter.

3.- Filtros de autentificación, autorización y Traza.

C3 – Basarse en BizTalk creo que te dejaría fuera del alcance de cualquier empresa pequeña. El costo de licenciamiento es enorme. Lo que podría usarse eventualmente es BizTalk Services, aunque es algo en etapa de prueba aun.

Estoy de acuerdo usar BizTalk es mala idea, mejor usamos lo que viene con el Framework 3.0 (Propuesta 3)

C4 – Debiera haber una lista de cargos o tareas para que sean repartidas/asignadas/elegidas (?)

Para este proyecto usaremos una herramienta de colaboración como CodePlex [1]. Esta herramienta define los siguientes roles (Propuesta 4):

Rol1.- Anonymous

Rol2.- Logged-In

Rol3.- Developer

Rol4.- Coordinator

Las tareas las serán definidas por el equipo y la asignación será por acuerdo. Si no existe acuerdo en algún punto podemos votar como método de asignación. Aquí retomo algo que declaré en el segundo Post de este proyecto [2] "cumplir con los compromisos que asuman". Nadie será obligado a hacer algo, los compromisos son personales.

C5- Una de esas tareas inmediatas sería hacer un sitio/grupo propio del proyecto y por ende…

Sí, podemos usar CODEPLEX[1]. Yo ya creé el siguiente sitio para el proyecto:

http://www.codeplex.com/miniESB

Para poder darles acceso, necesito que se inscriban como usuarios codeplex. Este sitio permite hacer discusiones, compartir fuentes, etc.

C6- Hay que darle un nombre al proyecto

En este punto no tengo propuesta. Pueden darle el nombre que quieran 🙂

C7 – Felices vacaciones. …también eres de los que en sus vacas no puede estar sin desarrollar?

Muchas gracias, fueron unas buenas vacaciones pero muy cortas. 😉

Esos son los comentarios recibidos hasta ahora.

Durante “los comentarios sobre los comentarios” puse 4 propuestas, las cuales me gustaría validar con ustedes equipo. Las pueden ver fácilmente en el texto porque están marcadas con (Propuesta N).

Eso es todo por ahora, seguimos trabajando y quedo atento a sus comentarios.

Referencias

[1] Codeplex, http://www.codeplex.com

[2] Segndo Post, http://liarjo.spaces.live.com/blog/cns!4131EA552C5BB029!2266.entry

Pipe and Filter, simple y útil.

Para un proyecto necesitamos hacer un Middleware. Este Middleware consume servicios del BackOffice del cliente, pero no es solo un catalogo de servicios sino que debe actuar como intermediario entre el cliente y los servicios.

Para implementar esta maravilla se me ocurrió mirar el patrón de diseño Pipe And Filter, después de leer con atención me dije que esto podía hacerse extremadamente simple y quedar muy útil.

Entonces en unas 2,5 horas hice el ejemplo que incluyo en este POST. Este es un ejemplo para mostrarlo a los otros Developer del equipo por lo que deben perdonarme algunas barbaridades en la escritura del código, no es un ejemplo de buenas prácticas de codificación.

Aclarado eso, vamos al grano!!

Descripción del Patrón

Lo primero es entender el patrón Pipe and Filter. Este patrón se refiere a una cadena de filtros por los cuales pasa un mensaje (Contexto), desde el inicio al final. Cada uno de los filtros tiene acceso al contexto tanto de lectura como de escritura. Quien controla el armado y ejecución del Pipe es un Controlador. Este controlador lee de la configuración cuales son los filtros y su orden, los carga y le pasa el contexto al primero. Cuando el primero ejecuta le regresa el control al Controlador para que tome el Contexto y se lo pase al siguiente filtro.

 

Diagrama 1: Pipe And Filter

Contexto

El contexto es lo que se comparte entre los filtros. Los filtros tienen que compartir un método de ejecución, es este método el que ejecuta el Controlador para que el filtro se active. La siguiente clase es un ejemplo de una implementación de una clase Contexto.

 

Diagrama 2: Clase Contextooperaciones

 

EL siguiente código muestra la implementación de de la clase contexto. Este contexto es el que se irá traspasando de filtro en filtro para ser usado en la lógica que implementa cada filtro. Aparte de los dos operadores, que se usaran como argumentos en cada filtro, tiene una lista de respuestas dónde almacenará la respuesta de cada uno de los filtros. Así al terminar la ejecución del Pipe se contará con los resultados de cada filtro en la lista.

 

Código 1: Clase Contextooperaciones

 

Filtro

Los filtros componen el Pipe. La idea de los filtros es que expongan un método que los acciones (los ponga a trabajar) y que cuando terminen de ejecutar ese método regresen el Contexto al Controlador del Pipe. En el siguiente diagrama se muestran cuatro filtros los cuales exponen el método interceptar como iniciador del trabajo del filtro.

Diagrama 3: Clases que implementan filtros

El método que los acciona es Interceptar (muy creativo el nombre) el cual recibe el contexto, ejecuta la lógica programada en el filtro y deja el contexto en la propiedad miNuevoContexto para que el controlador del Pipe pueda tomarlo.

El siguiente código muestra la implementación del filtro. Este filtro lo que hace es sumar dos números que lee del contexto y guardar el resultado en una lista de resultados. Esa lista contendrá el resultado de todas las operaciones realizadas en el Pipe, esto es posible porque la lista de resultados está en el contexto y no el filtro.

Código 2: Clase FiltroSuma

Controlador

El controlador es el director de orquesta de este patrón, toma desde la configuración cuales son los filtros que debe cargar y en qué orden. Cuando inicia la ejecución utiliza el contexto y se lo entrega al primer filtro ejecutando su método para gatillar la lógica del filtro. En el ejemplo anterior el método Interceptar.

Diagrama 4: Controlador

 

En el siguiente código se muestra la clase PipeManager, que es el controlador del Pipe. LA instanciarse la clase, se le pasa la configuración XML que contiene los filtros a ser cargados. Una Vez cargados los filtros, el Pipe está listo para ser ejecutado.

Para poner en acción el Pipe es necesario llamar al método Ejecutar pasándolo el contexto inicial como argumento. Opcionalmente hay un parámetro de la ejecución que se llama ExceptionForward. Este segundo parámetro especifica cómo se comporta el Pipe si hay una excepción en alguno de los filtros. Puede comportarse de dos maneras ante una excepción: detenerse o guardar en el log y avanzar.

Código 3: Clase PipeManager

Programa para probar el código

Para probar la implementación hice una aplicación de consola que instancia el controlador pasándole la ruta del archivo XML que contiene la configuración de los filtros. Paso dos, crea el contexto inicial. Luego comienza un loop en el que pide ingresar los dos operadores, los carga en el contexto y ejecuta el Pipe.

Código 4: Clase Program

Configuracion XML

La configuración XML se muestra en el siguiente archivo XML.

Código 5: Xml configuración

 

Los códigos de este ejemplo los pueden descargar aquí.

 

Salu2  

Proyecto Mini ESB DotNet Código Abierto

Hace un tiempo propuse en este espacio una idea que hace tiempo le doy vuelta. Hacer un proyecto de ESB en DotNet que sea Open Source. Ese post pueden verlo Aquí.

He conversado con unas 4 personas y me han dicho que Sí a la idea, lo cual me ha puesto muy contento. Además de las personas que he contactado directamente, hay otro par que leyendo el Blog me han mandado mensajes para participar.

Motivado por la recepción de la propuesta ahora propongo las siguientes etapas para el proyecto.

Etapa Inicial

  • Armar equipo
  • Definir Objetivos
  • Formalizar Alcances y visión.

Etapa Elaboración

  • Identificar referencias técnicas
  • Diseñar el ESB
  • Publicar Diseño.
  • Presentar el proyecto a la comunidad y recibir feedback.

Etapa de Construcción

  • Construcción del ESB
  • Construcción del caso de uso de Ejemplo.
  • Documentar el proyecto.

Etapa de publicación

  • Publicar el Proyecto en Codeplex
  • Presentación del resultado a la comunidad.
  • Celebrar el fin del proyecto. (Esta es la parte que más me gusta)

     

Hoy 27 de junio, dos días antes de irme de vacaciones partimos con esta iniciativa. Esto quiere decir que vamos a "Armar el equipo".

¿Quiénes puedes participar?

En rigor cualquier persona que tenga interés. Esto es un proyecto voluntario / Social, es decir no hay retribución económica por esto y el resultado del trabajo será un Software de uso libre y código abierto a la comunidad. La idea es hacer una contribución desde nuestra realidad a la problemática técnica de las empresas pequeñas y medianas.

¿Cuál es el beneficio de participar?

La respuesta para mí es muy simple, aquí todos aprendemos.

¿Qué requisitos necesito para participar?

Como vamos a desarrollar software es necesario que los miembros del equipo sepan programar, ojalá en DotNet. No hay que ser un genio de la NASA para participar, porque entre los diferentes miembros del equipo nos vamos apoyando para llegar al objetivo del proyecto.

¿A qué me comprometo si me inscribo en el proyecto?

El único compromiso que podemos pedirle a los voluntarios como proyecto es el de "cumplir con los compromisos que asuman". Es decir, si usted se compromete a asistir a una reunión o a escribir un paper, etc, simplemente hágalo. Nadie en el equipo impondrá tareas, los miembros del equipo nos repartiremos las tareas de común acuerdo, es decir cada uno tomará los compromisos que esté dispuesto a cumplir.

¿Cómo se organiza este proyecto?

Esto no es un proyecto de software comercial, por lo que no hay jefe. La idea es que los miembros del equipo se organicen entre pares y avancemos en dirección de cumplir con el objetivo del proyecto.

Ahora, la pregunta del millón de dólares…….

¿Cómo me inscribo?

La inscripción es muy simple. En este mismo POST ponga como comentario los siguientes datos:

  • Nombre ó Nick.

    Ejemplo: Juan Pablo – Liarjo.

  • De que parte de universo es.

    Ejemplo: Santiago de Chile, trabajo en una empresa de tecnología, en el departamento de Desarrollo de Software.

  • BackGround

    Ejemplo: He trabajado en desarrollo de sistemas 10 años. No soy informático sino que estudie Ingeniería Civil Electrónica, Tengo experiencia en DotNEt.

  • Enviar un mensaje privado con sus datos de Contacto

    Ejemplo: Hola Soy Juan Pablo, quiero participar, puse mis datos en el Blog y me correo es XXXX@lala.cl

    Los mensajes privados se pueden mandar usando la funcionalidad del Blog "Enviar Mensaje". Esto aparece al final del post, como Link/opción.

 

Bueno, la invitación hecha el 3 de junio ahora ya está formalizada.

Espero sinceramente que este proyecto sea exitoso, no sólo porque es una idea que se me ocurrió a mí, sino porque sería la primera iniciativa que conozco de la comunidad DotNEt en Chile que enfrenta un tema tan "sofisticado" como un ESB. Por otra parte con el producto que se generará aquí, muchas empresas pequeñas que no tienen acceso a este tipo de tecnologías podrán usarlo, lo que ayudará a acortar la Brecha Digital.

Por último pero no por eso menos importante es que aquí aprendemos todos.

Salu2

PD: Espero que alguien se anote por lo menos 😉

 

¿Cómo hacer un gráfico con Barras y líneas en Reporting Services?

Hoy me preguntaron si se podía hacer en SSRS un gráfico que mostrara dos series de datos en barras y el promedio de las dos en una línea.

La respuesta es Sí.

¿Cómo se hace?

Es súper fácil, primero agregamos las dos series que estarán en el gráfico de barras. Por ejemplo costos y ventas, como muestra la ilustración 1.

Ilustración 1

Luego la idea es agregar una serie que saque el promedio de las dos series de barra y lo muestre como una línea. Para ello en las propiedades del gráfico, vamos a la pestaña Data y agregamos una serie de valores. Esto se muestra en la ilustración 2.

 

Ilustración 2

En el dialogo de creación de la serie se debe agregar el valor de la etiqueta a mostrar, por ejemplo "promedio" y el valor. En el valor usamos las capacidades de SSRS para calcular valores con la siguiente fórmula:

=Avg(Fields!HOras.Costo+Fields!Prom.Precio)

Por último para que esta serie se muestre como una línea y no una barra, como las otras dos, debemos seleccionar la opción Plot data as line como muestra la ilustración 3.

Ilustración 3

El resultado se muestra en la ilustración 4.

Eso es todo.

 

Salu2

Llamar un web servicies programado en java desde un Visual basic 6.0

Me llegó el siguiente mail:

 

Hola Juan Pablo:

Tienes alguna idea de cómo llamar un web servicies programado en java desde un Visual basic 6.0?
Si puedes ayudarme, te lo agradecería.
Que te tengas un buen día.

 

Por supuesto que se puede llamar un Servicio Web desde Visual Basic 6.0. No es tan fácil como se hace en dotNEt pero es posible.

Ahora que el servicio Web este hecho en Java, PHP, Piton, etc..etc… no tiene importancia ya que el propósito de los servicios Web es independencia de la tecnología que los implementa.

Puedes ver los siguientes links con ejemplos:

α.- Calling Web Services from Visual Basic 6, the Easy Way

β.- Microsoft Office XP Web Services Toolkit 2.0

γ.- HOW TO: Integrate a SOAP Toolkit Client with an Apache SOAP 2.2 XML Web Service

δ.- Sending SOAP Requests by Using the SOAP Toolkit 2.0 Client

 

Salu2

Entendiendo la administración de SOA

He aquí un excelente artículo sobre administración de SOA (SOA Management) escrito por Dain Hansen para BEA.

El aspecto de administración es crítico para el éxito de las iniciativas de SOA. Para lograr cumplir con la promesa de lograr agilidad usando SOA no solo es necesario una solida tecnología de servicios sino administrarla de manera efectiva.

En el siguiente link pueden ver una buena introducción al tema de administración.

Understanding SOA Management: What’s in your SOA?

Salu2

Buen feedback a la Vena!

Recibí este correo electrónico después de hacer una presentación en un cliente.

Mi hermano, que es más inteligente que yo, me dijo una vez que cuando uno entiende realmente algo complejo debe poder explicarlo en términos simples para que todos lo entiendan. Si uno no es capaz de hacer eso, no entiende realmente de lo que se está hablando.

Este es el feedback 😉

"Estimados 

    Solo quiero detenerme y felicitarlos por la presentación del día hoy, si bien no soy alguien muy técnico que pueda aportar en sus presentaciones, si lo hago como aprendiz y creo que en todas sus presentaciones me ha ido quedando claro cada una de las piezas de esta arquitectura…..dado que explicar algo complejo y hacerlo amigable y entendible para el resto no se ve todos los días en esta Area ………………………"

 

Por supuesto no revelaré información de quién, dónde, cuándo, por qué 😉

Salu2