Ya tenéis disponibles en SUGES para descarga los materiales (video en este caso) del chat de expertos de SharePoint que realizamos ayer. Del mismo modo, podéis descargaros la grabación del chat anterior desde este enlace. Agradecer a los compañeros del metal (Gustavo, Fabián, Mario, André, Alberto y David) su participación en el chat y a los asistentes por las preguntas realizadas. Aprovecho el post para comentar algunas de las cuestiones que se plantearon y dejar registro de la solución a las mismas (o al menos el camino a mirar):
-
Escaneo de documentos hacía SharePoint, hay varias alternativas disponibles como:
-
-
Los propios Scanner profesionales pueden disponer de esta funcionalidad ya integrada a través del middleware que incorporen de manera que se integren directamente con SharePoint.
-
Aprovechar la característica de correo entrante en SharePoint de manera que simplemente con escanear los documentos y enviarlos a la dirección o direcciones de correo de las bibliotecas habilitadas para recibir el correo entrante. Un par de direcciones con respecto a la configuración de correo entrante en SharePoint 2010:
-
Alta disponibilidad en SharePoint 2010, cero tiempo de caída y de pérdida de información sensible. Aquí la idea es usar Clustering a nivel de SQL Server, Mirroring o bien una combinación de ambos. Algo que no se comentó en el chat es el uso de Log Shipping, la definición conceptual de estos términos es la siguiente:
-
Clustering, es decir, configure un “failover cluster” a nivel de SQL Server que se define como una combinación de uno o más nodos o servidores y uno o más discos compartidos configurados como si se tratase una única máquina física, pero con capacidad de respuesta a fallos entre los nodos del clúster de manera que si uno de los nodos cae, automáticamente entra en funcionamiento otro de los nodos disponibles y de forma agnóstica para SharePoint 2010 que ve el clúster como un conjunto sin considerar las particularidades de su implementación.
-
Mirroring, que al contrario que en el caso de Clustering implica disponer de un servidor principal de BD’s y otro Espejo al que se envían las transacciones desde el servidor principal. En un escenario de alta disponibilidad de SQL Server con Mirroring, se dispone de un servidor testigo que continuamente monitoriza la salud del servidor principal de manera que si este cae, le cede el testigo al servidor espejo de manera que la granja de SharePoint 2010 no se resienta y continúe funcionando de manera ininterrumpida (es cuestión de segundos el paso del testigo). Además de este mecanismo para proporcionar alta disponibilidad, la técnica de Mirroring proporciona redundancia de BD’s de contenidos y de configuración así como para muchas de las BD’s de las aplicaciones de servicio de SharePoint 2010.
-
Log Shipping, que permite realizar copias de seguridad el log de transacciones de una instancia principal de SQL Server de forma regular en una o varias instancias secundarias de SQL Server.
Lo habitual en despliegues de alta disponibilidad de SharePoint 2010 es usar alguna de estas técnicas, cada una con sus ventajas e inconvenientes, e incluso combinarlas (mecanismos híbridos para garantizar la alta disponibilidad y que aprovechen lo mejor de cada técnica). Al final se trata de buscar un equilibrio entre el coste y la garantía de unos tiempos de recuperación mínimos de servicio y de datos. Si estos tiempos se quieren minimizar, será a base de aumentar el coste. Si el coste no se quiere disparar, entonces tendremos unos tiempos de recuperación peores. Algunas referencias al respecto:
-
- Alta disponibilidad:
- En general:
- A nivel de SQL Server:
- Disaster recovery:
-
Cómo plantear un escenario de explotación de datos de SharePoint en un Data Warehouse. Lo suyo es usar SQL Server Integration Services (SSIS) qué por defecto no dispone de adaptadores para SharePoint. Por suerte, en Codeplex hay un proyecto con ejemplos de SSIS y uno de ellos es un adaptador que permite recoger y enviar datos de/a SharePoint:
- Como monitorizar de forma sencilla lo qué está haciendo SharePoint a distintos niveles: peticiones, errores producidos, etc. Las posibilidades aquí son varias:
-
Para detectar problemas usar el Analizador de salud que viene integrado en SharePoint 2010 y que además es extensible:
-
Aprovechar la herramienta SharePoint Diagnostics Studio 3.0 de carácter gratuito:
-
Finalmente, no nos olvidemos que Microsoft dispone de un excelente producto para administrar servidores de todo tipo dentro de su offering: System Center Operations Manager (SCOM). Os dejo varias referencias al respecto:
-
Cómo realizar validaciones en listas externas en SharePoint Foundation 2010:
-
Por defecto, las validaciones en listas externas no son posibles ni a través del mecanismo de validaciones de columna o de lista disponibles en SharePoint 2010 ni mediante manejadores de eventos o flujos de trabajo que no están disponibles.
-
A partir de aquí, las opciones de validación son dos:
1: function PreSaveAction()
2: {
3:
4: //Variables de comprobación
5: var bDataValid=false;
6: if (//Comrpobar datos) {
7: //Lógica adicional de comprobación
8: bDataValid = true;
9: }
10:
11:
12: if (bDataValid==false) {
13: alert("Datos introducidos no correctos");
14: return false;
15: }
16:
17: return true; // OK para realizar el guardado
18: }
-
- Una herramienta imprescindible para saber las llamadas que está haciendo SharePoint y averiguar si estamos teniendo errores de tipo 404 es Fiddler. Os dejo algunas referencias sobre como usar Fiddler con SharePoint:
Y en principio estas fueron algunas de las cuestiones más relevantes. Como comenté en el WebCast, os animo a plantear las dudas que tengáis en torno a SharePoint en los foros o bien contactado con nosotros directamente:
Comparte este post: