A la hora de integrar servicios tanto en SharePoint 2010 On-Premise como en su homólogo en la nube  (dentro de Office 365), uno de los escenarios que emerge con fuerza es el de integrar servicios WCF publicados en Azure y consumirlos en ambos entornos a través de jQuery que permite superar la restricción que tenemos en SharePoint Online (SPO) de llamar a servicios dentro de soluciones Sandbox puras. La idea de este primer artículo es mostrar como consumir un servicio WCF publicado en Azure aprovechando el WCF Service Web Role usando jQuery:

• Iniciamos Visual Studio y creamos un proyecto de tipo Windows Azure Project.
• A continuación elegimos como role el de C# –> WCF Service Web Role.

• En el ejemplo de integración, vamos a crear y publicar un simple servicio WCF que permite sumar dos números introducidos por el usuario. Una vez creada la estructura del proyecto, editamos la  interfaz que se crea por defecto y la renombramos ISumService. Configuramos la interfaz de acuerdo al siguiente código en el que definimos tanto el contrato del servicio (ServiceContract) como las operaciones que forman parte de él (OperationContract) que tenemos que decorar adecuadamente (atributo WebInvoke) para que el servicio pueda ser llamado mediante jQuery lo que en este caso se traduce en que tanto la llamada como la respuesta realizada serán en formato JSON.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Runtime.Serialization;

   5: using System.ServiceModel;

   6: using System.ServiceModel.Web;

   7: using System.Text;

   8:  

   9: namespace SumServiceWebService

  10: {

  11:     [ServiceContract]

  12:     public interface ISumService

  13:     {

  14:         [OperationContract]

  15:         [WebInvoke(Method = "POST",

  16:             BodyStyle = WebMessageBodyStyle.WrappedRequest,

  17:             RequestFormat = WebMessageFormat.Json,

  18:             ResponseFormat = WebMessageFormat.Json,

  19:             UriTemplate = "sum")]

  20:         int SumNumbers(int iNumber1, int iNumber2);  

  21:     }

  22: }

