PDF de programación - CompartiMOSS 29

Nº29 septiembre 2016

REVISTA ESPECIALIZADA EN TECNOLOGÍAS MICROSOFT

Entrevista
Darwin Castro
Marín

SharePoint
y Azure
WebJobs

Power BI:
Conexión con
SQL Server y
Oracle

Nueva Ex-
periencia de
Usuario en
Listas en SPO

1

EnrContenido
03
Editorial
07

04

Enmarcha: Como facilita el Unit
Testing en SharePoint / Office 365

Manejo de Gateways con Power BI

11

15

Microsoft Bot Framework para
automatizar conversaciones
25

Integra cualquier sistema en tu PowerApp
con Microsoft Flow y Custom API: Agenda
de usuarios sobre MongoDB

35
Xamarin Forms y SharePoint OnPre-
mises
44
Power BI: Conexión con SQL Server
y Oracle

50

Custom Extensibility Handlers para
el framework de provisioning del PnP

20

SharePoint y Azure WebJobs
33

Entrevista Darwin Castro Marín
38
Azure Task Scheduler Planifica tus
procesos en Azure
47

Azure Infomation Protection

Nueva Experiencia de Usuario en
Listas en SPO

54

57

Gestión de datos no relacionales
en Microsoft Azure

Flujos y eventos para Project
Server con Nintex

02
Staff

CompartiMOSS es una pu-
blicación independiente de
distribución libre en forma
electrónica. Las opiniones
aquí expresadas son de es-
tricto orden personal, cada
autor es completamente
responsable de su propio
contenido.

DIRECCIÓN GENERAL

• Gustavo Velez
• Juan Carlos Gonzalez
• Fabian Imaz
• Alberto Diaz

DISEÑO Y DIAGRAMACIÓN
• Santiago Porras Rodríguez

Contacte con
nosotros

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

BLOGS
http://www.gavd.net
http://geeks.ms/blogs/jcgonzalez
http://blog.siderys.com
http://geeks.ms/blogs/adiazmartin

REDES SOCIALES
Facebook:
http://www.facebook.com/group.
php?gid=128911147140492
LinkedIn:
http://www.linkedin.com/groups/
CompartiMOSS-3776291
Twitter:
@CompartiMOSScom

2

03 Editorial

Siguiendo con el proceso incesante de renovación e innovación que nos hemos impuesto desde el principio en Comparti-
MOSS, continuamos en este número integrando nuevas tecnologías de Microsoft en nuestro contenido. Como tal, damos la
bienvenida a Gastón Cruz que se está encargando de manejar la sección correspondiente a BI (y, por supuesto, de Power BI).
Estamos seguros que la revista continuará su ruta informativa con sus aportes y queremos animar a todos nuestros lectores
que quieran escribir artículos sobre BI a que tomen contacto con Gastón directamente, o por intermedio de la revista misma
([email protected]).
Azure toma cada vez más impulso, y lo vemos no solo en los resultados financieros que Microsoft presentó hace unas cuan-
tas semanas, sino también en CompartiMOSS. Cuando hace un año no publicábamos más de un artículo por número, ahora
prácticamente la mitad de la revista contiene información relacionada directa o indirectamente con Azure. La nube es la
gran apuesta del momento, no solo para Microsoft, sino para todos los que trabajamos profesionalmente con herramientas
informáticas. Solamente el futuro dirá como se van a seguir desarrollando la nube con Azure y Office 365, pero por el mo-
mento parece que es, sin ninguna duda, el camino a seguir.
Esperamos que la información de este número les parezca tan interesante como de costumbre, y que se diviertan leyendo
los artículos, tanto como los autores lo hicieron escribiéndolos, y nosotros publicándolos.

El Equipo Editorial de CompartiMOSS

3

04

Enmarcha: Como facilita el Unit Testing
en SharePoint / Office 365

Conceptos Previos
Antes de empezar con el articulo vamos a definir algunos
conceptos de Unit Testing para dejar aclarado algunos pun-
tos.

• Stub-> Un trozo de código usado como sustituto de
alguna otra funcionalidad. Un stub puede simular el
comportamiento de código existente (tal como un pro-
cedimiento en una máquina remota) o ser el sustituto
temporal para un código aún no desarrollado.

• Mock -> Se usan para simular el comportamiento de
objetos complejos cuando es imposible o impractica-
ble usar al objeto real en la prueba. De paso resuelve el
problema del caso de objetos interdependientes, que
para probar el primero debe ser usado un objeto no
probado aún, lo que invalida la prueba: los objetos si-
mulados son muy simples de construir y devuelven un
resultado determinado y de implementación directa,
independientemente de los complejos procesos o in-
teracciones que el objeto real pueda tener.

con Enmarcha podemos hacer Unit Testing
sobre SharePoint de una forma sencilla

Los objetos simulados se usan en lugar de objetos reales
que tengan algunas de estas características:

• Devuelven resultados no determinísticos (por ejemplo,

la hora o la temperatura).

errores de conexión).

