Actually, we can configure an Azure Storage Account to have an access tier by default: hot or cool. Archive is not an option for an entire account though; so you just can specify if a given blob will be in archive mode.

When you mark a storage account to be cool by default, any single blob uploaded to that account will have its access tier set to cool if no other access tier is specified during the upload operation.

This means, that even when you have declared a default access tier for a storage account it can contain blobs with different access tires among them (i.e. a cool storage account can have hot and archive blobs as well).

Working with these blob features is pretty straightforward using the Azure Portal and its GUI. But what if you need to upload some millions of blobs in hot mode to a storage account that has been configured with a cool access tier?

Enter AzCopy: the legendary console tool that always has been there to help us with uploading blobs to the Azure Storage. Today, this tool is in its 10th version and in preview mode. This version represents a radical change in how we execute commands: now they are easier and cleaner to use. Its architecture has also been modified for high-performance reliable data transfers. Besides this, it now ships the ability to work with access tiers (this feature wasn’t available in previous versions because access tiers are relatively new).

So, let’s take a look to how take advantage of these new features to achieve our goal of upload blobs specifying their access tiers explicitly:

1. Download the v10 (preview or further) version of AzCopy. It now consists only of one *.exe that you can save in your preferred location. You can even change its name (I did it in order to keep parallel versions: the 8.1 along the v10 preview; so now I call the latest one by typing azc10pre)
2. To work with your storage account Azure requires that you either Login into the tool using Azure Active Directory or use SAS Tokens. For this example I will be using SAS tokens: There are many ways to get a SAS token. Once you have it you just need to append it at the end of the path of the blob you are working with. In a nutshell, the SAS token contains a passport to work with the storage account for a limited time and under some conditions.
3. Let’s create a container for our example:
• azcopy make https://account.blob.core.windows.net/container-namesastoken
• Observe how we have appended the sas token.
4. Now let’s use the CP command to copy two files from our computer to the cloud:
• azcopy cp "C:\local\path\myfile" "https://account.blob.core.windows.net/container/myfilesastoken”
• If we operate in this way the resulting uploaded blob, will be in cool tier as it is the account´s default and we didn’t specified anything else. But, if we need to override that default, we should use:
• azcopy cp "C:\local\path\myfile" "https://account.blob.core.windows.net/container/myfilesastoken” --block-blob-tier="hot"

So this is the way you can have mixed access tiers inside a given storage account using the AzTool that works for Windows, Linux and MacOS

SendGrid is a very good email sending service that allows you to send millions of emails through their platform. One of the mechanisms they have to inform you about what was the result of sending your massive emails (opened, reported as spam, deleted without being read, etc.) is by sending a HTTP POST to a URL you can provide. The HTTP POST will then contain a JSON body with details about the result of the emails sent.

You could be interested in store this information in a repository where you could be able to query these reports. For example, to know what messages were reported as spam during the last three days.

My customer was using a service called Keen.io that provided him with the webhook so SendGrid could send the information there, and with a repository and a platform to query the data gathered by the webhook.

But after a couple of months of being using this service, the costs started to rise notoriously. Hitting USD$500 just for some thousands of notifications received.

So, they consulted me, described to me the situation and I immediately imagined a solution based on Azure that will be obviously a way cheaper.

The main components would be the almighty Azure Functions on the receiving URL side, and Azure Cosmos DB as a repository.

Azure Functions can be deployed on the consumption plan model i.e. they will charge just for the seconds they are running. Not to mention that Azure gives you a million of Azure Functions calls per month for free!

On the other hand, Cosmos DB can store your JSON documents natively and make advanced and fast queries over them without too much effort. And since all the information could be stored in just one collection, you can keep the costs very low, as the price for just one collection of 400 RUs (you won't need anything else for a use case like these) is $21.92.

The other considerable cost associated with the Cosmos DB will be the storage per se. It is $0.25 GB/month. Let's exaggerate and say you have one GB of notifications per month. On the first month, your total costs will be near to $22+$0.25=$22.25. On the second, you'll pay $22 plus what you were already storing: $0.25 plus another GB: $0.25. A total of $22.5. And so on.

All in all, Keep.io is a very good service that keeps you away from the implementation details; but you could do it by yourself on your own Azure subscription while keeping the costs far down from one-tenth of the original cost of an already available service.

Let's get down to work

The following diagram depicts the solution for this case:

First, you would like to create a Cosmos DB on your subscription or maybe getting a free testing Cosmos DB. We are so flexible, that you could use even a Cosmos DB emulator.

Once you have created your Cosmos DB, you will have its endpoint and connection key (required to make the connection - like the connection string for a SQL Database). Keep them at hand as we are going to configure our function with them.

Now, using your Visual Studio, create an HTTP Triggered Azure Function. A new function with a predefined template will be created. Remove the get method from the function header as we are going to need just the post method. It is a good practice to reduce the attack surface a possible intruder could have.

By now, November 2018, the template will come a little outdated (the tracer for logging is now being deprecated and replaced by the ILogger). But not a problem. The code I'm showing you is already adjusted to being on the cutting edge (for now). Another thing to update is how we access the configuration settings. Observe that I have added the ExecutionContext parameter as input for the template. It will help us to set up the config object to get those variables in the way that is used in the .NET Core world.

So, if we are in the development environment, app settings will be loaded from local.settings.json; but in production, these variables will be loaded from the appsettings tab of the app service.

The data sent from the client (SendGrid or another source) to Azure Functions is supposed to come in raw JSON format inside the body of the post message as an array of JSON documents. That's why I am using the JArray object to store these documents.

Once you get the documents in memory it is time for us to communicate to the Cosmos DB and insert that info in the required collection. Apart from the Cosmos DB URI and Key, we are going to need the name of the DB and collection in which we need to store the data. All these values should be provided as configuration variables, so you can change the repository whenever you want, without changing your code.

The DocumentClient object will do the magic for us and when it is configured as we need a simple foreach will be required to traverse the JArray object and for each entry (a JObject) it will be inserted in the Cosmos DB using the operation CreateDocumentAsync.

If there are errors when inserting a document, in this case, the execution continues with the other documents. So, this insertion is not transactional. To make this execution transactional you should create a Cosmos DB stored procedure containing the transaction logic as right now there are no means to control transactions from Cosmos DB clients. Just inside the engine. The failed insertions will be reported in the log, and at the end of the execution, in the response, it will be noted that not all the documents were inserted. This could help administrators to check what went wrong.

This is the code that summarizes my previous instructions:

[FunctionName("JsonInserter")]
public static async Task<IActionResult> Run
    ([HttpTrigger(AuthorizationLevel.Function, "post", Route = null)]HttpRequest req,
    ILogger log,
    ExecutionContext context)  
{
 
    //This is the proper .net core way to get the config object to access configuration variables
    //If we are in the development environment, app settings will be loaded from local.settings.json
    //In production, these variables will be loaded from the appsettings tab of the app service
    var config = new ConfigurationBuilder()
        .SetBasePath(context.FunctionAppDirectory)
        .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
        .AddEnvironmentVariables()
        .Build();
 
    //Getting the configuration variables (names are self explanatory)
    var cosmosDBEndpointUri = config["cosmosDBEndpointUri"];
    var cosmosDBPrimaryKey = config["cosmosDBPrimaryKey"];
    var cosmosDBName = config["cosmosDBName"];
    var cosmosDBCollectionName = config["cosmosDBCollectionName"];
 
    //The data sent from the client to Azure Functions is supossed to come
    //in raw json format inside the body of the post message; 
    //specifically, as an array of json documents.
    //That's why we are using the JArray object. To store these documents
    JArray data;
    string requestBody = new StreamReader(req.Body).ReadToEnd();
    try
    {
        data = (JArray)JsonConvert.DeserializeObject(requestBody);
    }
    catch(Exception exc)
    {
        //As we relay on the json info correctly beign parsed, 
        //if we have an exception trying to parse it, then we must finish the execution
        //Exceptions in this functions are handled writing a message in the log
        //so we could trace in which part of the fucntion it was originated
        //And returning the most suitable error message with the exception text
        //as the function response
        log.LogError($"Problem with JSON input: {exc.Message}");
        //Bad request since the format of the message is not as expected
        return new BadRequestObjectResult(exc); 
    }
 
    //This is going to be the object that allows us to communicate with cosmosDB
    //It comes in the Microsoft.Azure.DocumentDB.Core package, so be sure to include it
    DocumentClient client;
    try
    {
        //Client must be initialized with the cosmosdb uri and key
        client = new DocumentClient(new Uri(cosmosDBEndpointUri), cosmosDBPrimaryKey);
        //If the desired database doesn't exist it is created
        await client.CreateDatabaseIfNotExistsAsync(new Database { Id = cosmosDBName });
        //If the desired collection doesn't exist it is created
        await client.CreateDocumentCollectionIfNotExistsAsync(
            UriFactory.CreateDatabaseUri(cosmosDBName),
        new DocumentCollection { Id = cosmosDBCollectionName });
    }
    catch (Exception exc)
    {
        log.LogError($"Problem communicating with CosmosDB: {exc.Message}");
        return new ExceptionResult(exc, true);
    }
 
    //Now that we have the db context we can proceed to insert the json documents in data
    uint successfullInsertions = 0;
    foreach (var jobj in data)
    {
        try
        {
            await client.CreateDocumentAsync(
                UriFactory.CreateDocumentCollectionUri(cosmosDBName, cosmosDBCollectionName),
                jobj);
            successfullInsertions++;
        }
        catch(Exception exc)
        {
            //We don't finish the execution here. If there are errors, the execution continues
            //with the other documents. So this insertion is not transactional.
            //To make this execution transactional you must create a cosmosdb stored procedure
            //with the transaction logic as there are no means right now to control transactions
            //from cosmosdb clients. Just inside the engine.
            //The failed insertions will be reported in the log, and at the end of the execution,
            //in the response, it will be noted that not all the documents were inserted.
            //This could help administrators to check what went wrong.
            log.LogError($"Problem inserting document: {exc.Message}\n" +
                $"Content: {jobj.ToString()}");                    
        }                
    }
 
    //A little report is generated as response if no exceptions were found
    //This report indicates how many documents were inserted and what was the total
    //of documents passed to the function to be processed
    var endingMessage = $"{successfullInsertions} / {data.Count} " +
        $"documents inserted in CosmosDB";
    log.LogInformation(endingMessage);
    return new OkObjectResult(endingMessage);
}

You can also find this project on GitHub and collaborate if you want to add more features or improvements to it:

UPDATE

After the first deployment, my customer told me that sometimes they required the information from SendGrid to be stored on a MongoDB database they had outside Azure.

The code base basically will be the same as for receiving the data in the Azure Function. Thus, I decided to make the function configurable so you can choose when you want to store the received data in CosmosDB either using the SQL Native model or the MongoDB model. Using the MongoDB model the data could be stored on any MongoDB i.e. Not just CosmosDB. Then, the configuration file for the Azure Function will look like:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "AzureWebJobsDashboard": "UseDevelopmentStorage=true",
    "cosmosDbEndpointUri": "https://…",
    "cosmosDbPrimaryKey": "…==",
    "mongoDbConnectionString": "mongodb://….documents.azure.com:10255/?ssl=true&replicaSet=globaldb",
    "dbName": "…",
    "dbCollectionName": "sendgrid",
    "useMongoDb": "true"
  }
} 

The key variable here is useMongoDb if it is set to true, it means that the function will be storing the data in MongoDB (or CosmosDB for MongoDB) so the values for the variables related to CosmosDB will be omitted.

The C# code also changed, specially to include the instructions to store the data in MongoDB. For this, you have to include the MongoDB.Driver nuget package. That code updated is published in the GitHub repository and you could use it to compare how is the experience of working with the Native SQL mode and the MongoDB mode in CosmosDB.

Me puse a investigar y sucede que el Uptime Institute ofrece unas certificaciones de disponibilidad de servicio en un datacenter. Estas certificaciones clasifican al datacenter como Tier I, II, III o IV, donde el IV es la categoría de los datacenters con más disponibilidad del servicio (de acuerdo a la clasificación propuesta por la https://www.tia-942.org/) con un 99.999% de disponibilidad.

Sin embargo, dado que la arquitectura de Azure y otros grandes proveedores de cloud es mucho más moderna y a escala que la de un datacenter tradicional de los que mide el Uptime Institute, los mecanismos usados por este instituto para hacer las mediciones, no aplican para proveedores de cloud, dado que el Uptime Institute trata de medir el tiempo que un gran servidor permanece arriba sin caerse; mientras que la nube está diseñada para que existan muchos servidores en redundancia, de tal suerte que cuando uno cae, los otros siguen funcionando en su lugar. Es por esto que ningún proveedor importante de cloud aparece en el listado del instituto.

Sin embargo, en conclusión, la experiencia de un usuario de Azure en términos de disponibilidad del servicio, al final es equiparable a la que ofrecería un datacenter tradicional estando en Tier 3 o 4, dependiendo de los servicios de Azure que se estén usando.

Es muy útil tener esto en cuenta cuando potenciales clientes de nuestra solución cloud traten de medirnos usando un mecanismo que no aplica ya en éste entorno.]]> https://docs.microsoft.com/archive/blogs/warnov/se-puede-justificar-el-uso-de-goto Sat, 16 Sep 2017 16:49:36 GMT https://blogs.msdn.microsoft.com/warnov/?p=3985 goto  es tal vez una de los statements más cuestionados en los lenguajes de programación modernos.

Por años fue la pasta causante del código espagueti y miles de developers han denigrado de el pobre.

Pero en realidad... no habrán formas en las que usarlo sea adecuado?

Consideremos el siguiente loop:

while (currentFibonacciNumber <= maxLimit)  
{  
    var lastCurrentFibonacciNumber = currentFibonacciNumber;  
    currentFibonacciNumber += previousFibonacciNumber;  
    previousFibonacciNumber = lastCurrentFibonacciNumber;  
    if (currentFibonacciNumber % 2 == 0 &&  
        currentFibonacciNumber <= maxLimit)  
        sum += currentFibonacciNumber;  
}

Es un sencillo loop que suma los números pares de la serie de Fibonacci, tendiendo en cuenta que hay un límite superior, donde la suma se detiene (maxLimit).

Con este loop, dándole a maxLimit un valor de 4000000000, el algoritmo se resuelve en promedio en 550 ticks.

Obsérvese que por cada iteración, se hacen 3 comparaciones.

Podemos reducir el número de comparaciones a 2:

while (true)
{
     var lastCurrentFibonacciNumber = currentFibonacciNumber;
     currentFibonacciNumber += previousFibonacciNumber;
     if (currentFibonacciNumber <= maxLimit)
     {
         previousFibonacciNumber = lastCurrentFibonacciNumber;
         if (currentFibonacciNumber % 2 == 0)
             sum += currentFibonacciNumber;
     }
     else break;
 }

 return sum;

Curiosamente, el tiempo empleado es muy similar: 545 ticks.

Al parecer la mera estructura del loop implica esfuerzo de proceso.

Y que tal si traemos al no muy querido goto a escena?

IterateFibonacci:
var lastCurrentFibonacciNumber = currentFibonacciNumber;
currentFibonacciNumber += previousFibonacciNumber;
if (currentFibonacciNumber <= maxLimit)
{
    previousFibonacciNumber = lastCurrentFibonacciNumber;
    if (currentFibonacciNumber % 2 == 0)
        sum += currentFibonacciNumber;
    goto IterateFibonacci;
}

return sum;

En este caso, el tiempo promedio se reduce a 455 ticks!

Esto en loops mucho más grandes o con comparaciones más complejas, podría significar una gran diferencia!

De aquí también puedo rescatar que el uso de goto fue muy específico y con un alcance muy bien delimitado. Y en tiempos de ejecución está dando mejor resultado que los otros métodos. Además es más entendible a primera vista que por ejemplo el segundo método donde con lo que uno se encuentra al principio es con un loop infinito. Algo que no es realmente el objetivo del algoritmo.

Sin embargo, como siempre hay que poner todo en una balanza. Es en verdad la mejora que se gana con goto justificable para usarlo? eso depende de cada caso de uso.

Cuando no es así, el primer procedimiento da más claridad para los posteriores lectores del código que por ejemplo el segundo y teniendo un tiempo de ejecución muy similar, podría pensarse en preferirlo.

Todos estos son simples hallazgos que no determinan ninguna regla pero si amplían nuestro horizonte para poder escoger la mejor opción según sea el caso.

En esta ocasión, les estaré escribiendo de Azure Active Directory B2C (Business to Consumer).

Éste es un servicio que siempre me imaginé sería muy cool de existir: Poder delegar la repetitiva y no funcional tarea de manejo de usuarios (registro, login, passwords, perfiles, integración con redes sociales, etc.).

Azure hoy lo ofrece. Y dispone de toda la infraestructura y robustez que siempre ha caracterizado al Active Directory, ahora a disposición de aplicaciones o servicios dirigidos al consumidor; no solamente a usuarios corporativos como era costumbre.

Así que si estás desarrollando tu startup o tienes ya una aplicación SaaS que maneja múltiples usuarios, con ADB2C, tienes una opción.

En este caso, Azure te ofrece una base de datos propia para almacenar la información de tus usuarios. Ésta DB cuenta con la misma alta disponibilidad que es ofrecida a servicios como Outlook . Es una base de datos que está tan abstraída que difícilmente te darás cuenta de que existe. Tu solamente usarás el servicio para poder registrar tus usuarios y que ellos puedan luego hacer login, cambiar sus passwords, etc.

Es tan abstraído el servicio, que ya te ofrece interfaces web previamente creadas que son mostradas en tu aplicación cada vez que un usuario se va a registrar, loguear, editar su perfil, etc.

Así que lo único que hay que hacer, es configurar el servicio de ADB2C en tu suscripción de Azure, configurar la aplicación o servicio propio para usar ADB2C y comenzar a usarlo!

Se incluyen 50 autenticaciones al mes gratis. Y un millón cuestan la tercera parte de un centavo. O sea, es muy barato.

Aunque también se ofrece Multi-Factor Authentication sin que tengamos que desarrollar ni una línea de código. Así pues para un usuario que se loguee correctamente con usuario y password, también se podría emitir un SMS o una llamada telefónica en la cual se transmitiría un código, para que sea ingresado en el login y tener un acceso aún más seguro. Cada autenticación de este tipo sí vale 3 centavos de dólar.

Hace casi un año intenté usar ésta tecnología, pero aún estaba muy incipiente. Por ejemplo, en ese entonces no estaba disponible para aplicaciones de escritorio. Hoy en día, sí que lo está. También está disponibles para aplicaciones móviles y de hecho está hasta para sitios web asp.net core.

No todo es color de rosa… aún

Así que decidí darle otra oportunidad, precisamente con un sitio web asp.net core. Luego de estudiar bastante (no es una tecnología muy directa de usar; hay que entender varios conceptos con una curva un poco más alta que la del promedio de servicios de Azure) llegué a hacer funcionar mi sitio con la ayuda de este servicio.

De hecho el servicio ofrece una buena API para hacer operaciones en Batch, por ejemplo para hacer una migración desde un sistema de manejo de usuarios anterior, o para ingresar un conjunto de nuevos usuarios con una sola operación.

Sin embargo, aunque la prueba concepto estuvo adecuada y funcionó bien, el ir a producción con ADB2C me presentó varios inconvenientes insalvables por ahora, pues dependen de funcionalidades que aún no están en el servicio pero que claramente están en el roadmap. Yo le calcularía unos 6 meses más para salir (no es un compromiso de ninguna manera):

1. Páginas personalizadas: Como lo mencioné ADB2C ofrece interfaces de usuario prefabricadas para que los usuarios se registren, hagan login, actualicen sus permisos, etc. Éstas interfaces son muy parecidas a las que aparecen cada vez que te vas a loguear en un servicio de Microsoft como Outlook, Onedrive, etc.
   
   Pero a veces, los requerimientos del negocio exigen que el look and feel permanezca uniforme durante toda la aplicación. Así que sería ideal que los desarrolladores pudiesen ofrecer sus propias plantillas para el manejo de cuentas de usuarios.
   
   Aquí aunque se ha avanzado y algunas experiencias se pueden personalizar (por ejemplo la de registro), otras como el sign in no permiten que usemos nuestras propias páginas para el login, por lo que quedamos limitados a la experiencia que se ofrece por defecto, aún cuando en ésta se pueden cambiar logos, imágenes y colores. Pero siempre bajo la misma apariencia en general.
   
   Este es un punto muy importante en el que el equipo está trabajando, para que podamos personalizar cada experiencia de usuarios en nuestras aplicaciones. Pero por ahora no es posible.
   
2. Localización: Esta falencia fue la que definitivamente me frenó. Ya que las experiencias de usuario vienen solo en inglés y no es posible cambiarlas. Así que por ejemplo donde se pide el correo electrónico aparece: Email Address y si se te olvidó el password aparece: Forgot your Password? Y cosas por el estilo.
   
3. Falta de acceso a datos de Redes Sociales: A pesar de que un usuario se puede loguear por ejemplo con su cuenta de Facebook a través de OAuth 2.0 soportado por ADB2C, no se pueden extraer datos de su perfil ni acceder a otros permisos requeridos por Facebook. Solo se puede obtener el email. La implementación de éstas características también está en progreso.
   
4. No veo un manejo de roles: Por tal motivo, éste asunto debería manejarse dentro de la aplicación. No es algo del otro mundo, pero por ejemplo la autenticación asp.net, tenía sus tablas de roles en la db.

Conclusiones

En conclusión podría mencionar que si necesitamos generar una aplicación o servicio que maneje usuario de una manera súper rápida donde no importa mucho el look and feel de las experiencias de usuario para login registro, emails de verificación, etc. Y tampoco que éstas experiencias estén en inglés, podríamos obtener mucho beneficio de ADB2C.

Pero para usos más reales en nuestra industria considero que debemos esperar un poco más. Aunque sea hasta poder tener las experiencias personalizadas para todos los casos y hacer una localización que se ajuste a los gustos de nuestros usuarios.

Sin duda una tecnología muy prometedora que en el cercano futuro estaré usando en mis proyectos para ser mucho más productivo.

Sin embargo una de las piezas faltantes que no podía ejecutar desde la consola, es la creación del repositorio o proyecto como tal en Team Services. Entonces tenía que hacer una pausa, ir al portal, loguearme si no lo estaba, crear el proyecto, buscar la url del git y luego sí conectar todo con mi cliente de desarrollo.

Obviamente Team Services posee una API Rest para poder ejecutar operaciones programáticamente. Así que decidí investigar como hacer una aplicación de consola que me permitiera crear el repositorio en Team Services de manera automática sin entrar al portal.

Una forma muy sencilla de poder acceder al API de Team Services es a través de los “Personal Access Token” (PAT). Si tienes una cuenta de Team Services, lo puedes obtener desde el portal (solo hay que hacerlo una vez). Entrando a la parte de seguridad dentro de tu cuenta:

Allí de una vez encontrarás el acceso a la administración de los PAT relativos a tu cuenta de Team Services. Para un mejor control recomiendo generar un PAT único para tu aplicación de creación de proyectos. Puedes escoger qué permisos otorgará ese PAT sobre los servicios de Team Services y por cuánto tiempo será válido. La idea es que luego uses el PAT para hacer tus llamados a la API sin necesidad de un usuario y contraseña o tal vez de doble autenticación.

Quise desarrollar este proyecto usando .NETCore, (si no estás familiarizado con .NETCore, puedes ver este corto video que creé para mostrar de qué se trata muy rápidamente), de manera que cuando esté en Linux o acaso en MacOS, igual pueda usar la herramienta. Es un proyecto que hace uso extensivo del archivo de settings para .NETCore, que como ya es estándar, he llamado appsettings.json:

  {
   "domains": {
     "warnov": "YOUR PAT",
      "sample": "SampleAccountPATlaxs3zhqf74rcflkxqhufbmhnhpmma"   
     },
   "templates": {
      "scrum": "6B724908-EF14-45CF-84F8-768B5384DA45",
      "agile": "ADCC42AB-9882-485E-A3ED-7678F01F66BC", 
     "CMMI": "27450541-8E31-4150-9947-DC59F998FC01"   
     },
   "sourceControl": [ "Git", "Tfvc" ],  
    "defaults": { 
     "sourceControlProvider": "git",
      "template": "6B724908-EF14-45CF-84F8-768B5384DA45"   
    }, 
   "apiPath": "https://{0}.visualstudio.com/_apis/projects?api-version=2.2"
}

El trabajo con este tipo de archivos en .NETCore es algo especial comparado a como hacíamos antes con archivos como el Web.Config o App.Config. Empezando porque ya no son archivos XML sino JSON. Para una guía detallada para aprender a manejar estos tipos de archivos, consulta este post que escribí al respecto.

En primera instancia encontramos una sección de dominios, donde especificamos el PAT de cada uno de ellos. Esto quiere decir que por ejemplo en el código anterior, puedo trabajar con Team Services en warnov.visualstudio.com y sample.visualstudio.com, pues se supone que allí he especificado los PAT válidos para cada uno de ellos.

Luego tenemos los templates; como lo puedes ver en las llaves, hacen referencia a si vamos a trabajar con scrum, agile o CMMI el ciclo de vida de nuestro proyecto de software. Generalmente escojo scrum.

Después vienen las opciones que tendremos para administrar el código fuente. Hoy en día Team Services ofrece Git y Tfvc (Team Foundation Version Control). Últimamente estoy optando por usar más git por lo simplista de su acercamiento.

También creé una sección de valores por defecto tanto para el proveedor de source control y el template a usar; esto para que mi aplicación pueda funcionar sin necesidad de que yo especifique todos los parámetros cuando la llame.

Para finalizar, especifico el formato de la ruta del API a usar. Sucede que ésta API está en constante evolución y me ha pasado que la URL cambia ligeramente. O acaso quieras usar otra versión de la API. En ese caso, basta con modificar este formato. Observa el {0}: éste va a ser reemplazado con uno de los nombres de dominios que has especificado arriba y que será aquel que escojas para trabajar.

Ahora sí, let’s get fun!

if (args.Length > 0)
{
    workingDomain = args[0];
    workingProject = args[1];
    description = args[2];
    var defaults = Config.GetSection("defaults");
    sourceControlProvider = defaults["sourceControlProvider"];
    templateId = defaults["template"];
}

Sencillamente evalúo si he pasado argumentos a la herramienta. En el primero vendría el dominio… por ejemplo warnov si quiero trabajar con warnov.visualstudio.com. Luego el nombre del proyecto. Por ejemplo: Picas y Fijas on the Cloud y finalmente la descripción del proyecto: “Maravilloso y revolucionario juego interactivo”. Como se aprecia, los otros valores son extraídos de la sección de defaults que definí en mi appsettings. de hecho, esto les da la idea de cómo se trabaja con ese archivo.

Si no paso parámetros, los pido de manera interactiva:

else
{
    //Domain
    workingDomain = GetDomain();
    //Project Name
    Console.WriteLine("Project Name: ");
    workingProject = Console.ReadLine();
    //Project Description
    Console.WriteLine("Project Description: ");
    description = Console.ReadLine();
 
    //SOURCE CONTROL           
    sourceControlProvider = GetSourceControlProvider();
 
    TEMPLATE ID
    templateId = GetTemplateId();                 }

y eso es todo. Luego pedimos los otros valores requeridos para la conexión, como el PAT; armamos el mensaje a enviar al API, lo enviamos usando POST y luego con el resultado mostramos un mensaje al final de la ejecución del programa.

//PAT
var pat = domainsSection[workingDomain];
//Message Body
var messageBody = GetMessageBody(workingProject, description, sourceControlProvider, templateId);
//PostExecution
var postResult = ExecutePost(workingDomain, pat, messageBody);
Console.WriteLine($"{postResult}\n\nPress Enter to Finish...");
Console.ReadLine();

Mensaje a enviar:

ProjectCreator body = new ProjectCreator(workingProject, description, sourceControlProvider, templateId);
var jsonBody = JsonConvert.SerializeObject(body);
return new StringContent(jsonBody, Encoding.UTF8, "application/json");

Observa que hay una clase modelo que se llama ProjectCreator. Desarrollé ésta clase a partir de la documentación del API, usando la metodología que he descrito en este post. Es una metodología que ayuda mucho a poder conectarse a todas las APIs modernas basadas en REST y JSON.

Pues bien, una ves inicializo ésta clase con los valores requeridos para la creación de mi proyecto en Team Services, la convierto a un JSON que luego paso a un StringContent que es el objeto provisto por  el framework que prepara los datos y los deja listos para ser incluidos en el body de un mensaje post que incluye data en formato texto para ser enviada al servidor.

Finalmente pasamos al envío del mensaje:

private static string ExecutePost(string workingDomain, string pat, StringContent messageBody)
{
    string responseBody=string.Empty;
    using (HttpClient client = new HttpClient())
    {
        string _credentials = Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", "", pat)));
        client.DefaultRequestHeaders.Accept.Clear();
        client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", _credentials);
        var url = Config["apiPath"];
         var request = new HttpRequestMessage(HttpMethod.Post,
            string.Format(url, workingDomain))
        {
            Content = messageBody
        };                       try
        {
            var response = client.SendAsync(request).Result;
            response.EnsureSuccessStatusCode();
            var code = response.StatusCode;
            if (response.IsSuccessStatusCode)
            {
                responseBody = $"{code}: {response.Content.ReadAsStringAsync().Result}";
            }                                                          }
        catch (Exception exc)
        {
            responseBody = $"ERROR: {exc.Message}. {exc.InnerException?.Message}";
        }
    }
    return responseBody;
}

En primera medida ajustamos las credenciales de acceso al API, encodificando el PAT que hemos obtenido. Luego ajustamos el header de autorización con esta data. También indicamos que el API maneja mensajes JSON.

Después armamos la url de envío de nuestro request y adicionamos el mensaje que armamos previamente.

Finalmente enviamos el request y le pedimos al sistema que si no nos responden con éxito lance una excepión, a través de response.EnsureSuccessStatusCode();

Observa que la respuesta inicial no va a ser un 200, porque la operación no finaliza en bien recibimos la respuesta. La creación de un proyecto toma algún tiempo así que lo que es retornado por el servidor de Team Services es el código 202 que nos indica que todo está bien, pero que debemos esperar a que la operación termine (cosa que por lo general podemos hacer sin tomar acción especial distinta a esperar algunos segundos). También se nos retorna una URL de seguimiento del estado del request por si queremos automatizar la herramienta para que ella misma cree el repositorio local una vez haya quedado creado en la nube. Pero eso haría parte de otro post.

Así que después solo resta inicializar nuestro repositorio git, y agregarle el remote con dirección similar a esta:
https://[yourdomain].visualstudio.com/DefaultCollection/_git/[yourprojectname]</STRONG]

y voilá… habremos podido crear todo lo necesario para nuestro ambiente de desarrollo local soportado por Team Services, sin necesidad de salir de la consola!

Todo el código de esta solución lo pueden encontrar en mi Github. Pueden agregarle más funcionalidades basados en el API de Team Services o modificar su comportamiento. Estaré atento a sus push requests!

Ya no es ningún secreto que las APIs de hoy se construyen con la simplicidad de REST  y JSON.

Hay tal flexibilidad ya, que en todo lado encontramos herramientas muy apropiadas tanto para ayudarnos en el desarrollo de estas APIs, como para sus pruebas.

De los temas más acostumbrados hoy en día, es que la API reciba requests POST, donde los parámetros de ejecución vienen embebidos en un JSON que es transmitido dentro del content de dicho post.

Trabajando con JSON en .NET

Entonces para manejar JSON especialmente dentro de nuestras aplicaciones .NET, nada mejor que el gran framework, Json.NET creado por el talentoso James Newton-King. Quien lo ha dispuesto de manera free aún para el uso comercial. Y desde mi modo de ver, es la mejor librería para trabajar con JSON con .NET. Y además viendo que ya .NET es multiplataforma, entonces sería la mejor librería para trabajar JSON sobre cualquier plataforma. Te puedes bajar la dll a la vieja usanza o sencillamente incluir el paquete desde Nuget con el wizard o desde la consola NPM.

Creando modelos para nuestras APIs JSON con C#

Digamos eso sí, que lo anterior fue lo más obvio de este post. Pero bueno, ya teniendo como manipular JSON desde nuestro C#, lo siguiente que puede ocurrir entonces es que quisiéramos conectarnos a un API que nos pide le enviemos un json con la siguiente estructura:

{
  "name": "FabrikamTravel",
  "description": "Frabrikam travel app for Windows Phone",
  "capabilities": {
    "versioncontrol": {
      "sourceControlType": "Git"
    },
    "processTemplate": {
      "templateTypeId": "6b724908-ef14-45cf-84f8-768b5384da45"
    }
  }
}

Podríamos ponernos a construir las clases a mano y emplear un montón de tiempo en esto.

Pero mejor tomar el ejemplo del api que nos da el developer y pasarlo por esta tool online:

Como se aprecia, el modelo generado en C# es muy bueno. Nos ahorramos montones de tiempo y si no es exactamente lo que queremos, al menos tenemos una gran aproximación a lo que requerimos.

Luego ya con esas clases y la ayuda de JSON.NET, podemos hacer serializaciones que nos emiten automáticamente el JSON requerido.

Generando datos de prueba JSON de manera masiva

Algunas APIs pueden requerir que enviemos registros para ser insertados en una base de datos. Estos registros, deberían ir representados en JSON. Pero generalmente la edición de éstos  es mucho más sencilla por ejemplo en Excel, que poniéndose a escribir el JSON a mano. Mi recomendación entonces es seguir usando Excel para crear los datos de prueba y luego los grabamos en formato CSV. Cuando ya los tenemos así, podemos copiar y pegar el contenido de este archivo y ponerlo en esta otra tool online:

El resultado es un muy bien estructurado JSON que podremos agregar a nuestras pruebas al API con la aplicación que estemos construyendo.

Y hablando de pruebas:

Prueba de APIs propias y de terceros

Una vez creamos un API generalmente ésta quedará expuesta en nuestra máquina de desarrollo a través del localhost. Y para no tener que escribir una aplicación web por nuestra propia cuenta, tenemos varias opciones.

curl:

Es una herramienta de consola que proviene del mundo Unix y nos permite hacer llamados HTTP y recibir respuesta en la misma consola. Hay muchas formas de obtenerlo. Existe la versión stand alone para Windows y también se puede obtener dentro del paquete de Cygwin que es uno de los intentos más notables hasta ahora de traer el mundo de la consola Linux a Windows. Si han instalado Git para Windows, ésta instalación también instala una emulación de la consola Bash del mundo *nix, que incluye por supuesto curl. Pero la opción más interesante para mí sin embargo, es usarlo desde Bash en Windows, luego de que ya es posible tener un subsistema de Linux formal dentro de Windows, gracias a las herramientas para desarrollador que vienen para Windows 10. Así que el bash que se ejecuta no es emulado sino realmente el bash de Linux (con algunas limitantes):

Por ejemplo, con una línea de comando consulté un API que tengo desplegada en Azure que sencillamente te retorna la IP actual con la que te reconocen desde internet:

Claro está que si el término azul no es lo tuyo y te gustan las tools más elaboradas, podrías usar el muy amigable PostMan que comenzó siendo una extensión de Chrome y ahora ya tiene su instalador standalone para Windows y otros sistemas operativos:

Aquí hago un llamado a la misma API anterior. Se pueden armar llamados HTTP de cualquier tipo y hay muchas ayudas visuales para crear el cuerpo de los mensajes y para formatear las respuestas desde el server de manera que sean fácilmente entendibles por el developer.

Pero definitivamente la navaja suiza para trabajar con APIs es Fiddler. Su interfaz para nada tan amigable con el usuario tal vez nos haga sentir como si estuviéramos frente a los controles de un Boeing 747. Pero por ejemplo a diferencia de PostMan, Fiddler permite rastrear todo el trafico web desde y hacia nuestra máquina de desarrollo. Nos permite simular certificados https, correr scripts de automatización avanzados y muchos más. Puedes leer más de fiddler en este blog post que escribí hace años.

Visualizando JSON entendiblemente

Puede que luego de probar alguna API recibamos un montón de JSON que queramos ver de manera estructurada, sabiendo la cantidad de nodos que hay en cada nivel y demás. Para eso, nada mejor que esta gran tool online:

Generación de esquemas JSON

Sí, hay esquemas JSON. Así como habían esquemas XSD, también hay documentos que pueden describir un JSON. Y esto es muy útil para poder desarrollar otras herramientas que manejen JSON o para poder validar la estructura de un documento JSON en general. La herramienta que les mostraré a continuación, permite que le pasemos un ejemplo de un documento JSON y en vez de generarnos por ejemplo clases C#, lo que nos genera es el dichoso esquema que obviamente viene escrito en JSON. Plataformas como Logic Apps en Azure por ejemplo, requieren que especifiquemos un esquema JSON para los datos de entrada de las aplicaciones y qué mejor que contar con una herramienta online como ésta:

En conclusión este es el pequeño arsenal de tools con el que me defiendo cuando trabajo bien sea creando o consumiendo APIs. Si tienes otras tools para recomendar, bienvenidas en los comentarios!

La principal limitante para mover recursos entre suscripciones sin requerir soporte, es que dichas suscripciones pertenezcan al mismo tenant de Active Directory (o a la misma cuenta de Azure – una cuenta de Azure puede ser dueña de varias suscripciones de Azure. En este caso, todas las suscripciones pertenecientes a esa cuenta, también pertenecen al mismo tenant de Azure Directory que se crea por defecto).

Si las suscripciones no pertenecen al mismo tenant, entonces se hace obligatorio pedir un caso de soporte para hacer el movimiento.

Hoy en día, esta es una labor sencilla, dado que dentro del portal de administración de Azure, en las opciones de soporte hay una especial para la administración de la suscripción, que permite este tipo de acciones y que viene incluida sin costo.

En los otros casos, el movimiento de recursos en general funciona de la siguiente manera:

Se selecciona el Resource Group (RG) que tiene los recursos a mover. Allí en la descripción del RG hay una opción de mover el RG. Al seleccionarla, aparecen los recursos incluidos dentro de es RG para escoger aquellos que queremos mover. Luego se selecciona el RG al que se quieren mover.

Esto casi siempre es necesario antes de mover los recursos a otra suscripción, pues este movimiento se hace basado en todo un RG completo. Así que primero hay que agrupar los elementos que se quieren transferir a un RG separado, si es que no se quiere transferir todo un RG originalmente.

Una vez se tienen agrupados los elementos que se quieren transferir procedemos así:

Y nos aparecerá una lista de todas las suscripciones pertenecientes al mismo AD Tenant. Solo a esas podremos mover los recursos automáticamente. Recuerde que si se necesita mover los recursos a un tenant diferente, se requerirá entonces de un caso de soporte.

Otras limitaciones:

Como lo mencioné anteriormente, hay servicios con limitantes. Por ejemplo el App Service posee ciertas reglas a la hora de moverse. O los elementos clásicos que no están manejados a través de un Resource Group. En estos casos, la mayoría de veces también es mejor acudir a soporte. Encuentre aquí, una lista detallada de los elementos que se pueden mover, aquellos que tienen limitantes y los que definitivamente no pueden moverse.

Esta es la filosofía en Windows. Pero en Linux y Mac, las opciones por defecto siempre instalarán la última versión estable.

Así que si en Windows queremos estar a la vanguardia, existen un par de pasos adicionales que necesitamos para quedar con la última versión estable que a Enero de 2017 es la 1.1.0.

La versión 1.1.0 del framework requiere trabajar con una versión de Nuget mínimo 3.4.4. Esto, con el fin de que Nuget pueda configurar bien los archivos del proyecto Net Core de acuerdo a la última versión. Si en el about de Visual Studio se observa una versión menor a 3.4.4:

Entonces lo primero que hay que hacer es actualizar a la última (clic en la imagen para ir al destino):

Después de esto, procedemos a descargar el .NET Core 1.1 ( o el que se encuentre “current” a la hora de leer este artículo).

Obsérvese que como queremos desarrollar, se escoge el SDK y no solo el runtime. Solo escogeremos el runtime, para instalarlo en una máquina cliente por ejemplo.

Acto seguido, ejecutamos la instalación del SDK:

Ahora, si usamos Visual Studio, procedemos a la creación o modificación de nuestro proyecto .NET Core que queremos tener en la última versión del framework. Y si vemos el archivo de configuración project.json observaremos que en la sección de dependencies, tiene una estructura similar a esta:

"dependencies": {
   "Microsoft.NETCore.App": {
     "type": "platform",
     "version": "1.0.1"
   }

Aquí se nota que por defecto Visual Studio trabaja con la versión LTS. Por ahora no hay una forma visual para decirle a Visual Studio que trabaje con la versión 1.1.0 o la última estable. Ojo que no basta con cambiar la versión en el archivo de configuración. Es necesario hacer el upgrade a través de Nuget; que como ya está actualizado a la última versión, sabrá cómo actualizar el proyecto para que quede funcionando correctamente. Así que hacemos la actualización a través de Nuget:

Después de esto, entre otras actualizaciones tendremos la del project.json:

"dependencies": {
   "Microsoft.NETCore.App": {
     "type": "platform",
     "version": "1.1.0"
   }

Con lo que ya quedaríamos listos para correr nuestra aplicación con la última versión del .NET Core Framework.

Encuentra en mi Github un ejemplo muy sencillo de una aplicación de Consola .NET Core corriendo con la versión 1.1.0 del framework: