Pregunta

Tenemos una gran cantidad de servlets / portlets basados ??en Java que se ejecutan en un portal BEA que queremos convertir en elementos web de SharePoint 2007. Muchos de los portlets usan las preferencias del usuario, pero las implementaciones se dividen entre las preferencias que maneja el portlet directamente y se almacenan en una base de datos separada del portal. Otros están utilizando la API BEA WebLogic para las preferencias del usuario.

Tres preguntas:

  1. ¿Alguien ha recibido un Java Servlet / JSP (compilado contra JRE 1.4.2 y ejecutándose en Tomcat 4.1) para ejecutarlo como un elemento web de SharePoint 2007?
  2. ¿Qué tan grande fue el esfuerzo en general (como en, se midió en días / semanas / meses)?
  3. ¿Sería más fácil reescribir el portlet como elementos web nativos al menos en lo que respecta a las preferencias del usuario?
¿Fue útil?

Solución 2

Esto es lo que he hecho para un único portlet, un panel de cotización de acciones.

Tenemos un gadget que muestra cotizaciones de bolsa. Tenemos una cuenta con Tickertech para que nos proporcionen información de cotización. Hay preferencias de usuario que permiten a las personas agregar el gadget a una página privada y luego seleccionar acciones de interés para ellos como individuos. También puede seleccionar qué columnas mostrar. Esto se logra a través de JavaScript. Los símbolos de stock seleccionados se envían junto con un token que identifica que la solicitud proviene de un cliente válido.

El enfoque más simple era usar un control de contenido web y simplemente pegar el JavaScript. Esto funciona, pero no deja ningún modo para que un usuario cambie los símbolos de valores u otras preferencias que involucren Tickertech.

El siguiente paso fue crear un elemento web personalizado. Estamos utilizando el complemento WSPBuilder para Visual Studio. La empresa de consultoría que nos está ayudando con el proyecto lo recomendó y estoy muy contento de que lo hayan hecho, reduce el ciclo de integración a un nivel tolerable.

En el elemento web tenemos una propiedad que contiene el script.

public class MarketSummaryWP : Microsoft.SharePoint.WebPartPages.WebPart
{     
    string m_scriptBlockPre = "<script language='javascript'> \n"+ // the beginning of the JavaScipt block 

En la anulación CreateChildControls (), acabo de agregarlo como literal.

this.Controls.Add(new LiteralControl(this.Script));  

A continuación, cambié el script para que sea privado y creé otra propiedad para contener la lista de símbolos de stock. Observe que la propiedad Script realiza la concatenación dentro del captador.

    //Script Property
    [WebBrowsable(false),
    WebDisplayName("Script"),
    WebDescription("The JavaScript to insert in the page.")]
    public string Script
    {
    get { return m_scriptBlockPre + m_stockSymbolsList + m_scriptBlockPost; }
    //set { ; }
    }

    //Stock Symbol list Property
    [Personalizable(PersonalizationScope.User), WebBrowsable(true),
    WebDisplayName("Stock Symbols"),
    WebDescription("The stock symbols to retrieve quotes for, seperated by commas.")]
    public string StockSymbols
    {
        get { return m_stockSymbolsList; }
        set { m_stockSymbolsList = value; }
    }


    string m_stockSymbolsList = "GE,CAT,$DJI,AMR,JNJ,";

    string m_scriptBlockPost = " *other JavaScript code* </script> \n"+

Esto me da un elemento web que se puede agregar a cualquier página porque está en la galería de elementos web. Para agregar una copia del elemento web creado utilizando el elemento web estático html, debe obtener el bloque JavaScipt de una instancia existente, probablemente usando 'ver código fuente', navegar a la página de destino, agregar una nueva instancia del elemento web estático HTML, y modificarlo para incluir el bloque JavaScipt; cada vez. De esta forma, los usuarios solo tienen que seleccionarlo de una lista de elementos web y pueden tener preferencias personalizadas de cotizaciones de acciones.

Otros consejos

Tenemos un proyecto ligeramente similar, donde estamos convirtiendo desde un portal BEA a Sharepoint.

La diferencia es que no tenemos ningún servlet de Java o páginas JSP como elementos web / portlets, sino que todo ese código en nuestro sistema es portlets .net (y ahora elementos web).

Los servlets de Java están en ventanas emergentes, que están vinculadas desde Sharepoint mediante hipervínculos.

Así que no puedo darte una respuesta a 1. Como nunca hemos hecho esto.
Sin embargo, convertir un portlet de portal BEA en un elemento web de SharePoint puede ser un ejercicio significativo, ya que debe crearlos de una manera completamente diferente.

En términos de esfuerzos, hemos migrado aproximadamente 100 dispositivos a partes / aplicaciones web en 1 año, con 1 desarrollador a tiempo completo y 1 infraestructura / configurador de punto compartido.

Y para 3 ... depende de lo complicado que sea su portlet. Si desea mantenerlos como portlet / webparts, se requiere una reescritura completa a menos que use un truco como un elemento web de visor de páginas ... pero realmente no está migrando, simplemente encapsula su sistema existente con SharePoint en la parte superior.

Diría que este es un proyecto grande, que necesita una planificación cuidadosa para tener éxito.
Espero que esto ayude.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top