Calling service using SOAP message (.NET)

If you need to call a web service at low-level this is a good post for you.

For this purpose, you have to use HttpWebRequest and HttpWebResponse for treating the call. With Visual Studio’s auto-generated proxy for calling web methods of a web service hides the communication language between client and server. You do not have any control about the SOAP message generated. The only way is to call web methods using low-level protocol (HttpRequest)

Look an example below:

HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create("<<Url of your web method>>");

request.Headers["SOAPAction"] = <<web method URI>>;
request.ContentType = "text/xml;charset=\"utf-8\"";
request.Accept = "text/xml";
request.Method = "POST";

As you can see I have created the request using the information related to the web service. Next step is to build the SOAP Envelope

//Global variable for helping

static string soapEnvelope = @"<soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'><soap:Header></soap:Header><soap:Body></soap:Body></soap:Envelope>";

StringBuilder sb = new StringBuilder(soapEnvelope);
sb.Insert(sb.ToString().IndexOf("</soap:Header>"), String.Format("<AuthorizationToken xmlns=\"<<some URI>>"><Token>{0}</Token></AuthorizationToken>", authToken.Token));
sb.Insert(sb.ToString().IndexOf("</soap:Body>"), String.Format("<YOURMethod xmlns=\"<<some URI>>"><Parameter1>{0}</Parameter1><Parameter2>{1}</Parameter2></YOURMethod>", serviceName, methodName));

XDocument soapEnvelopeXml = XDocument.Parse(sb.ToString());

 

And finally, make the call

IAsyncResult result = request.BeginGetRequestStream((IAsyncResult asynchronousResult) =>
{

//inserting soap message in the request

using (Stream postStream = request.EndGetRequestStream(asynchronousResult))
{
soapEnvelope.Save(postStream);
postStream.Close();
}

request.BeginGetResponse(new AsyncCallback(asyncresult =>
{
XElement res = null;
HttpWebRequest request = (HttpWebRequest)asyncResult.AsyncState;
HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(asyncResult);
Stream streamResponse = response.GetResponseStream();
StreamReader streamRead = new StreamReader(streamResponse);
string responseString = streamRead.ReadToEnd();
XDocument res = XDocument.Parse(responseString);
XNamespace ns = "<<your namespace>>";

streamResponse.Close();
streamRead.Close();

response.Close();

XElement results = res.Descendants(ns + "<<your method name>>Response").FirstOrDefault();
if (results == null)
{
}
else
{
res =  results.Elements().FirstOrDefault();
}
}), request);
}, null);

 

Original solution : Non-string parameters between pages in Windows Phone

My last post was about an original solution using Dependency properties. This time another original solution passing non-string parameters between pages in Windows Phone.

In WPF or Windows Runtime (aka Windows Store apps) you can pass parameters between pages as objects and this means that you don’t have any problem to pass parameters. But, in Windows Phone only parameters as string is possible. For example:

NavigationService.Navigate(new Uri("yourpage.xaml?parameter1=value1&parameter2=value2,UriKind.Absolute));

As you can see, navigate in Windows Phone is like web pages. Only using Uri you can pass parameters, and this parameters need to be in string format.

Yes, this is a problem, because in some cases, we are using complex objects structures in a page and we would like to pass this same complex structure to another page.

A solution is to serialize the object with DataContract attribute. But, the problem is, no all object can be serialized and the Uri is length limited.

An original solution that I found on internet is using an extension for NavigationService and a static field to save the object to pass to another page. Look an example:

public static class NavigationExtensions {

private static object _navigationData = null;

public static void Navigate(this NavigationService service, string page, object data)

{

_navigationData = data;

service.Navigate(new Uri(page, UriKind.Relative));

}

public static object GetLastNavigationData(this NavigationService service)

{

object data = _navigationData;

_navigationData = null;

return data;

}

}

Simply clever, awesome.

Then, you can call on the source page

NavigationService.Navigate("mypage.xaml", myParameter);

And on the target page in the OnNavigatedTo

var myParameter = NavigationService.GetLastNavigationData();

Source:

How do I pass non-string parameters between pages in windows phone 8?

Solución original : Añadir un DependencyProperty propio a un control

Trabajando con Windows Phone 8 y concretamente con el control de mapas y el Toolkit de Windows Phone, que por cierto ahora es distinto que con Windows Phone 7 y 7.5, me he encontrado con el problema de que al momento de colocar Pushpins de forma dinámica usando una lista la propiedad ItemsSource de MapItemsControl no es Bindable.

Ante este problema una solución es asignar la lista directamente por código y con eso acabamos. Solución rápida y simple.

Pero si buscamos ser coherentes con lo que es o son las aplicaciones WPF de separar lo que es la lógica de la interfaz de usuario (XAML) y que por eso existe el patrón MVVM esta solución no es pura 🙂

Encontré una solución original que no solo sirve en este caso sino que también en cualquier otro. Crear tu propio propiedad Bindable y asignarlo a cualquier control como si fuera nativo.

El enlace lo encontráis al final de este post pero yo os lo cuento un poco por encima.

Si creas una clase estática con un Dependency Property luego puedes usar esa propiedad (que también debes hacerla estática) en cualquier control WPF. El truco está en programar el método que se debe ejecutar cuando cambia la propiedad Dependecy Property.

Aquí tienes la sintaxis del MSDN:

public static DependencyProperty Register(
string name,
Type propertyType,
Type ownerType,
PropertyMetadata typeMetadata,
ValidateValueCallback validateValueCallback
)

De esta forma puedes conseguir leer las propiedades del control al cual te “hospedas” y asignar valores en código.

private static void OnPushPinPropertyChanged(DependencyObject d,
DependencyPropertyChangedEventArgs e)
{
UIElement uie = (UIElement)d;
var pushpin = MapExtensions.GetChildren((Map)uie).OfType<MapItemsControl>().FirstOrDefault();
pushpin.ItemsSource = (IEnumerable)e.NewValue;
}

 

Aquí tenéis el ejemplo completo: MVVM Windows Phone 8 – adding a collection of pushpins to a map

Si teneis alguna duda me lo preguntáis.

DataContractSerializer no deserialitza correctament

Hi poden haver moltes raons perquè el DataContractSerializer no deserialitzi bé. Però he pensat que era el millor títol que podia donar ja que en realitat és un problema que sembli exactament el que diu: Que no deserialitza correctament.

Però en realitat no és així, el problema està en què no sabem a vegades com funciona del tot.

Aquesta és la instrucció:

Countries = MVVMUtils.DataContractDeserializeObject<Countries>(e.Result.ToString());

I aquesta és la classe Countries

[CollectionDataContract(Namespace="")]
public class Countries : List<Country> { }

[DataContract(Namespace = "")]
public class Country {
[DataMember]
public string cty_key { get; set; }

[DataMember]
public string cty_code { get; set; }

[DataMember]
public string cty_idd_code { get; set; }
}

I aquest el fitxer XML que volem deserialitzar

<Countries xmlns="">
<Country>
<cty_key>8C445CE2-5AF6-48B6-BDDA-B10B77724566</cty_key>
<cty_code>United States</cty_code>
<cty_idd_code>1</cty_idd_code>
</Country>
<Country>
<cty_key>18227E69-725D-4A17-8245-4E2683094ED0</cty_key>
<cty_code>Canada</cty_code>
<cty_idd_code>1</cty_idd_code>
</Country>
<Country>

Si observes bé les propietats no estan ordenades alfabèticament. Aquest XML s’ha extret d’un altre sistema de serialització. Si s’hagués fet amb el DataContractSerializer estarien completament ordenades.

Aquest és el problema.DataContractSerializer necessita que les propietats estiguin ordenades i quan això no és possible llavors hem de indicar un atribut més al model : Order

Per tant el model hauria de ser:

[CollectionDataContract(Namespace="")]
public class Countries : List<Country> { }

[DataContract(Namespace = "")]
public class Country {
[DataMember(Order=1)]
public string cty_key { get; set; }

[DataMember(Order = 2)]
public string cty_code { get; set; }

[DataMember(Order = 3)]
public string cty_idd_code { get; set; }
}

Més informació:
Why needs DataContractSerializer alphabetically sorted XML?

Aspectos fundamentales de la programación ASP.NET (parte 5)

Quinta y ultima parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte,la segunda, la tercera y la cuarta.

Ejecución de una página ASP.NET

Parte fundamental para entender como funciona ASP.NET y como puede afectar esto a tu forma de programar tus aplicaciones web. Ya he dicho antes que ASP.NET se planteó que la programación fuera “Event driven” que significa que cada página genera eventos.

Entender cual es el orden de generación de los eventos es esen-cial para programar correctamente.

Para verlo hablamos del ciclo de vida de la página. Aquí vas a encontrar un resumen del ciclo. Cuando llega una petición :

Construir el árbol de controles

Verás que las páginas en ASP.NET utilizan controles de servidor y esos controles están ordenados en forma de árbol tal y como ya pasa en las aplicaciones Winforms.

Evento Init

El primer evento que se ejecuta en una página es el Init. Tienes creados los controles pero estos aún no tienen los valores.

Cargar el estado y los datos recibidos

Aquí es donde se guardan los datos en los controles. En el caso que la petición sea un submit de un formulario previamente enviado también se guardaran estos valores nuevos.

Evento Load

El evento más comúnmente utilizado. Es donde tienes acceso a los valores en los controles. Aquí es importante no hacer inicializaciones sin antes comprobar que no se está realizando una petición Postback. Postback es la forma que tenemos para llamar las peticiones que envían información al servidor. Es decir, las llamadas creadas mediante una acción del usuario. No son Postback cuando la petición es directa mediante la barra de navegación del explorador o mediante un link simple (etiqueta a) de la página.

Evento acción del usuario / evento cambios en controles

Si se trata de una petición Postback quiere decir que el usuario ha realizado una acción, como por ejemplo el clic de un botón, esta acción es un evento que se debe tratar. También pueden ocurrir otros eventos que no tienen por que ser acciones de botones. Pueden ser eventos producidos por el cambio en una lista, el cambio en un texto. Este tipo de eventos también se tratan.

Evento LoadComplete

El evento anterior a procesar la página para su entrega al cliente.

Guardar el estado

Una de las características del ASP.NET es la utilización en cada página de una variable de estado denominada ViewState que permite recuperar el estado en que se ha enviado inicialmente la página. Fíjate que sin el ViewState no podrías saber que eventos de modificación se han producido.

Renderizar los controles

Otra característica de ASP.NET es la utilización de controles de servidor. Estos controles se caracterizan por empezar en “asp:”, tener un ID y un runat=”server”. Estos controles no pueden ser interpretados por ningún navegador ya que ellos solo interpretan Html. Por eso antes de enviar necesitas transformar los controles de servidor en Html.

Evento Unload

Ultimo evento en el ciclo. Se pueden liberar recursos ocupados en el proceso.

La siguiente tabla tienes todos los eventos que se generan en el ciclo de ejecución de una página. Al lado tienes los que se generan en cada uno de los controles.

Más cosas de los eventos

Los eventos producidos por cambios en los controles siempre se ejecutan cuando hay un Postback. Recuerda que un Postback es cuando llega una solicitud al servidor producido por una acción del cliente. Esta acción puede ser la pulsación de un botón como también la selección de otro elemento de una lista.

Algunos controles tienen una propiedad AutoPostBack que poniéndola a cierto provocas que cualquier cambio produzca esta acción.

Puedes tener varios controles en una misma página que generen eventos de modificación. El orden en el servidor no esta establecido y por tanto es aleatorio.

Como ya te he dicho antes sin el ViewState no se pueden generar eventos de modificación. El ViewState en los controles se puede deshabilitar. Páginas que sean demasiado pesadas puedes quitarle este peso deshabilitando el ViewState de algunos controles o incluso de toda la página.

Millorar ObservableCollection

A StackOverflow s’ha publicat un exemple de com es pot fer un ObservableCollection més efectiu.

ObservableCollection és una llista genèrica que implementa INotifyPropertyChanged i per tant avisa a la UI dels canvis que hi ha dins la llista. Bàsicament si s’afegeix o es borra algun element.

El problema és que no és Thread safe ni tampoc Thread Affinity. Per tant, quan un Thread que no és l’UI actualitza aquesta llista es genera una excepció.

El segon, és que per cada operació d’afegir o borrar es llencen els events corresponent per notificar a UI del canvi sense l’opció de poder-los agrupar i que només es faci una vegada la notificació després d’un conjunt d’operacions.

Consulteu l’exemple que és força interessant.

Fast performing and thread safe observable collection

 

 

Aspectos fundamentales de la programación ASP.NET (4rta parte)

Cuarta parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte,la segunda y la tercera.

ASP.NET Modelo en objetos

Muchos son los objetos utilizados en el procesado de ASP.NET pero hay uno que siempre tiene que estar presente en tu memo-ria ya que lo trae prácticamente todo. HttpContext es la clase que representa una petición y su res-puesta a un recurso de la web. Context es la propiedad de la clase Page que te permite tener acceso a la instancia de la clase generada por la petición. También puedes acceder por la pro-piedad estática Current de la clase HttpContext.

Page.Context HttpContext.Current

El objeto Current tiene propiedades tan importantes y utiliza-das como:

• Request : Representa la petición. Es una instancia de HttpRequest. Puedes acceder a la cadena Url como a las cookies.
• Response: Representa la respuesta que debe generar el servidor. Es una instancia de la clase HttpResponse. Dispone de métodos de redireccionamiento a otras UR-L’s y métodos de escritura directa por el canal de salida.
• User: Representa el usuario autentificado que realiza la consulta. Es la implementación de una interfaz genérica IPrincipal que puedes consultar el nombre de usuario y el rol asociado.
• Server: Representa el servidor. Es una instancia de HttpServerUtility. Encuentras métodos para transferir la solicitud a otra página y para recuperar la dirección físi-ca dentro del disco de un recurso.
• Session: Objeto que puedes guardar valores que sirven para mantener el estado entre peticiones.
• Profile: Objeto que te permite leer y guardar valores que sirven para mantener el estado entre sesiones.
• Items: Diccionario de objetos que se guardan durante la solicitud.
• Application: Diccionario global en todas las solicitudes a la aplicación. Compartido por todos los usuarios.

Web.config

El archivo de configuración de las aplicaciones web. Este ar-chivo se encuentra en la raíz de la aplicación y es básico para el correcto funcionamiento. En este archivo que esta estructurado en formato XML se en-cuentran cosas tan importantes como:

• Cadenas de conexiones: Las cadenas de conexión a las bases de datos que utiliza la aplicación web.
• Autorizaciones: Permisos aplicados a carpetas o re-cursos de la aplicación web.
• Autenticaciones: Como se deben autenticar los usua-rios. También puede contener usuarios y contraseñas encriptadas.
• Propiedades de configuración de la aplicación: Una colección de claves y valores que se utilizan en la aplicación.
• Perfiles: Para mantener el estado entre sesiones.
• Proveedores de usuarios: ASP.NET tiene su propio gestor de usuarios. Puedes modificarlo para adaptarlo.
• Proveedores de roles: ASP.NET tiene su propio ges-tor de roles. Puedes modificarlo para adaptarlo.

La herencia en web.config

Los ficheros de configuración pueden estar en cualquier sub-carpeta de la misma. Posibilita así una herencia de configura-ciones donde se puede romper en cualquier momento e incluso sobreescribirlo. Así podrías tener una carpeta completamente pública y dentro una carpeta completamente privada. El archivo base del web.config es el machine.config. Este ulti-mo tiene su ámbito en todo el servidor. Uno de los cambios en-tre ASP.NET 3.5 y 4.0 es que web.config reduce significativa-mente su tamaño ya que la mayoría han pasado al machi-ne.config. Naturalmente puedes sobreescribirlo añadiéndolo en el web.config.

Mouse events Grid Control

In this article is explained How to handle mouse event on entire Grid Control in WPF or Windows Store apps or Windows Phone apps.
It is really simple and I would not write anything about that in my blog if I had not had problems with this simple action in my Windows Phone project that I am working.
At the bottom of this article it says the gold rule:
In order for this to work you need to always set the Grid Background, either to transparent or to whatever you like, because if its null the event isn’t triggered…

And that’s true, remember to put a background on your Grid, by default could be set to null.

Aspectos fundamentales de la programación ASP.NET (3era parte)

Tercera parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte y la segunda.

Cookies

Una de las formas que tienes de poder conservar el estado en tus peticiones Http es utilizando Cookies. Ya he hablado de que el protocolo Http no tiene estado, significa que cada petición es independiente de la anterior, e implica que para cada petición necesitas enviar toda la información necesaria para que el servidor pueda recordar quien eres y que habías hecho para saber que quieres hacer. Eso es lo que denominamos mantener el estado.

Las cookies son ficheros de texto simples que se guardan en el ordenador del cliente y se adjuntan a las peticiones Http. Se habla mucho de las cookies y del peligro de seguridad que suponen. Al ser una información que viaja por la red y que se queda guarda en el cliente no la puedes utilizar para almacenar información importante o susceptible para el buen comportamiento de tus aplicación web.

Normalmente se utilizan las cookies para ayudar a la aplicación web saber que páginas has estado visitando antes.

Internet Information Server (IIS)

Toda aplicación web ya sea estática o dinámica necesita de un servidor web para poder entregar las páginas. En Microsoft tenemos el IIS. El IIS es el responsable de entregar las páginas que se solicitan mediante una petición Http. En el caso de ASP.NET necesita la instalación del Framework para que el IIS sepa interpretar los archivos con extensión .aspx.

Microsoft Windows Server 2003 trabaja con IIS 6, Microsoft Windows Server 2008 con IIS 7. Existe un cambio importante entre las dos versiones.

La aplicación web se guarda en una carpeta del servidor que por defecto es wwwroot en la unidad de instalación del sistema operativo.

 

Directorios virtuales

Configura una carpeta para que funcione como una aplicación web. Una aplicación web funciona mediante un pool de aplicaciones que puede ser distinto para cada web permitiendo aislar la web de todas las demás.

Procesado ASP.NET

Como se comporta el IIS ante una petición a una página ASPX sirve para entender un poco más como funciona la lógica de proceso ASP.NET.

Ya he hablado que existen dos versiones actualmente del IIS y que habían cambios importantes, con la siguiente explicación espero poder aclarar en que se basan.

Procesado en IIS6 / IIS7 Modo clásico

El IIS tiene la responsabilidad para cada solicitud de comprobar restricciones IP, permisos de lectura y ejecución de la página solicitada y si es de acceso anónimo o necesita una autenticación. En IIS 6 solo puedes gestionar la autenticación por Windows.

Después la solicitud es recogida por el proceso de trabajo ASP.NET donde se evalúa la autorización de acceso al recurso solicitado, si es necesario una autenticación por formularios, sobreescritura de la URL, recuperación de la sesión, gestión de la caché, servicios personalizados, creación de los objetos ASP.NET. Todo esto es lo que se hace en la Pipeline.

En la primera solicitud se carga el ensamblado en el dominio de la aplicación y se crea una instancia del objeto. Recuerda que ya he comentado que en .Net todo es un objeto incluso las páginas en ASP.NET.

Con la instancia del objeto creado se procesa y se genera una respuesta.

El ensamblado se queda guardado en el dominio de la aplicación para posteriores peticiones. De esta forma las peticiones siguientes serán más rápidas.

Procesado en IIS7 Modo integrado

En la nueva versión del IIS hay módulos ASP.NET integrados que permite coger más responsabilidad en el procesado de las páginas ASP.NET. Ahora el Pipeline está en el IIS, de esta forma la autorización, autenticación o caché de salida sirve para páginas estáticas, páginas php, etc.

También IIS7 permite la autenticación por formularios.

ASP.NET 4 Versión IIS 7.5

Con el Microsoft Windows Server 2008 R2 aparece una versión mejorada del 7. El IIS 7.5 tiene la novedad que junto a ASP.NET versión 4 del .Net Framework puedes programar el auto arranque de las aplicaciones web hospedadas en el IIS. Tal y como he hablado antes las primeras peticiones cargan el ensamblado en el dominio de la aplicación, esto supone claro una perdida de tiempo. Para evitarlo tienes el auto arranque.

Para ello debe indicar qué pool de aplicaciones son arrancados automáticamente. Tienes que editar el fichero de configuración applicationhost.config

<applicationPools>

<add name=”MyApplicationPool” startMode=”AlwaysRunning” />

</applicationPools>

o puedes indicar individualmente aplicaciones para que se auto carguen al inicializar el IIS.

<sites>

<site name=”MySite” id=”1″>

<application path=”/” serviceAutoStartEnabled=”true” serviceAutoStartProvider=”PrewarmMyCache” >

<!– Additional content –>

</application>

</site>

</sites>

<!– Additional content –>

<serviceAutoStartProviders>

<add name=”PrewarmMyCache” type=”MyNamespace.CustomInitialization, MyLibrary” />

</serviceAutoStartProviders>

El funcionamiento es muy simple: En el momento que IIS arranca por primera vez o se reinicia un pool de aplicaciones IIS 7.5 envía una solicitud al objeto CustomInitialization para que ejecute el método PreLoad. En este momento las solicitudes quedan bloqueadas.

Después se carga el ensamblado en el dominio de la aplicación y se libera el bloqueo.

public class CustomInitialization :

System.Web.Hosting.IProcessHostPreloadClient

{

public void Preload(string[] parameters)

{

// Perform initialization.

}

}

La interfaz IProcessHostPreloadClient permite la implementación del método PreLoad utilizada en IIS 7.5 como punto de entrada en la pre carga de una aplicación web.

Más cosas en la cuarta parte de este post.

Gracias

Windows Phone : TextBlock justify doesn’t work

TextBlock is the control to used for writing text on the screen. It is really simple and easy. But, I don’t know why, justify the text using the TextAlignment attribute doesn’t work.

Luckily we have the RichTextBox control.

 

<RichTextBox TextAlignment=”Justify” IsReadOnly=”True”>
<Paragraph>
Put your text here
</Paragraph>
</RichTextBox>

 

Happy coding.