Este documento describe una arquitectura propuesta para extraer datos de redes sociales de manera generalizada e independiente de cada plataforma. Se propone separar la extracción de datos en componentes genéricos para el manejo de autenticación, servicios de API y almacenamiento, con implementaciones específicas para cada red social. Esto permitiría extraer periódicamente datos de diferentes plataformas de manera unificada y almacenar la información de manera estructurada.

1. Redes Sociales
Pablo Gómez Cruañes
pgomez@SolidQ.com
Daniel Seara
dseara@SolidQ.com

2. ¿Qué vemos?
 Motivación
 Las redes sociales son otro camino para la interacción con los clientes
 La naturaleza de esas interacciones aporta información valiosa
 Las redes sociales son heterogéneas y manejan los datos de manera distinta
 Arquitectura para resolver problemas
 Donde separamos en partes, para poder interactuar debidamente con las redes
sociales
 Modelo de generalización de componentes
 Donde decidimos separar para vencer
 Demo
 …o sea, demo

3. Por qué no usar el conector de Power BI
 Alcance
 Maneja sólo algunos métodos de la API
 Autenticación
 Sólo permite autenticarse como un usuario
 No multicuenta, no autenticación de página
 Puede no existir conector para cierta red (twitter)
 Es suficiente en algunos casos … en otros no

4. Motivación
(Donde contamos que diferente que viene la información
desde cada red Social)

5. Rest API
• Peticiones HTTP (GET, POST, PUT, DELETE)
• Manejo de URIs
• Respuestas en JSON
• Distintos métodos de autenticación

6. Oauth, oAuth2, … #@~|
 Convengamos, la identificación es un tema
 Y por eso se torna estricta
 Hay casos, de llamadas re entrantes para confirmar identidad
del solicitante
 Te pido permiso
 Me mandas algo para ver si yo soy quien digo ser
 Con ese algo voy a otro lado a ver si me lo aceptas
 Me das un identificador de acceso
 … y nos hace falta un sitio público

7. Facebook
 Dos fuentes de datos principales:
 Feed de página:
 Lista de las publicaciones de página y de otros en la página.
 Cada publicación contiene información relacionada con las interacciones
 Hay que pedir explícitamente la información de un post
 Facebook insights
 Datos agregados de la página
 Usuarios por país
 Usuarios por género / Edad

8. Facebook
 Autenticación: Oauth2
 Requiere que el usuario otorgue permiso a la app
 Requiere intervención del usuario (popup)
 Distintos tipos de token (con distintos niveles de acceso)
 Autenticación de usuario
 Autenticación de página
 Autenticación de app

9. Twitter
 User_timeline: Tweets de la cronología del usuario
 Tweets anidados (dentro de un tweet está su retweet)
 Siempre viene toda la información disponible del tweet
 Tweet_search
 En los últimos cambios de la API ha pasado a ser de pago (o estar
limitado en la versión gratuita)
 Permite obtener los tweets en los que se nombró a un usuario, o los
que contienen ciertos términos
 Estructura igual que la cronología

10. Twitter
 Autenticación: Oauth1
 Además, la mayoría de datos son accesibles con token de
app

11. Arquitectura para resolver problemas
(Donde separamos en partes, para poder interactuar
debidamente con las redes sociales
… o la lucha por la correcta identificación )

12. Arquitectura para resolver problemas
BD
WebAPP
ReadConfig()
Lee de la bd la
info de la red
social y la
guarda en un
SocialNetwork
Se crea un
"manejador de
API" a partir
del
Socialnetwork:
Processor
ProcessNewInfo()
Llama a la API, trae
los datos, los
almacena en Azure
Storage
API
JSON Azure Storage
Analyzer
Se crea un
“manejador de
destinos” que
almacenará la
información
ProcessContent()
Trae los datos
del azure
storage y los
almacena en el
destino
Destino

13. Diseño completo

14. Modelo de generalización de componentes
(Donde decidimos separar para vencer)

15. Modelo de generalización de componentes
Para cada red social:
 Extractor:
 Auth: Manejador de autenticación
 Service: Funciones básicas, lenguaje “máquina”
 GetAsync(URL)
 Client: Funciones Complejas, lenguaje “humano”
 “Tráeme las 100 últimas publicaciones”

16. Modelo de generalización de componentes
Para cada red social y destino:
 Analizador:
 Obtiene el resultado de la extracción de Azure Storage
 Lo inserta en el destino

17. Diseño de captación de datos
 Extractores

18. Diseño de Captación de Datos
 Analizadores

19. Cliente web para lidiar con OAuth2
 … y de paso, exponer API para procesar

20. Y, ya que estábamos en esas
(Un modelo similar, para almacenar la información)

21. Diseño de Captación de Datos
 Almacenamiento

22. Diseño Generalizado
 Definir interfaces para usar desde las aplicaciones
 Componentes que implementan, con distintas acciones
específicas en cada caso
 Instanciación por parámetros

23. Diseño Generalizado (II)
public class StorageManager : IStore
{
IStore internalStorage = null;
public StorageManager(string storageType, string connectionString)
{
AssemblyName name = new AssemblyName("SolidQ." + storageType);
try
{
System.Reflection.Assembly ass = System.Reflection.Assembly.Load(name);
if (ass != null)
{
var type = ass.GetType(name.Name + ".Store");
internalStorage = Activator.CreateInstance(type, connectionString) as IStore;
}
}
catch (Exception ex)
{
throw ex;
}
}

24. Perspectiva de los datos
 Periodo de tiempo que descargamos
 Limitado por la API o por el tiempo que dedicamos al proceso
 Dada una perspectiva, traemos ese periodo
 Snapshot del estado de la red social
 Luego tenemos que mezclar con lo que ya había

25. Perspectiva de los datos (SQL)
 El proceso escribe la perspectiva en una table
 Se dispara un procedimiento almacenado que realiza el
merge

26. Perspectiva de los datos (JSON)
 Cada archivo se corresponde a una extracción
 Otro proceso tendrá que realizar el merge

27. Demo
En Acción

28. Preguntas