• Su estado es difícil de crear o reproducir (por ejemplo,

• Es lento (por ejemplo, el resultado de un cálculo inten-

sivo o una búsqueda en una BBDD).

• El objeto todavía no existe o su comportamiento pue-

de cambiar.

para el testeo.

• Debería incluir atributos o métodos exclusivamente

Otro de los conceptos que muchos desarrolladores tienen
en la cabeza es que juntan un concepto como Test Driven
Development (TDD) como hacer Test. Hacer Test no impli-
ca que necesariamente tengas que hacer TDD, TDD es una
práctica que podemos decir que antes de empezar a tirar
una línea de código ya implementas los Test que vas a ha-
cer para que una vez vas implementando la funcionalidad
vas comprobando si este es correcto o no. Y una vez es co-

rrecto podemos dedicarnos a refactorizar nuestro código y
dejarlo como idealmente queremos.

Imagen 1.- Conceptos de TDD.

Hagamos Testing con SharePoint
SharePoint como tal es una plataforma que ha ido evolucio-
nando con el tiempo, principalmente por su mayor impor-
tancia dentro de grandes organizaciones. Esto ha provoca-
do que versión a versión el producto haya ido mejorando
más y más y de cara al desarrollador se ha ido haciendo
mejoras en cuanto al ciclo de vida de la solución. Estas me-
joras han sido adoptadas por la gran mayoría de equipos
de desarrollo. Sin embargo, cuando se habla sobre temas
como Unit Testing estos desarrolladores siguen igual que
en sus inicios, es decir, no hay Test Unitarios en la mayoría
de las ocasiones. Muchos de estos desarrolladores indican
que es imposible hacer Unit Test en SharePoint. Algunos
de estos argumentos se basan en que el SDK de SharePoint
se compone de innumerables clases “selladas” y que por
este motivo no se pueden hacer mocks. Esta afirmación no
es más que una verdad a medias ya que existen productos
comerciales como TypeMock o JustMock que se encargan
de generar los mocks (no comento los emuladores de Sha-
rePoint porque podemos decir la propia Microsoft no los
ha evolucionado desde 2010). Si bien es cierto que para
alguien que empiece a hacer testing, SharePoint no es una
plataforma que lo facilite de una forma sencilla (se han de
tener claros cada uno de los conceptos y una forma de de-
sarrollar clara).
Por estos motivos cuando empezamos a trabajar en Sha-
rePoint, uno de nuestros principales objetivos fue seguir
las buenas prácticas y consejos que se utilizan en todas las
plataformas .NET. No debemos de tratar SharePoint como
una plataforma distinta y en la que todo vale. De este co-
nocimiento como hablamos en el artículo del número 27

4

surgió ENMARCHA.
Entre sus múltiples utilidades Enmarcha tiene una Capa de
Acceso a las listas de SharePoint que facilita el aprendiza-
je sobre la plataforma. Esta clase surgió de intentar en la
medida de lo posible seguir una arquitectura N-Capas en
nuestros desarrollos y tener una capa de acceso a datos
siguiendo el patrón Repositorio. Este patrón lo podemos
definir como un repositorio que es un mediador entre el
dominio de la aplicación y los datos que le dan persisten-
cia. Con este planteamiento podemos pensar que el usua-
rio de este repositorio no necesitaría conocer la tecnología
utilizada para acceder a los datos, sino que le bastaría con
saber las operaciones que nos facilita este “mediador”, el
repositorio.

Imagen 2.- Patrón Repositorio.

Este patrón en Enmarcha lo hacemos implementando la in-
terfaz IRepository, la cual tiene la siguiente definición.

public interface IRepository<T> : IPageable
{
T Get(int id);
ICollection<T> GetAll();
ICollection<T> GetAll(int page);
ICollection<T> Query(IQuery query, int page);
ICollection<T> Query(string query, int page);
int Insert(T data);
bool Save(int id, T data);
bool Delete(int id);
}

Para el acceso a listas utilizando SharePoint Server Object
Model hemos implementado la clase SharePointReposi-
tory de tal forma que dado una clase de C# podamos “ma-
pearla” con una lista de SharePoint.

Hacer Test no implica que necesariamente
tengas que hacer TDD

Ahora bien, ¿cómo hacemos Unit
Testing con Enmarcha?
Partimos de la base de que tenemos un WebPart que nos
muestran los clientes que tienen un saldo de más de 1.000
€. Para ello en SharePoint lo que tendremos es una lista de
SharePoint llamada cliente. Y dentro de nuestra solución
de Visual Studio tendremos lo siguiente:

• Una clase “Customer”(mapea la clase C# con la lista de

SharePoint) con la siguiente definición

public class Customer
{
[Enmarcha(AddPrefeix = false, Create = false, Type =
TypeField.Text)]
public string ID { get; set; }
[Enmarcha(AddPrefeix = false, Create = false, Type =
TypeField.Text)]
public string CIF { get; set; }
[Enmarcha(AddPrefeix = false, Create = false, Type =
TypeField.Text)]
public string Title { get; set; }
[Enmarcha(AddPrefeix = false, Create = false, Type =
TypeField.Text)]
public string Direccion { get; set; }
[Enmarcha(AddPrefeix = false, Create = false, Type =
TypeField.Number)]
public double Saldo { get; set; }
}
• En la Capa de Servicio t