Pianificare un'applicazione basata su moduli

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Molte applicazioni di SharePoint Server contengono moduli di InfoPath. Un sottoinsieme di tali applicazioni è effettivamente gestito tramite un modulo. Le applicazioni basate su moduli condividono in genere le caratteristiche seguenti:

  • Consentono di automatizzare un processo aziendale, ad esempio l'inserimento di un ordine oppure il completamento delle valutazioni relative alle prestazioni dei dipendenti.

  • Le informazioni strutturate contengono quindi un elemento chiave, le cui istanze vengono trasferite a diverse attività per consentire il completamento del processo aziendale.

Sebbene ogni applicazione sia unica, le applicazioni basate su moduli sono spesso caratterizzate da una struttura comune. Se l'applicazione in uso è adatta a tale struttura comune, è possibile utilizzare la struttura illustrata in questo articolo e modificarla in base a esigenze specifiche.

In questo articolo viene descritta la struttura di un particolare tipo di applicazione di Microsoft SharePoint Server 2010 che utilizza moduli. Non vengono invece illustrate le procedure di progettazione di altri tipi di applicazioni di SharePoint Server o di progettazione dei moduli. Per ulteriori informazioi su come progettare moduli di Microsoft InfoPath 2010, visitare il sito Web Office.com (http://go.microsoft.com/fwlink/?linkid=187550&clcid=0x410).

Contenuto dell'articolo:

Un'applicazione di SharePoint Server complessa basata su moduli può contenere i componenti seguenti:

  • Un sito di SharePoint in cui ospitare l'applicazione.

  • Un modello di modulo in cui vengono acquisite le informazioni essenziali. È possibile che per il modello di modulo siano disponibili visualizzazioni diverse a seconda dei gruppi o degli utenti o delle fasi del ciclo di vita delle informazioni.

  • Un elenco o una raccolta SharePoint in cui archiviare le istanze del modello di modulo completato (denominate moduli).

  • Un flusso di lavoro che instrada un elemento in un processo di business. Il flusso di lavoro viene avviato quando si crea un nuovo modulo.

  • Elenchi SharePoint che contengono informazioni ausiliarie utilizzate per popolare i campi nel modello di modulo. È possibile associare moduli e flussi di lavoro a questi elenchi per gestire le informazioni nell'elenco.

  • Database esterni o applicazioni line-of-business (LOB) che forniscono i dati per il modello di modulo o il flusso di lavoro.

  • Regola business rappresentata come regole di convalida nel modello di modulo o come parte del flusso di lavoro.

  • Una pagina Web che funge da portale e consente agli utenti di creare una nuova istanza del modello di modulo e di visualizzare altre informazioni sui moduli. Possono esistere più portali a seconda del gruppo di destinatari.

Non è necessario che l'applicazione in uso ricalchi esattamente questa struttura. Alcune applicazioni SharePoint Server basate su moduli non contengono tutti questi componenti, mentre in altre applicazioni vengono aggiunte piccole varianti, ad esempio includono più flussi di lavoro.

Per progettare un tipo comune di applicazione basata su moduli, è in primo luogo necessario determinare l'informazione chiave per la gestione del processo aziendale. È quindi possibile decidere se archiviare le informazioni in un elenco o in una raccolta SharePoint e definire il flusso di lavoro utilizzato per l'elaborazione delle informazioni e successivamente determinare le eventuali origini dati aggiuntive necessarie, fino a progettare i portali tramite i quali gli utenti accederanno all'applicazione.

Il primo passaggio per la pianificazione di un'applicazione basata su form consiste nel determinare l'informazione chiave su cui è incentrata l'applicazione. In molte situazioni l'informazione chiave è ovvia. In un'applicazione per helpdesk, ad esempio, l'informazione chiave è probabilmente costituita da una richiesta di intervento, nel processo di revisione delle prestazioni dei dipendenti è probabilmente il modulo di valutazione del dipendente, mentre in un sistema per la gestione degli acquisti è probabilmente un ordine.

Identificare l'informazione chiave per la gestione del processo. Se l'informazione chiave non è ovvia, considerare i suggerimenti seguenti:

  • Se l'applicazione automatizzerà un processo esistente, è presente un documento o un file che viene trasferito da una persona a un'altra nelle varie fasi del processo, Tale documento o file è probabilmente l'informazione chiave.

  • Se un processo viene avviato quando un elemento viene creato o viene visualizzato in una posizione specifica, l'elemento è probabilmente l'informazione chiave.

  • L'informazione chiave è probabilmente caratterizzata da una determinata struttura e potrebbe aumentare di dimensioni o cambiare durante l'elaborazione. Ad esempio, un ordine contiene nome e indirizzo del cliente, un elenco di elementi con l'indicazione di quantità e prezzo, nonché altri dettagli. Durante l'elaborazione dell'ordine vengono aggiunte ulteriori informazioni, ad esempio un numero di controllo.

  • All'informazione chiave viene probabilmente associato uno stato che cambia nel tempo.

Se non si riesce a determinare l'informazione chiave per la gestione del processo, è probabile che la struttura illustrata in questo articolo non è adatta alle esigenze dell'applicazione in uso.

Quando si implementa l'applicazione, viene creato un modello di modulo per l'informazione chiave. In questo articolo al modello di modulo verrà fatto riferimento con il termine "modulo principale".

Determinare se le istanze del modulo principale verranno archiviate in un elenco SharePoint o in una raccolta moduli SharePoint Server.

Se possibile, utilizzare un elenco. Le soluzioni basate su elenchi sono più semplici e più efficienti. In alcune situazioni tuttavia non è possibile utilizzare un elenco. In presenza di una delle condizioni seguenti, utilizzare una raccolta moduli:

  • È necessario mantenere una cronologia delle modifiche apportate alle istanze del modulo.

  • Il modulo principale contiene sezioni ripetute, ad esempio un numero arbitrario di obiettivi raggiunti nel modulo di valutazione di un dipendente.

  • Il modulo principale contiene dati annidati, ad esempio un modulo d'ordine contenente un articolo, in cui un articolo può contenere informazioni quali codice prodotto, quantità, dimensioni e prezzo.

  • Il modulo principale conterrà codice.

    Di seguito sono descritte alcune situazioni in cui un modulo può contenere codice:

    • Il modulo include pulsanti che eseguono azioni personalizzate.

    • Il valore di un campo del modulo è basato su una combinazione complessa di altri valori del modulo.

  • Le istanze del modulo principale verranno firmate digitalmente.

  • È necessario archiviare i dati su ogni istanza del modulo principale in formato XML.

Se si archiviano le istanze del modulo principale in un elenco, ogni campo del modulo diventerà una colonna dell'elenco e ogni istanza del modulo diventerà una voce dell'elenco. Se si archiviano le istanze del modulo principale in una raccolta moduli, ogni istanza verrà trasformata in un documento XML e i documenti verranno archiviati nella raccolta.

Il processo aziendale ha inizio quando si verifica un evento correlato a un'istanza del modulo principale. Il processo aziendale inizia spesso in seguito alla creazione di una nuova istanza del modulo principale, tuttavia può iniziare anche in concomitanza di altri eventi, ad esempio la modifica di un'istanza del modulo principale o l'assegnazione del modulo a un utente.

Il processo aziendale inoltra l'istanza del modulo principale agli utenti e ai sistemi che devono eseguire le azioni. Se ad esempio il modulo principale è una richiesta di assistenza, è possibile che in seguito alla creazione di una nuova richiesta venga avviato un processo che assegna la richiesta al tecnico del servizio di assistenza che dovrà interagire con l'autore della richiesta. Il tecnico del servizio di assistenza può intraprendere diverse azioni a seconda dell'esito della discussione con l'autore della richiesta e, ad esempio, inviare la richiesta a un responsabile di livello superiore, contrassegnare la richiesta come evasa, inoltrare la richiesta al reparto ordini se è necessario inviare all'utente un articolo sostitutivo e così via.

Identificare i passaggi e i punti decisionali interessati nell'elaborazione di un'istanza del modulo principale. Questa sequenza di passaggi verrà rappresentata in SharePoint Server sotto forma di flusso di lavoro. Per ulteriori informazioni sui flussi di lavoro, vedere Pianificare i flussi di lavoro (SharePoint Server 2010).

Un modello di modulo può recuperare dati da origini esterne, ad esempio un database, un servizio Web o un elenco SharePoint. I dati esterni vengono comunemente utilizzati per popolare un elenco di valori validi per un campo del modello di modulo, ad esempio un elenco dei centri di costo. È inoltre possibile utilizzare una regola per calcolare il valore di un campo in base a una combinazione di dati esterni e dei valori di altri campi. Ad esempio, è possibile ottenere il valore di un campo “Responsabile approvazione” utilizzando un'origine dati esterna per cercare il responsabile del dipendente il cui nome è stato immesso nel campo “Inviato da”.

Identificare i dati esterni a cui accederà il modulo principale. Per ogni origine dei dati esterni indicare la provenienza dei dati, specificando ad esempio se i dati provengono da un elenco SharePoint, un database SQL, un sistema LOB quale SAP o da un'altra origine.

NotaNote
È possibile accedere ad alcuni dati LOB direttamente dagli elenchi SharePoint Server creando un tipo di contenuto esterno. Per ulteriori informazioni sulla creazione di tipi di contenuto esterni, vedere Panoramica di Servizi di integrazione applicativa (SharePoint Server 2010).

Considerare la modalità di gestione dei dati per ogni elenco SharePoint che include i dati per il modulo principale e decidere ad esempio se creare un modulo per immettere nuovi dati nell'elenco o se utilizzare flussi di lavoro per gestire le voci dell'elenco. Se ad esempio nel modulo principale viene utilizzato un elenco dei centri di costo, è possibile aggiungere all'elenco un flusso di lavoro per l'approvazione.

Stabilire chi utilizzerà l'applicazione e se sono previsti ruoli utenti diversi, in cui i membri di un ruolo eseguono azioni diverse o visualizzano informazioni diverse rispetto agli utenti di altri ruoli. Se gli utenti con ruoli diversi eseguono operazioni diverse nell'applicazione, è opportuno creare un portale per ogni ruolo. Personalizzare le azioni e le informazioni disponibili in ogni portale in base al ruolo degli utenti.

Ad esempio, in un'applicazione per la valutazione delle prestazioni dei dipendenti è probabile che siano disponibili tre ruoli:

  • Dipendenti, che completano i moduli di valutazione delle prestazioni.

  • Responsabili, che aggiungono informazioni ai moduli ed approvano le valutazioni.

  • Professionisti delle risorse umane, che creano report e aggregano le informazioni delle valutazioni delle prestazioni.

I dipendenti accedono all'applicazione per la valutazione delle prestazioni tramite un portale per dipendenti che consente di creare un nuovo modulo di valutazione e di essere informati quando la valutazione è stata approvata dal responsabile. I responsabili accedono all'applicazione tramite un portale per responsabili in cui viene visualizzato un elenco dei dipendenti in cui è indicato se il dipendente ha già inviato un modulo di valutazione delle prestazioni ed è presente un collegamento per aprire il modulo. I professionisti delle risorse umane accedono all'applicazione tramite un portale per le risorse umane che visualizza le statistiche riepilogative sui moduli di valutazione delle prestazioni approvati, inviati ma non ancora approvati o non ancora inviati.

Il tipo di portale più semplice da creare consiste in una visualizzazione dell'elenco o della raccolta SharePoint in cui vengono create le istanze del modulo principale. È quindi possibile utilizzare un filtro o applicare formattazione condizionale per personalizzare la visualizzazione per l'utente specifico.

È inoltre possibile progettare una pagina Web personalizzata per ogni ruolo utente e assegnare a ogni utente l'URL appropriato in base al ruolo per accedere all'applicazione. Nelle pagine Web del portale è possibile includer alcuni degli elementi seguenti:

  • Un pulsante Nuovo per creare una nuova istanza del modulo principale.

  • Una visualizzazione riepilogativa/dettagliata delle istanze del modulo principale. La visualizzazione riepilogativa è un elenco delle istanze del modulo, filtrate in base ad alcuni criteri, mentre la visualizzazione dettagliata include i dettagli relativi a una qualsiasi istanza del modulo selezionata nel riepilogo. È possibile creare la visualizzazione riepilogativa utilizzando una web part Visualizzazione elenco o Query contenuto. È possibile creare la visualizzazione dettagliata ospitando il modulo principale nella web part del modulo di InfoPath. Per ulteriori informazioni sulla web part Visualizzazione elenco, vedere il blog del team di Microsoft SharePoint (le informazioni potrebbero essere in lingua inglese) (http://go.microsoft.com/fwlink/?linkid=187653&clcid=0x410). Per ulteriori informazioni sulla web part Query contenuto, vedere la procedura per personalizzare il contenuto con la web part Query contenuto utilizzando le proprietà personalizzate (le informazioni potrebbero essere in lingua inglese) (http://go.microsoft.com/fwlink/?linkid=187635&clcid=0x410). Per ulteriori informazioni sulla web part del modulo di InfoPath, vedere la procedura per ospitare un modulo di InfoPath nella web part del modulo di InfoPath (le informazioni potrebbero essere in lingua inglese) (http://go.microsoft.com/fwlink/?linkid=187637&clcid=0x410). È possibile utilizzare un filtro diverso nei portali relativi a ruoli diversi. Ad esempio, nel portale per gli utenti che creano nuove istanze di modulo è possibile filtrare il contenuto in base alle istanze create dallo stesso utente. Nel portale per i responsabili dell'approvazione è possibile filtrare il contenuto in base alle istanze in attesa di valutazione e approvazione da parte dell'utente.

  • Statistiche sul processo, ad esempio il numero di istanze del modulo elaborate ogni giono oppure misurazioni correlate all'area di interesse dell'applicazione.

Se si è riusciti a determinare le caratteristiche dell'applicazione corrispondenti alla maggior parte delle sezioni precedenti, è probabile che sia possibile implementare l'applicazione attenendosi al paradigma di un'applicazione basata su moduli. Creare un sito di SharePoint in cui ospitare l'applicazione. Creare un modello di modulo per il modulo principale, quindi creare un elenco o una raccolta in cui archiviare le istanze del modulo principale e associare il modello di modulo all'elenco o alla raccolta. Aggiungere un flusso di lavoro che viene attivato quando si aggiunge un nuovo modulo all'elenco o alla raccolta. Creare e popolare eventuali elenchi aggiuntivi necessari per fornire i dati per il modello di modulo. Creare uno o più portali che verranno utilizzati dagli utenti per interagire con l'applicazione.

Mostra: