Social Icons

twitter facebook google plus linkedin

miércoles, 18 de enero de 2017

Enviar datos a Azure Mobile Apps usando jQuery

Hola Mundo:

Este artículo es un tanto distinto a los que siempre se publican. Esta vez es sobre desarrollo, pero
consumiendo servicios publicados en Microsoft Azure.

Azure Mobile Apps es un servicio de Microsoft Azure que permite levantar, sin mayor esfuerzo, un backend para aplicaciones móviles. Este backend puede estar construido con ASP.NET o Node.js.
De cualquier manera, provee las herramientas para generar una REST API lista para ser consumida desde las aplicaciones cliente.

Me refiero a aplicaciones cliente y no móviles, porque estos servicios pueden ser consumidos desde cualquier lugar. Incluso desde un sistema web usando Javascript.

En este caso puntual, compartiré una ayuda de memoria para enviar datos usando jQuery usando el método AJAX:
$.ajax({
 type: "POST",
 contentType: "application/json; charset=UTF-8",
 url: "https://xxxxxxx.azurewebsites.net/tables/xxxxxx",
 headers: {'ZUMO-API-VERSION': '2.0.0', 'Content-Type': 'application/json'},
 data: JSON.stringify({
  "Campo1": "Valor1",
    "Campo2": "Valor2"
 }),
 dataType: "json",
 accept:  "json",
 success: function(datos){
   console.log(datos)
   alert('Datos reportados correctamente')
 },
 error: function(jqXHR, estado, error){
   console.log(estado)
   console.log(error)
 },
 complete: function(jqXHR, estado){
   console.log(estado)
 },
 timeout: 1000000000
});

Lo relevante:

  • El type es POST. No olvidar que estamos enviando datos al servidor. Si tienes duda sobre esto, revisa este link: http://www.restapitutorial.com/lessons/httpmethods.html
  • contentType debe ser "application/json; charset=UTF-8". El servidor recibe datos en formato JSON. De otra forma, arrojará error 500.
  • La url es la dirección web del servicio. Esta es la forma más estándar si es que no han creado una personalizada.
  • La cabecera de la petición se indica en headers. Siempre debe estar incluido 'ZUMO-API-VERSION': '2.0.0' y  'Content-Type': 'application/json'. En el caso que alguno falte, la consola indicará que hace falta una de las dos y arrojará un error 500 o 400.
  • En data se indican los datos que se enviarán. El método stringify del objeto JSON es el encargado de hacer que los datos que estamos enviando sigan el formato de JSON.  Recuerden que en contentType y en la cabecera se indica que estamos enviando datos en formato JSON. Si esto no está, recibirán un error 400.
  • El atributo accept le indica al servidor el formato en el que se requiere la respuesta.
  • El atributo dataType es usado por jQuery para "formatear" la respuesta antes de dejarla disponible para el trabajo con ella.
  • Success indica la función que se ejecutará cuando los datos se reporten correctamente.
  • Error indica la función que se ejecutará cuando se produzca un error en el reporte de datos.
  • Complete indica la función que se ejecutará luego de la ejecución de lo indicado en Success o Error.
  • Timeout indica el tiempo total de espera, en milisegundos, antes de cancelar la operación. Previene una ejecución casi infinita de la solicitud.
Nada más quería estar a la moda y jugar un rato con Javascript y Azure.

Espero que les sea de su total utilidad.

miércoles, 4 de enero de 2017

WSUS no sincroniza con SCCM. Error 503

Primer artículo del año. 

Este año se abre con una problemática muy habitual de WSUS y SCCM y guarda relación cuando el
rol de Software Update Point de SCCM no logra conectarse con el servicio de WSUS para gatillar la la actualización del catálogo de actualizaciones para los productos Microsoft seleccionados.

El servicio de WSUS provee una capa de servicios web que otros componentes, como SCCM, consumen para la interoperación.

El signo observado es el error de SCCM al sincronizar con el servicio. Al revisar el log SMS_WSUS_SYNC_MANAGER vamos a encontrar el siguiente mensaje:

Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.

Básicamente, lo que se indica es que al intentar acceder al servicio web, éste le responde con un error 503. 
Si hacen el ejercicio de entrar por el navegador a la URL del servicio, el resultado será el mismo.

Al abrir la consola de IIS y revisar los App Pool encontrarán que WsusPool se encontrará detenido:
fuente: Blogs Technet

Ahí está el problema. El App Pool se encuentra detenido. Tienes dos opciones: Inciarlo de forma manual y esperar a que nuevamente se caiga, o bien, solucionar el problema.

Me inclino por la segunda opción. El problema está en que el App Pool cuenta con memoria asignada insuficiente para atender las peticiones de los clientes. Cuando hay muchos clientes haciendo uso del servicio, se va a utilizar toda la memoria y el servicio se detendrá.

Para corregir el problema entrar a las opciones avanzadas y buscar el elemento Private Memory Limit (KB) y asignarle un valor mayor. Quizá unos 4 ó 5 GB estará bien.
Fuente: Blogs Technet

Advertencia: Al aumentar la memoria asignada, el uso de recursos del servidor aumentará y provocará una carga mayor sobre el mismo. Al acceder muchos clientes al mismo servidor para la descarga de actualizaciones, es altamente probable que la red sufra un alto impacto. Si esto ocurre, sugiero revisar la arquitectura de distribución de paquetes.

Una vez realizado el cambio, iniciar el App Pool y el servicio funcionará normalmente.

Saludos!