• Una vez definida la implementación de la interfaz y los métodos correspondientes, el siguiente paso es definir adecuadamente la clase que contiene la lógica del servicio y que sigue dicha interfaz. Como véis, la clase SumService implementa la interfaz ISumService y además la decoramos con los atributos ServiceBehavior y AspNetCompatibilityRequirements que especifica el modo de compatibilidad ASP.NET del servicio.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Runtime.Serialization;

   5: using System.ServiceModel;

   6: using System.ServiceModel.Web;

   7: using System.Text;

   8:  

   9: //Espacios de nombres necesarios

  10: using System.ServiceModel.Activation;

  11:  

  12:  

  13: namespace SumServiceWebService

  14: {

  15:  

  16:     [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

  17:     [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

  18:     

  19:     public class SumService : ISumService

  20:     {

  21:         public int SumNumbers(int iNumber1, int iNumber2)

  22:         {

  23:             int iResult= iNumber1 + iNumber2;

  24:             return iResult;

  25:         }

  26:     }

  27: }

• El siguiente paso a realizar es configurar adecuadamente el Web.Config del servicio para exponerlo de forma que pueda ser llamado desde jQuery sin problemas. Esto lo modelamos a través del correspondiente behavior en el que básicamente definimos el tipo de binding (webHttpBinding) y el contrato ya indicado en la definición de la interfaz.

   1: <?xml version="1.0"?>

   2: <configuration>

   3:     <system.diagnostics>

   4:         <trace>

   5:             <listeners>

   6:                 <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">

   7:                     <filter type=""/>

   8:                 </add>

   9:             </listeners>

  10:         </trace>

  11:     </system.diagnostics>

  12:     <appSettings/>

  13:     <connectionStrings/>

  14:     <system.web>

  15:         <compilation debug="true" targetFramework="4.0">

  16:         </compilation>

  17:         <!--

  18:           The <authentication> section enables configuration 

  19:           of the security authentication mode used by 

  20:           ASP.NET to identify an incoming user. 

  21:         -->

  22:         <authentication mode="Windows"/>

  23:         <!--

  24:            The <customErrors> section enables configuration 

  25:            of what to do if/when an unhandled error occurs 

  26:            during the execution of a request. Specifically, 

  27:            it enables developers to configure html error pages 

  28:            to be displayed in place of a error stack trace.

  29:  

  30:            <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">

  31:              <error statusCode="403" redirect="NoAccess.htm" />

  32:              <error statusCode="404" redirect="FileNotFound.htm" />

  33:            </customErrors>

  34:         -->

  35:         <pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"/>

  36:         <machineKey decryption="AES" decryptionKey="0CA3EFAF0F7A5E7A62681C0BF656EE0ECE31ACEE3E1023BA3FAD20EA5F199DE8" validation="SHA1" validationKey="FCF71343240C6E081AF3C9F3C10C3F3C11B903359DE62168764FF0DCE537184F0535D5D9AD66DEDC97DC1ABFF7FA540B4DFD82E5BB196B95D15FF81F75AD5328" />

  37:     </system.web>

  38:     <!-- 

  39:         The system.webServer section is required for running ASP.NET AJAX under Internet

  40:         Information Services 7.0.  It is not necessary for previous version of IIS.

  41:     -->

  42:     <system.serviceModel>

  43:         <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>

  44:         <services>

  45:             <service behaviorConfiguration="SumServiceWebService.CloudWCFServiceBehavior"

  46:                      name="SumServiceWebService.SumService">

  47:                 <endpoint address=""

  48:                           binding="webHttpBinding"

  49:         behaviorConfiguration="JsonEndpointBehavior"

  50:         contract="SumServiceWebService.ISumService" />

  51:                 <endpoint address="mex"

  52:                           binding="mexHttpBinding"

  53:                           contract="IMetadataExchange" />

  54:             </service>

  55:         </services>

  56:         <behaviors>

  57:             <serviceBehaviors>

  58:                 <behavior name="SumServiceWebService.CloudWCFServiceBehavior">

  59:                     <!--The useRequestHeadersForMetadataAddress behavior is contained in the KB981002- WCF: Hotfix rollup upodate. This behavior is required for WCF to correctly serve metadata when behind a load balancer (which is the case in Windows Azure)-->

  60:                     <useRequestHeadersForMetadataAddress>

  61:                         <defaultPorts>

  62:                             <add scheme="http"

  63:                                  port="81"/>

  64:                             <add scheme="https"

  65:                                  port="444"/>

  66:                         </defaultPorts>

  67:                     </useRequestHeadersForMetadataAddress>

  68:                     <serviceMetadata httpGetEnabled="true"/>

  69:                     <serviceDebug includeExceptionDetailInFaults="true"/>

  70:                 </behavior>

  71:             </serviceBehaviors>

  72:             <endpointBehaviors>

  73:                 <behavior name="JsonEndpointBehavior">

  74:                     <webHttp/>

  75:                 </behavior>

  76:             </endpointBehaviors>

  77:         </behaviors>

  78:  

  79:     </system.serviceModel>

  80:  

  81: </configuration>

• En teoría, con los pasos anteriores ya hemos acabado. De hecho, si publicamos el servicio en Windows Azure de forma directa a través de Visual Studio o a través del portal de Windows Azure indicando dónde se encuentran el paquete a publicar y el archivo de configuración lo tendremos accesible y listo para su consumo. Si probamos a consumir el servicio desde una página HTML, todo irá sobre ruedas…pero no ocurre lo mismo si lo hacemos desde SharePoint por el famoso “Cross-Domain issue” que básicamente se traduce en el bloqueo seguro que realizan los navegadores cuando interpretan que se están realizando llamadas entre dominios de aplicación diferentes como es nuestro caso.
• La solución para salir del paso, si se os presenta este problema, pasa por añadir un archivo “Global.asax” a nuestro proyecto de servicio WCF y permitir que se puedan realizar llamadas entre dominios diferentes superando el bloqueo introducido por el navegador. Para ello, añadimos en el método Application_BeginReguest() de Global.asax las siguientes cabeceras en la respuesta del servicio:

   1: protected void Application_BeginRequest(object sender, EventArgs e)

   2: {

   3:     HttpContext.Current.Response.AddHeader(

   4:         "Access-Control-Allow-Origin", "*");

   5:     HttpContext.Current.Response.AddHeader(

   6:         "Access-Control-Allow-Methods","GET, POST");

   7:     HttpContext.Current.Response.AddHeader(

   8:         "Access-Control-Allow-Headers","Content-Type, Accept");

   9:     HttpContext.Current.Response.AddHeader(

  10:         "Access-Control-Max-Age","1728000");

  11:  

  12: }

• Actualizamos el servicio publicado en Azure, y ahora si que funcionará sin problemas las llamadas al mismo desde código jQuery. En mi caso, el código jQuery que llama al servicio y procesa la respuesta del mismo es el siguiente:

   1: <script type="text/javascript" src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js"></script>

   2: ript type="text/javascript">

   3: TA[

   4:  var HolJQuerySPOnPrem = {

   5:      // This will hook up elements on the page.

   6:      Initialize: function () {

   7:          $("#Sum").click(null, function () {

   8:              var Number1 = parseFloat($("#Number1").val());                     

   9:              var Number2 = parseFloat($("#Number2").val());

  10:              // make a json string - you SHOULD use a library

  11:              var data = '{ "iNumber1" : ' + Number1 + ', "iNumber2": ' + Number2 + '}';

  12:              // send via ajax

  13:              alert("Llamando al servicio de Azure");      

  14:              $.ajax({

  15:                  data: data,

  16:                  cache: false,

  17:                  success: HolJQuerySPOnPrem.ReceiveData,

  18:                  error: HolJQuerySPOnPrem.ReceiveDataError,

  19:                  type: "POST",

  20:                  dataType: "json",

  21:                  contentType: "application/json; charset=utf-8",

  22:                  url: "http://sumservice.cloudapp.net:8085/SumService.svc/sum"

  23:              }); 

  24:              return false;

  25:          });

  26:      },

  27:  

  28:      // When the response arrives, update the answer

  29:      ReceiveData: function (data, status, xhr) {

  30:          $("#result").text(data.toFixed(2));

  31:          alert("Operación realizada con éxito");

  32:      },

  33:      ReceiveDataError: function () {

  34:          alert("Operación fallida");

  35:      }

  36:  };

  37:  

  38:  // TODO: 5.5.4 - On Load event; called before the page contents are loaded. 

  39:  $(document).ready(HolJQuerySPOnPrem.Initialize);         

  40: //]]>

  41: ript>

  42: le="margin: 15px;">

  43: :<input type="text" id="Number1" style="position: absolute; left: 150px;" />

  44: </div>

  45: le="margin: 15px;">

  46: :<input type="text" id="Number2" style="position: absolute; left: 150px;" />

  47: </div>

  48: le="margin: 15px;">

  49: id="Sum">Sumar</button>

  50: </div>

  51: le="margin: 15px;">

  52: o:<span id="result" style="position: absolute; left: 150px;" ></span>

  53: </div>

• Sin más, para comprobar que todo está operativo nos vamos a nuestro sitio de SharePoint de trabajo y en una página de WebParts insertamos por ejemplo una Content Editor WebPart en la que añadimos el código anterior.
• Finalmente, probamos que la llamada al servicio funciona y se devuelve el resultado esperado.

Varios comentarios finales respecto a la integración:

• En un entorno de SharePoint On-Premise, la integración funciona sin problemas tanto en IE 8 como en FireFox 3.X.
• En un entorno SPO, la integración funciona correctamente en Google Chrome, pero no en IE9 y FireFox 3.X…la guerra de los navegadores vuelve a escena.

[Post original publicado por Juan Carlos Gonzalez en su blog; http://geeks.ms/blogs/ciin]

Siguiendo con la serie de posts en torno a la integración de SharePoint y Azure, en esta ocasión vamos a ver un ejemplo sencillo en el que integremos una página ASP.NET publicada en Windows Azure dentro de un sitio de SharePoint. Antes de empezar os recuerdo los posts previos de la serie:

• SharePoint & Azure: Alternativas de integración (I)!
• SharePoint & Azure: Alternativas de integración (II)!
• SharePoint & Azure: Alternativas de integración (III)!

Para integrar una página ASP.NET publicada en Azure dentro de un sitio de SharePoint los pasos a seguir son bastante sencillos:

• En primer lugar, necesitamos la Url de la página web a integrar. La obtenemos a través del portal de administración de Windows Azure.
• En segundo lugar, creamos en nuestro sitio de trabajo de SharePoint 2010 una página de WebParts e insertamos en la misma una WebPart de tipo Page Viewer.
• Configuramos la WebPart para que muestre la página ASP.NET publicada en Azure. Para ello, es suficiente con especificar la Url de dicha página.

• Finalmente, salimos del modo de edición de la página y comprobamos que funciona correctamente en el iFrame que define la WebPart de tipo Page Viewer.

[Post original publicado por Juan Carlos Gonzalez en su blog; http://geeks.ms/blogs/ciin]

Siguiendo con la serie de posts sobre las alternativas de integración que existen entre SharePoint & Azure, en esta ocasión y continuando con los artículos previos quería completar los patrones de integración introducidos con los que se detallan en este artículo de Todd Baginski muy completo y recomendable. Para finalizar, este breve post, os recuerdo los dos post previos sobre la misma temática:

• SharePoint & Azure: Alternativas de integración (I)!
• SharePoint & Azure: Alternativas de integración (II)!

[Post original publicado por Juan Carlos Gonzalez en su blog; http://geeks.ms/blogs/ciin]

Siguiendo con la serie de artículos en torno a las alternativas de integración entre SharePoint y Azure, en esta ocasión vamos a seguir viendo que otras posibilidades tenemos desde una u otra plataforma:

• Desde SharePoint:
  • Podemos usar el modelo de objetos en cliente de SharePoint (.NET, Silverlight o ECMAScript) para interactuar con datos de Windows Azure.
  • A través de los Business Connectivity Services (BCS) para modelar la integración de datos de Azure en SharePoint por medio de tipos de contenido externos y listas externas.
  • Integración de servicios de Azure o de datos a través de WebParts de SharePoint.
  • Usando Silverlight para construir interfaces de usuario ricas que tiren de servicios o datos de Azure.
  • A través de las búsquedas federadas de SharePoint que permitan incluir datos de Azure.
• Desde Windows Azure:
  • Uso de los servicios web de SharePoint para interactuar con sitios, listas, usuarios y otros elementos de la plataforma.
  • Uso de la API REST de SharePoint para interactuar con datos de listas de SharePoint.

Un resumen de estas opciones de integración de Azure y SharePoint es el siguiente:

Si nos centramos en escenarios de integración, surgen los siguientes:

• Escenario 1: Llamar a código externo:

• Escenario 2: Acceso a datos externos:

• Escenario 3: Exponer datos de SharePoint al exterior

Y hasta aquí llega este segundo artículo sobre alternativas de integración entre SharePoint y Azure.

[Post original publicado por Juan Carlos Gonzalez en su blog; http://geeks.ms/blogs/ciin]

Sin duda, las dos plataformas de moda del momento son SharePoint por un lado y Windows Azure por otro…y claro, la pregunta que a muchos les puede rondar por la cabeza es que posibilidades de integración entre ambas tenemos

• Mediante el uso de iFrames que nos permite integrar de forma sencilla páginas ASP.NET publicadas en Windows Azure. Para ello basta con añadir en una content editor web part lo siguiente:

   1: <IFRAME id=“azureTest" src="http://fabrikamhockeyazure.cloudapp.net/Default.aspx" scrolling="auto">

   2: </IFRAME>

• En cuanto a puntos fuertes y débiles de esta aproximación:
  • Ventajas:
    • Integración simple y ligera.
    • No se requiere código.
    • No hay que desplegar nada en SharePoint.
  • Desventajas:
    • Se pierden las personalizaciones propias de SharePoint.
    • La integración es poco profunda.
    • No se distribuye vía un paquete estándar de SharePoint.
• A través de un servicio o de datos hospedados que nos permitan integrar de forma sencilla datos que se encuentran en Azure (en SQL Azure) de forma directa (usando el servicio de BCS por ejemplo) o mediante un elemento intermediario (un servicio web fuera de la nube que recupere datos de SQL Azure. En lo que a ventajas e inconvenientes de esta aproximación:
  • Ventajas:
    • Uso de servicios existentes.
    • Extensivo en datos/servicios.
    • Modelo de programación directo.
  • Desventajas:
    • Dependencia del servicio / de los datos.
• A través de servicios personalizados publicados en Azure con las siguientes ventajas e inconvenientes:
  • Ventajas:
    • La integración permite generar artefactos de SharePoint (WebParts, aplicaciones Silverlight).
    • Múltiples puntos de entrada.
    • Mayor control.
  • Inconvenientes:
    • Necesidad de administrar los servicios desplegados.
    • Se necesita tirar más código.
• Mediante el uso de la DataFormWebPart, podemos a partir de un origen de datos mostrar información de por ejemplo una BD SQL Azure.

Y hasta aquí llega este primer post sobre la integración de SharePoint y Azure.

[Post original publicado por Juan Carlos Gonzalez en su blog; http://geeks.ms/blogs/ciin]