Conversione di un JSP in una web part di SharePoint

Question

Abbiamo un gran numero di servlet / portlet basati su Java in esecuzione in un portale BEA che vogliamo convertire in webpart di SharePoint 2007. Molti portlet utilizzano le preferenze dell'utente, ma le implementazioni sono suddivise tra le preferenze gestite direttamente dal portlet e archiviate in un database separato dal portale. Altri stanno usando l'API BEA WebLogic per le preferenze dell'utente.

Tre domande:

1. Qualcuno ha ottenuto un Servlet / JSP Java (compilato su JRE 1.4.2 e in esecuzione su Tomcat 4.1) per essere eseguito come webpart di SharePoint 2007?
2. Quanto è stato grande uno sforzo in generale (come in, è stato misurato in giorni / settimane / mesi)?
3. Sarebbe più semplice riscrivere il portlet come parti web native almeno per quanto riguarda le preferenze dell'utente?

Answer 1

Ecco cosa ho fatto per un singolo portlet, un pannello quotazioni di borsa.

Abbiamo un gadget che mostra le quotazioni di borsa. Abbiamo un account con Tickertech per fornirci informazioni sul preventivo. Ci sono preferenze dell'utente che consentono alle persone di aggiungere il gadget a una pagina privata e quindi selezionare titoli di loro interesse come singoli. Puoi anche selezionare quali colonne visualizzare. Questo viene realizzato tramite JavaScript. I simboli di borsa selezionati vengono inviati insieme a un token che identifica la richiesta come proveniente da un cliente valido.

L'approccio più semplice era utilizzare un controllo del contenuto Web e incollarlo nel JavaScript. Funziona ma non consente ad un utente di modificare i simboli di borsa o altre preferenze che coinvolgono Tickertech.

Il passo successivo è stato creare una webpart personalizzata. Stiamo utilizzando il componente aggiuntivo WSPBuilder per Visual Studio. La società di consulenza che ci sta aiutando con il progetto lo ha raccomandato e sono molto contento di averlo fatto, riduce il ciclo di integrazione a un livello tollerabile.

Nella webpart abbiamo una proprietà che contiene lo script.

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

Nell'override di CreateChildControls (), l'ho appena aggiunto come letterale.

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

Successivamente ho modificato lo script in privato e ho creato un'altra proprietà per contenere l'elenco dei simboli di borsa. Notare che la proprietà Script esegue la concatenazione all'interno del getter.

    //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"+

Questo mi dà una webpart che può essere aggiunta a qualsiasi pagina perché è nella galleria webpart. Per aggiungere una copia della webpart creata utilizzando la web part html statica, è necessario ottenere il blocco JavaScipt da un'istanza esistente probabilmente utilizzando "visualizza sorgente", passare alla pagina di destinazione, aggiungere una nuova istanza della webpart HTML statica, e modificarlo per includere il blocco JavaScipt; ogni volta. In questo modo gli utenti devono solo selezionarlo da un elenco di webpart e possono avere preferenze personalizzate per le quotazioni di borsa.

Answer 2

Abbiamo un progetto leggermente simile, in cui stiamo convertendo da un portale BEA a Sharepoint.

La differenza è che non abbiamo pagine servlet java o JSP come webpart / portlet, invece tutto quel codice sul nostro sistema è portlet .net (e ora webpart.).

I servlet Java sono nelle finestre popup, che sono collegati da Sharepoint usando collegamenti ipertestuali.

Quindi non posso darti una risposta a 1. Dato che non l'abbiamo mai fatto.
Tuttavia, la conversione da un portlet del portale BEA in una webpart di SharePoint può essere un esercizio significativo, poiché è necessario crearli in un modo completamente diverso.

In termini di sforzi, abbiamo migrato all'incirca 100 gadget in webpart / applicazioni in 1 anno, con 1 sviluppatore a tempo pieno e 1 infrastruttura / configuratore sharepoint.

E per 3 ... dipende da quanto sono complicati i portlet. Se si desidera mantenerli come portlet / webpart, è necessaria una riscrittura completa a meno che non si utilizzi un hack come un webpart visualizzatore di pagine ... ma poi non si sta realmente migrando, si sta semplicemente incapsulando il sistema esistente con SharePoint in cima.

Direi che questo è un grande progetto, che ha bisogno di un'attenta pianificazione per avere successo.
Spero che questo aiuti.