Azure Functions 2 – Publicando en Azure

En la anterior entrada del blog realizamos un ejercicio sencillo en el que desarrollamos una simple azure function “disparada” ´por llamada http en la que utilizamos inyección de dependencias. En esta nueva entrada realizaremos la publicación de este ejercicio en Azure

Como pre-requisito necesitamos contar con una suscripción a Azure y, preferiblemente, ya creado un resource group. Para obtener una cuenta en Azure podemos optar por crea una en este link con hasta por 12 meses de ciertos servicios de forma gratuita. 

Con la cuenta ya creada podemos realizar la publicación por medio de Visual Studio, para esto hacemos clic derecho sobre el proyecto que tiene nuestra función y seleccionamos la opción “Publish”. 

Si no hemos realizado previamente ninguna publicación esto nos abrirá un “wizard” en el que crearemos, en primera instancia, nuestro perfil de publicación. En el primer paso seleccionaremos donde vamos a publicar:

 

En este caso dejaremos la opción seleccionada por defecto es decir publicaremos directamente en la “Azure” cloud, y haremos clic en el botón “Next”. 

En el segundo paso se nos solicitará que seleccionamos el tipo de servicio que alojara nuestras funciones. Es importante notar que “Azure function app” se refiere al servicio o recurso dentro de azure capaz de alojar azure functions, podemos pensar en el cómo el espacio que contendrá nuestras funciones. Este servicio puede ejecutarse (tras bambalinas) en Windows, Linux o como una imagen de Docker, o como cuarta opción podemos desplegar directamente en otro servicio, el Azure container Registry (contenedor de imágenes Docker). En este sencillo ejemplo dejaremos seleccionada la opción por defecto, es decir publicaremos en un Azure Function App que se ejecutará en un entorno Windows y hacemos clic en el botón “Next”. 

Si estuviéramos utilizando Visual Studio con credenciales ya asociadas a una cuenta de Azure este tercer paso sería diferente, pero asumamos que vamos a configurar la conexión a Azure por primera vez por lo que hacemos clic en el link “Sign in” (si aún no hemos creado la cuenta podríamos utilizar el link Create your free Azure Account pero en lo personal prefiero llegar aquí ya con la cuenta creada). Se nos mostrara una ventana emergente en la que debemos ingresar las mismas credenciales utilizadas al crear la cuenta en Azure (estas pueden ser diferentes a las credenciales con las que estamos utilizando visual Studio)

 

Una vez ingresadas las credenciales y realizada una correcta conexión con Azure se nos mostrará una pantalla similar a la siguiente: 

En esta se muestra el nombre de nuestra subscripción (o subscripciones en el caso de que tuviésemos varias). Para continuar debemos hacer clic el símbolo “+” cerca de la etiqueta Function Apps, lo cual nos abrirá la ventana en la que configuramos una nueva app. 

Aquí ingresamos el nombre de nuestra Function App (Que no es el nombre de la función en sí, si no del recurso o servicio que la va a contener); seleccionamos la subscripción en la que va se va crear este servicio; seleccionamos o creamos un Resourse Group (Que es un contenedor de recursos, que sirve para organizar de mejor manera recursos afines o que interactúan entre sí); seleccionamos el Plan Type (que tiene que ver con ciertas características y modelos de precio. El Consumption, por ejemplo, es el verdaderamente serveless y el más cómodo en cuenta a precio al menos para pruebas, pero también hay un plan Premuim y un plan Service App estos últimos no son verdaderamente serveless pero permite por ejemplo configurar una VNet para la Azure Function App cosa que no lo permite el plan Consumption) en nuestro ejercicio dejamos el plan Consumption seleccionado. Seguidamente seleccionamos la Location (corresponde a la región geográfica donde se desplegará la Function App, tiene mucha importancia pues la idea es que se encuentre cerca de nuestros usuarios o cerca de otros recursos que podríamos utilizar lo que a su vez podría reducir latencia y costos) y, finalmente, seleccionamos o creamos un Azure Storage donde se almacenara el código de la función que se va a ejecutar, hacemos clic en el botón “Create” lo que creará los recursos en Azure y nos devolverá a la pantalla anterior. 

En esta dejamos seleccionado el checkbox “Run from package file (recommended)” y hacemos clic en el botón “Finish”. Ya hemos creado los recursos necesarios y hemos creado un “perfil” de publicación que recordara nuestras selecciones, pero aún no hemos realizado la publicación. Para esto debemos hacer clic en el botón “Publish” de la siguiente pantalla: 

Por ahora ignoraremos los iconos de “warnning” y efectivamente haremos clic en el botón “Publish” con lo Visual Studio procederá a realizar la publicación de nuestra Azure Function.

Al final de la publicación podemos ir al portal de Azure con el fin de verificar que efectivamente nuestra publicación se realizó. Podemos ubicar nuestro Resource Group y dentro de esta nuestra recién creada Function App 

Al seleccionarla se mostrara una menú a la derecha donde tenemos la opción “Functions“ 

Al seleccionar la opción “Functions” se nos listará todas las funciones contenidas dentro del Azure Function App, en nuestro caso únicamente aparecerá Function1 que es el nombre con el quedó decorado nuestro método run de la azure function. 

Al seleccionar la función se nos mostrará un menú en la parte superior de la sección donde podemos obtener la dirección de nuestra función. 

Hay que notar que el link tiene en su querystring un código incorporado, este se generó automáticamente debido a que seleccionamos el authorization level en “Function”.

Con este url podemos probar nuestra función ahora alojada en la nube de Azure

 

Con esta entrada terminamos este pequeño tutorial de publicación en Azure de una azure function.

Leer más

Azure Functions 1 – Dependency injection

Últimamente gracias a proyectos dentro de la compañía he tenido oportunidad de tener contacto con tecnologías en la “nube”, cloud computing como lo llaman los entendidos. Entre estas tecnologías están las azure functions que son parte de la oferta serverless de Microsoft. 

Estas funciones consisten en porciones de código que se ejecutan producto de algún trigger o evento. Estos triggers puede ser llamadas http, timers, archivos subidos a un blob storage, entre muchos otros tipos. Estas funciones en la versión 2 de las azure functions se pueden escribir utilizando .net core 3.1 (también se puede usar javascript) por lo que se pueden usar técnicas afines, por ejemplo, al web api o los sitios MVC tales como la inyección de dependencias.

Realicemos un ejercicio sencillo. Empecemos por crear nuestra azure function desde visual studio 2019:

Seleccionamos el template de las azure función y hacemos clic en “Next”

Le damos un nombre a nuestro proyecto, seleccionamos una ubicación y hacemos clic en “Create”. A continuación, se nos presentará la pantalla donde podemos seleccionar el trigger que desencadenará la ejecución de nuestra función.

Para nuestro ejercicio seleccionaremos el “HTTP trigger”. En el panel de la derecha si tuviéramos una cuenta en azure podríamos seleccionar el storage account al cual se subiría la azure función, también podemos dejarlo tal cual en el storage emulator como lo haremos en este caso. Adicionalmente podemos seleccionar el nivel de autorización (Authorization level) los cuales pueden ser:

Anonymous: no hay ningún mecanismo que restrinja el acceso.

Function: va a requerir un código o key para acceder a la función particular, este código se pude proporcionar por medio un campo llamado code en el querystring del llamado o bien en un header llamado x-functions-key.

Admin: al igual que el nivel de función el acceso es por medio de un código o key, solo que en este caso se conocen como “host key” y se define una sola llave para todas las funciones dentro de una app función mientras que en Funcion se debe definir un code para cada función.

En nuestro caso dejaremos el nivel del acceso por defecto, es decir Function.

Este template de Visual Studio nos proporciona una azure function totalmente funcional

Esta función espera un parámetro name ya sea en el querystring o bien como parte de un json en el body del llamado. Visual Studio proporciona una manera de probar nuestra función de manera local, sin necesidad de subirla a la nube de Azure. Simplemente ejecutamos nuestra función con lo cual se nos mostrará una ventana de consola como esta:

Como podemos notar en la sección Functions se nos listan las funciones que tenemos codificadas (en este caso solo tenemos una, pero podríamos tener “n”) al tiempo que nos indica, en el caso de las funciones activadas por http trigger, su endpoint. Podemos utilizar insomnia (o postman) por ejemplo para probar nuestra función

Bien, ya tenemos nuestra primera azure function, ahora hagamos esto un poco mas divertido. Añadimos un proyecto de lógica de negocios, en el cual tendremos una clase que vamos a utilizar en nuestra azure función por medio de la inyección de dependencias. Quedamos con algo similar a lo siguiente:

Ahora tenemos un proyecto BLL, donde tenemos nuestra clase RequestProcessor y su respectiva interfaz. 

IRequestProcessor: 

namespace BLL
{
    public interface IRequestProcessor
    {
        string ProcessName(string name);
    }
}

RequestProcessor: 

namespace BLL
{
    public class RequestProcessor : IRequestProcessor
    {
        public string ProcessName(string name)
        {
            return $"Hello {name} from Azure function!";
        }
    }
}

Ahora queremos utilizarla en nuestra función. Probablemente el código de nuestra función termine quedando algo más o menos así (Recordemos añadimos a nuestro proyecto AzureFuncionDI la referencia al proyecto BLL haciendo clic derecho sobre el primero y Add > Project Reference…): 

using BLL;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using System.IO;
using System.Threading.Tasks;

namespace AzureFunctionDI
{
    public class Function1
    {
        private readonly IRequestProcessor Processor;

        public Function1(IRequestProcessor Processor)
        {
            this.Processor = Processor;
        }

        [FunctionName("Function1")]
        public async Task <IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = Processor.ProcessName(name);

            return new OkObjectResult(responseMessage);
        }
    }
}

¿Qué hicimos? Pues añadimos una variable del tipo interfaz y un constructor a nuestra clase para poder inyectar la clase que implementa esta interfaz y para esto debimos quitar el modificador static tanto de la clase como del método run. Esto compila, sin embargo, no se ejecuta correctamente; al realizar el llamado nos muestra algo como esto y nos devuelve un código 500 Internal Server Error:

Esto pasa porque nos hace falta una pieza muy importante que es donde realizamos la inversión del control, es decir, donde decimos que al solicitar un tipo de esa interfaz se debe insertar cierta clase en concreto. En las aplicaciones MVC esto se realiza en el Startup.cs pero aquí no tenemos este archivo, entonces, vamos a crearlo dentro del proyecto que contiene la azure function:

El código del archivo Startup sería el siguiente:

using BLL;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(AzureFunctionDI.Startup))]

namespace AzureFunctionDI
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddScoped<IRequestProcessor, RequestProcessor>();
        }
    }
}

Como se mencionó al inicio, si ya hemos trabajado con el mecanismo de inyección de dependencias de .Net Core esto no parecerá muy familiar. Para que el código de arriba nos funcione debimos instalar el paquete Microsoft.Azure.Functions.Extensions ya que estamos heredando de functionStartup. En este código indicamos que al solicitar un tipo de interfaz IRequestProcessor se inyecte un objeto RequestProcessor el cual implementa dicha interfaz. Con esto ya en su lugar procedemos a ejecutar nuevamente la función.

Y he aquí que nuestra azure function con inyección de dependencias está funcionando.

En otra entrada explicare como realiza la publicación de la función puesto que esta entrada del blog ya se alargó bastante.

Leer más

Arquitectura RESTFul

Estas son las notas del primer capitulo del libro Hands-On RESTful API Design Patterns and Best Practices que recomiendo encarecidamente adquirir, ya que aclara los conceptos que aquí apenas se mencionan. Lo siguiente es un resumen que está lejos de tener el valor de todos los matices que abarca el libro.

Algunos conceptos o definiciones previos:

XML/JSON (Extensible Markup Language/ JavaScript Object Notation) es el formato que provee metadata para los datos que son contenidos dentro de los mensajes que intercambian los sistemas/servicios

SOAP (Simple Object Accces Protocol): usado para para transferir datos.

WSDL (Web Services Description Language) : se usa para definir los servicios disponibles que pueden ser consumidos

UDDI (Universal Description, Discovery, and Integration) es una lista de los servicios disponibles.

URI (Uniform Resource Identifier) se usa para identificar la ubicación de recursos en una red.

API (Application Programming Interface) especifica como un componente de software se comunica con otros componentes.

REST (Representational State Transfer) es una manera o estilo de exponer funciones y datos para ser consumidos en un ambiente distribuido.

SOA (Service Oriented Architecture): define estándares y enfoques para el diseño de web services y cómo estos se comunican entre sí. Aquí, un web service es la representación lógica actividades de negocio repetibles,  son una operación que tienen un resultado específico: obtener el costo de un producto, actualizar el inventario, obtener la ubicación de un negocio. Para el consumidor el webservice que consume es una caja negra. Estas alojados en servidores e interactúan con otras aplicaciones a través de interfaces.

ROA (Resourse Oriented Architecture): es una arquitectura fundada en la semántica de la web. Define un diseño estructural y guías para soportar e implementar interacciones con cualquier recurso conectado. En este contexto, cualquier entidad de negocio puede ser representado por como un recurso y pude ser accesible a través de una URI. Así en un sistema de recursos humanos cada empleado es una entidad (servicio) y sus detalles, salario, perfil, son asociaciones (descriptores) de una entidad y cada entidad puede permitir varias acciones (contratos).

Como se apuntó ROA está fundamentada en la semántica de la web ¿Cuál semántica? Las operaciones o “verbos” que implementa el protocolo HTTP , es decir:

VERBO	USO
GET	Leer las representaciones de un recurso
PUT	Creación de un nuevo recurso.
DELETE	Eliminación del recurso (y de los recursos ligados, de forma opcional)
POST	Modificación del recurso.
HEAD	Meta información del recurso.

Ahora, para decir con propiedad que tenemos una API que es REST ésta debe cumplir con ciertas restricciones  y propiedades (dadas por Roy Fielding, quien propuso en primera instancia el concepto de REST) Entre las propiedades están: se exponen recursos, no se mantiene estado entre requests, direccionabilidad (el recurso debe usar una dirección), uniformidad y usar el protocolo HTTP para la comunicación de los datos.

Entre las restricciones (Constraints) REST están:

• Cliente-Servidor: La comunicación se da entre el cliente (o muchos clientes) que es quien quién solicita un servicio, utilizándolos mediante el envio de requests, y el servidor que es quien provee el servicio a consumir, manejando los request o solicitudes para acceder a los mismos. Clientes y servidor típicamente existen en un ambiente distribuido comunicándose a través de una red por medio de patrón request-respond.

• Statelessness (sin estado): Significa que el servidor no mantiene ninguna información o estado contextual entre los requests. Dicho de otra forma cada llamado (request) del cliente debe contener toda la información necesaria de manera explícita para que el servidor pueda entenderlo y manejarlo de manera totalmente independiente. Esto asegura escalabilidad y confiabilidad del lado del servidor. Es importante señalar que es el cliente, entonces, quien debe mantener algún mecanismo para mantener contexto entre las llamadas al servidor.

• Caching (Caché): en el contexto de REST se refiere a la posibilidad almacenar datos de uso frecuente de manera que parcial o totalmente se elimine la necesidad de la comunicación entre el cliente y el servidor, disminuyendo la latencia y mejorando el rendimiento en el lado del cliente. Hay diversas estrategias para el caching: browser caché, proxy caché, gateway cache (reverse proxy). Usualmente se usan algunos tags a nivel de headers para controlar el cache: expires, Cache-control,E-Tag, Last-Modified. (más información).
• Interfaz Uniforme: como se mencionó anteriormente se refiere a la combinación de la semántica del HTTP, con el concepto de recurso, creando una interfaz uniforme. Es decir donde GET, es siempre leer, y DELETE es siempre eliminar con respecto a un recurso cualquiera este sea. Esto es parte del corazón de REST, Roy Fielding, instituyó cuatro principios necesarios para alcanzar a cabalidad la restricción de interfaz uniforme:

1. Identificación de los recursos: cada recurso debe estar identificado inequívocamente  por medio de un URI. Así el URI para ubicar un empleado será https://api.MyRRHH.com/1.1/Planilla/Empleados/:id.json los datos devueltos podrán refinarse y mejorase con la evolución de las versiones pero está siempre será la forma de acceder al recurso empleado.
2. Manipulación del recurso: se refiere a la independencia del URI de un recurso y los formatos en la que la información es devuelta al cliente. Puede que la misma URI exponga el recurso solicitado en diferentes formatos: JSON, XML, HTML,  PNG, SVG, etc (Multipurpose Internet Mail Extension (MIME))  permitiendo que el cliente manipule esta data según sus posibilidades y conveniencia. Para lograr esto el servidor habilita a través del tag Accept del Http header que el cliente le solicite el formato en que requiere el recurso. Separar la representación (formato) del recurso  de la URI del mismo es un aspecto crucial de REST.
3. Mensajes Auto-Descriptivos: REST descansa sobre el principio de que tanto el request del cliente como el response del servidor son estandarizados (tienen cuerpo y metadata) y son autodescriptitvos es decir usan los tipos de mensajes: GET, HEAD, OPTIONS, PUT, POST y DELETE) de manera que son completamente comprendidos tanto por el servidor como por el cliente. De esta manera se tiene el mecanismo por medio del cual los mensajes contienen la información necesaria, manteniéndose cada uno independiente, sin necesidad de mantener estados en el servidor.
4. Hypermedia como el motor de Estado de Aplicación (Hypermedia as the Engine of Application State (HATEOAS)): Sin esta característica no podemos argumentar que un servicio es RESTful, fue introducida en el modelo Richardson Maturity Model (RMM) por Leonard Richardson. Se trata del siguiente paso una vez tenemos un servicio que expone un recurso a través de un URI accesible a por medio de los verbos de HTTP, y consiste en brindar al cliente que consume un recurso la guía de qué es lo siguiente que puede hacer con él. Esto se realiza por medio de un dato más denominado de forma estándar “link” o “links” que acompaña la respuesta del servidor. Para ponerlo menos abstracto imaginemos un servicio que nos devuelve una lista de las citas disponibles de un doctor, con HATEOAS a cada uno de los  ítems devueltos se le añade un dato link que nos indica cual es el URI para tomar esa particular cita de manera que el cliente es guiado al siguiente paso o estado de la aplicación. Resumiendo, HATEOAS se refiere a que la representación de un recurso devuelta por un servicio incluye links que le indican a quien lo consume recursos relacionados con el mismo.

• Sistemas en capas: consiste en sistemas que se componen de unidades que se comunican a través de interfaces predefinidas desempeñando diversas funciones. Estas capas puede estar físicamente separadas de manera que, por ejemplo, la API REST se instala en el servidor A, la autenticación se realiza en el servidor B y los datos se almacenan el servidor C. REST sugiere que los servicios pueden estar constituidos por múltiples capas, que éstas publican contratos de servicios y que, en un ordenamiento jerárquico, la lógica de una capa dada únicamente puede ser conocida por la capa inmediatamente superior o  inmediatamente inferior.

Resumiendo:
El mismo Roy Fielding, fundador del estilo REST, dejó claro que para que un API (servicio) se atribuya el estatus de RESTful debe cumplir con las restricciones de su estilo de arquitectura, es decir cumplir con:

• Cliente-Servidor
• Statelessness
• Caching
• Interfaz Uniforme
• Sistema en capas.

Las metas de una arquitectura REST son cumplir con las siguientes propiedades:

• Rendimiento
• Escalabilidad
• Simplicidad
• Modificabilidad
• Visibilidad
• Portabilidad
• Confiabilidad
• Testeability (susceptible de probarse)

Una  vez mas sugerir la adquisición del libro Hands-On RESTful API Design Patterns and Best Practice para aclarar los conceptos que quedan oscuros en este resumen.

Leer más

El secreto de la felicidad…

Ya tengo mis años en estas andanzas, me quedan dos años para alcanzar mi 40va primavera (aunque también he tenido inviernos), son casi 17 años de vida profesional, y desde que comencé este camino he tenido claro una cosa que, muy honestamente y sin tratar de engañarme a mismo (más de una vez me he sorprendido tratando de engañarme), ha logrado mantenerme feliz: Hago lo que me gusta hacer, simple y llanamente.

Desde muy temprana edad, en la época de chiquillo de escuela, conocí las computadoras. Aquellos cajones con letras en verde chillón o ámbar en fondo negro, me cautivaron, me enamoraron desde el principio. Unos cursos gratuitos de Logo y Logowriter que vinieron a ofrecer del Liceo León Cortés Castro (Grecia, Alajuela, Costa Rica) a mi escuela rural de distrito, fueron el disparo de salida para sumergirme en lo que iba a ser el resto de mi vida…

Había que ir y venir en autobús, en tiempo fuera de horario escolar. Para un niño sumamente tímido y retraído aquello era todo un reto, casi una hazaña;  pero ver moverse aquella tortuguita digital formando figuras a partir de los comandos que yo creaba, bien valían la pena: aquello me hacia feliz.

Computadora no había en casa, con mucho costo había un televisor a blanco y negro y un atún para repartir entre cinco más algo de arroz y frijoles. En esa época era impensable contar con una. Pero yo sabía que, tarde o temprano, me iba a dedicar a trabajar con computadoras sí o sí.

Un amigo, de más musculo económico, adquirió una. Aquella era una maravilla, no solo tenía verde, sino hasta 8 colores ¡8 colores! No existía nada en el mundo mejor que jugar Test Drive. Pasaba cada vez que podía, y, aunque los turnos para usarla eran largos, yo era feliz.

Llegué al colegio, al mismo liceo de los cursos, y salvo un brevísimo periodo de coqueteo con la biología (en parte por culpa de una joven y bonita profesora sustituta) mi ruta era clara, estar cerca del laboratorio de informática y llevar computación como materia técnica. Me gustaba mucho aprender, no únicamente de computadoras, y mientras aprendía era feliz.

Llegué a la universidad decido a estudiar informática, aunque no tuviera “machete” o herramienta. Pero mi padre y madre, quiénes con mucho esfuerzo habían logrado hacerse de un lotecito, lo sacrificaron para comprarme mi primer computadora. Jamás nunca podré pagarles ni agradecerles lo suficiente.

Aún recuerdo las palabras de recibimiento de la directora de la carrera, quien, además, impartía el curso de lógica: “Aquí no vienen a aprender a digitar, ni a usar paquetes ofimáticos, aquí van a aprender a programar una computadora”. Éxtasis…

Todos los cursos de programación los pasé con muy buenas notas, mas no todo fue fácil, muy a mi pesar también repetí un par de cursos. Pero no importaba, estar ahí y saber cómo funciona un programa, como decirle a una computadora que hacer en PASCAL o en FOX-DOS, era simplemente demasiado bueno para ser cierto. Era muy feliz.

Al final de la carrera universitaria las oscuras garras de la duda intentaron sujetar mi voluntad. ¿Y si no consigo trabajo? ¿Y si no es cómo lo imagino? ¿Y si no cumplo las expectativas? ¿Y si no gano lo suficiente? Y muchas otras preguntas asaltaban mi cabeza; algunas eran dudas razonables otras eran estúpidos miedos queriendo convertirse en excusas para tomar pésimas decisiones.

Al final, posterior a una práctica empresarial que me dejó un mal sabor, aunque fue experiencia al fin y al cabo, y luego de una única entrevista de trabajo, en Julio de 2001 llegué a mi segunda casa, a mi segundo hogar. ¡Y nada era como lo imaginaba! Todo es más difícil, mucho más complicado pero también excepcionalmente gratificante.

Desde entonces he programado casi siempre, algunas veces con más otras con menos responsabilidades, con muchos colegas al mismo tiempo o autogestionándome completamente solo y, aunque también se hacen muchas otras tareas de la forma más profesional posible como reuniones con clientes, levantamiento de requisitos, diseño, documentación, manuales, ayuda, aspectos gráficos, presentaciones de productos, capacitaciones, etc… para mí lo importante es que tarde o temprano termino programando y eso me hace simplemente feliz.

Aunque he tenido y sé que habrá días en que hubiera sido mejor no salir de la cama (porque para todos existen esos días complicados) y que habrá problemas grandes y pequeños que solucionar y situaciones difíciles que enfrentar, laborales y personales. El secreto para ser feliz la mayor parte de mi existencia ha consistido y consiste aún, en haber encontrado lo que realmente me apasiona (afortunadamente muy temprano) y haber tomado la decisión de dedicarme a eso como forma de vida. Hacer lo que me gusta, dedicarme a lo que realmente me gusta es mi secreto para ser feliz.

Leer más

Scripts útiles: Ranking de Tablas y Búsqueda en Procedimientos Almacenados

 Algunas veces necesitamos algunos pequeños scritps de SQL para hacernos la vida más simple. A continuación dejo dos de éstos.

El primero lista las tablas en una base de datos en orden cantidad de registros en ellas en orden decendente.

SELECT  O.name TABLA, I.rows AS REGISTROS
FROM sysobjects O
	INNER JOIN sysindexes I ON I.id = O.id 
WHERE O.xtype= 'U'
	AND I.indid IN (0, 1)
ORDER BY REGISTROS DESC;

es útil para encontrar tablas candidatas a particionamiento .

El segundo sirve para buscar texto en los procedimientos almancenados o funciones

DECLARE @buscar nvarchar(max)='texto a buscar' 

SELECT OBJECT_NAME(id)
FROM sys.syscomments
WHERE [text] LIKE '%'+ @buscar +'%'
AND (
	OBJECTPROPERTY(id, 'IsProcedure') = 1
	OR OBJECTPROPERTY(id, 'IsInlineFunction') = 1
	OR OBJECTPROPERTY(id, 'IsScalarFunction') = 1
	OR  OBJECTPROPERTY(id, 'IsTableFunction') = 1
	)
GROUP BY OBJECT_NAME(id)

Muy útil cunado queremos buscar codigos de registros, parametros etc

Leer más