Creazione di soluzioni Office Business Application

di Atanu Banerjee

Microsoft Office System 2007 offre un set di server, client e strumenti che rendono più semplice per le organizzazioni e i produttori di software sviluppare e implementare applicazioni composite negli ambienti aziendali. Queste soluzioni, denominate Office Business Applications (OBA), sono rapide da creare e implementare, offrono numerose funzionalità agli utenti finali grazie ad ampie capacità di personalizzazione, sono semplici da modificare in base alle esigenze di business e vengono sviluppate utilizzando familiari strumenti e applicazioni Microsoft Office. Il presente documento illustra come progettare applicazioni composite e i motivi per cui Microsoft Office System 2007 offre un'ottima piattaforma, familiare agli utenti finali, per lo sviluppo di applicazioni di questo tipo.

In questa pagina

 Che cosa sono le applicazioni composite?
 Microsoft Office System 2007 come piattaforma per lo sviluppo di applicazioni composite
 Soluzioni Office Business Applications come applicazioni composite
 Sviluppo di una soluzione Office Business Applications
 Sviluppo di siti SharePoint di reparto per l'hosting di documenti e processi
 Conclusioni
 Informazioni sull'autore

Globalizzazione, specializzazione e outsourcing richiedono un livello di collaborazione senza precedenti tra le persone. Questa tendenza impone un corrispondente cambiamento negli strumenti utilizzati dagli information worker per ottenere informazioni, collaborare, prendere decisioni e agire. Oggi, la maggior parte delle applicazioni aziendali è efficace per automatizzare le transazioni, ma non consente una collaborazione avanzata al di là dei confini delle varie funzioni. Questo in genere porta gli information worker a utilizzare strumenti di produttività personale per l'esecuzione delle complesse interazioni necessarie per le attività di business. Ciò, tuttavia, produce una perdita di produttività, perché gli utenti sono costretti a passare da un set di strumenti all'altro, spesso copiando e incollando i dati per spostarli. Questi gap tra le varie applicazioni aziendali e gli strumenti di produttività devono essere superati per gli information worker in un modo semplice, sincronizzato e protetto.
Finora non esisteva una soluzione efficiente per consentire la composizione di applicazioni aziendali in un modo contestuale, collaborativo, facile da usare, basato sui ruoli e configurabile per l'integrazione delle altre piattaforme tecnologiche necessarie per lo sviluppo di questo tipo di applicazioni composite. La facilità di utilizzo è importante, perché la piattaforma, gli strumenti e l'architettura per la composizione non devono introdurre un livello irragionevole di complessità tecnica che richieda una notevole formazione del personale.

Che cosa sono le applicazioni composite?

Un'applicazione composita è un insieme di risorse software assemblate in modo da fornire una capacità di business. Queste risorse sono elementi che possono essere implementati indipendentemente, che consentono la composizione e che sfruttano specifiche funzionalità della piattaforma.

In passato, le risorse software di un'organizzazione solitamente erano costituite da applicazioni aziendali indipendenti, monolitiche e scarsamente integrate. Tuttavia, per ottenere i vantaggi di business della composizione, un'organizzazione deve gestire le proprie risorse software in un modo più preciso e i diversi livelli dell'architettura richiedono diversi tipi di risorse, come risorse di presentazione, di applicazione e dati. Ad esempio, un Web service potrebbe essere una risorsa di applicazione, un cubo OLAP (Online Analytical Processing) una risorsa dati e una particolare schermata di immissione dati una risorsa di presentazione.

Un inventario delle risorse software di per sé non consente la creazione di applicazioni composite. A questo scopo è necessaria una piattaforma con capacità di composizione, ovvero una piattaforma che fornisca la possibilità di implementare le risorse sia separatamente che in modo combinato. In altre parole, le risorse devono essere dei componenti e la piattaforma deve fornire dei contenitori (figura 1).

Figura 1. Rappresentazione di alto livello di un'applicazione composita

I contenitori forniti dalla piattaforma devono essere di diversi tipi e associati ai differenti livelli dell'architettura. Le architetture aziendali in genere sono costituite da tre livelli: presentazione, applicazione (o logica business) e dati. Di conseguenza, la piattaforma deve fornire contenitori per tali elementi. Tuttavia, un'architettura a tre livelli presuppone dati e processi di business strutturati, in cui tutti i requisiti sono resi noti durante il processo di progettazione e sviluppo del sistema. Per natura, le applicazioni composite presuppongono che la composizione delle soluzioni possa aver luogo dopo lo sviluppo e l'implementazione delle soluzioni, quindi devono esplicitamente tenere conto delle interazioni tra gli information worker che sono essenziali per il completamento di qualsiasi processo di business. Generalmente queste interazioni non vengono acquisite dai processi strutturati o dalle tradizionali applicazioni aziendali, pertanto è essenziale aggiungere un quarto livello (il livello della produttività) per tenere conto di queste interazioni umane, come illustrato nella figura 2.

Figura 2. I quattro livelli di un'applicazione composita

Le tradizionali discussioni sull'architettura delle applicazioni aziendali tendono a focalizzarsi sul livello applicazioni perché rappresenta la connessione tra persone e dati. In genere, tuttavia, il livello applicazioni contiene la logica business strutturata e questo lascia spazio a discussioni su Service-Oriented Architecture (SOA), Enterprise Service Bus (ESB), Service Component Architecture (SCA) e sulla maggior parte delle altre prospettive architetturali del settore, inclusa la prima generazione di discussioni sulle applicazioni composite. Per lo sviluppo di applicazioni composite, comunque, è necessario non solo che il progettista consideri il livello di produttività come un elemento critico dello stack, ma anche che riconosca che questo contiene la maggior parte del valore di business.

Per ampliare il confronto tra applicazioni composite e architetture SOA, entrambe hanno come obiettivo la flessibilità e la modularizzazione, tuttavia le seconde assicurano flessibilità a un solo livello: la logica business strutturata al livello intermedio. Le applicazioni composite, invece, hanno come obiettivo la flessibilità a tutti e quattro i livelli. Detto questo, un'applicazione composita è una soluzione ideale per estrarre informazioni da un'architettura SOA ed esporre applicazioni line-of-business come servizi rende più semplice integrare il supporto per processi interfunzionali nelle applicazioni composite.

Di conseguenza, per progettare un'applicazione composita è necessario:

• Scegliere uno stack di composizione. Selezionare uno o più contenitori da ciascun livello e un set di tipi di componenti che siano implementabili in questi contenitori.

• Scegliere i componenti. Definire il repository di risorse che deve essere creato a partire da questo set di tipi di componenti, in base alle esigenze di business.

• Specificare l'applicazione composita. Definire i modi in cui queste risorse devono essere connesse per fornire un particolare processo interfunzionale. La piattaforma dovrebbe consentire un regime di controllo libero tra queste connessioni.

Dopo il deployment, gli utenti avranno l'opportunità di personalizzare sia le risorse che le connessioni e lo stack di composizione dovrebbe rendere questo possibile attraverso un regime di controllo libero e meccanismi di estendibilità.

 

Microsoft Office System 2007 come piattaforma per lo sviluppo di applicazioni composite

Microsoft Office System 2007 è una piattaforma per lo sviluppo di applicazioni composite, denominate Office Business Applications (OBA).

Figura 3. Funzionalità fornite da Microsoft Office System 2007

 

Soluzioni Office Business Applications come applicazioni composite

Consideriamo ora ciascuno dei livelli illustrati nella figura 2 ed esaminiamo i contenitori e i tipi di componenti forniti dalla piattaforma.

Tabella 1. Funzionalità di Microsoft Office System 2007

Funzionalità	Descrizione
Framework per siti Web e protezione	Un framework comune per la creazione di diversi tipi di siti, come siti per la collaborazione in team, portali Intranet e siti Web Internet.
Formati di file XML aperti	Questa caratteristica consente un'avanzata elaborazione sul lato server dei documenti. Con le versioni precedenti di Microsoft Office, per analizzare un documento (ad esempio, un foglio di calcolo) tramite il modello a oggetti del documento era necessario eseguire in memoria un'istanza dell'applicazione utilizzata per creare il documento (ad esempio, Excel).
Interfaccia utente estendibile	I portali sul lato server possono essere personalizzati dagli utenti a partire da blocchi estendibili da provider di soluzioni. Le applicazioni client possono essere estese utilizzando Visual Studio Tools per Office.
Catalogo dati business	Un repository di metadati per definire entità di business memorizzate in archivi dati back-end, per modellare relazioni tra le entità e per definire le azioni consentite sulle entità.
Ricerca contenuti organizzazione	Per estrarre dati da varie origini aziendali tramite ricerche.
Flussi di lavoro	Funzionalità integrata con Workflow Foundation per ospitare flussi di lavoro che rappresentano interazioni tra persone e sono collegati a elementi dell'interfaccia utente.
Gestione contenuto aziendale	Gestisce diversi contenuti con una sola topologia per il Web, i documenti e la gestione dei record. Supporta la gestione del ciclo di vita dei documenti.
Business Intelligence	Fogli di calcolo di Excel basati su server, oltre a componenti di Business Intelligence (dashboard, report, web part) integrati nel portale e connessi a SQL Server Analysis Services.
Comunicazione e collaborazione	Supporto per funzionalità Unified Communications integrato nella piattaforma.

La composizione nel livello di presentazione

Il primo tipo di contenitore nel livello di presentazione è l'applicazione client Microsoft Office (Excel, Word, InfoPath). Queste applicazioni sono contenitori personalizzabili che ora possono estrarre più facilmente informazioni e funzionalità da applicazioni line-of-business tramite riquadri attività personalizzati, barre multifunzione personalizzate e azioni che presentano agli utenti dati e operazioni nel contesto dell'attività corrente. Il tipo di componente che può essere ospitato in questi contenitori è il documento in formato XML aperto. Questa è la nuova rappresentazione XML dei documenti di Microsoft Office, che consente un'avanzata elaborazione sul lato server delle informazioni che contiene, come illustrato nella figura 4.

Figura 4. Le applicazioni client Office sono contenitori personalizzabili per i contenuti in formato XML aperto.

Il secondo tipo di contenitore è un portale Web, basato su Windows SharePoint Services (WSS) e Microsoft Office SharePoint Server (MOSS). WSS 3.0 offre la seguente gerarchia di contenitori, come illustrato nella figura 5:

• Farm. Installazione di uno o più server Web con bilanciamento del carico e server back-end, con un database di configurazione.

• Applicazione Web. Sito Web di IIS, esteso per l'utilizzo di WSS, che può ospitare raccolte siti.

• Raccolta siti. Contenitore di siti WSS, presente all'interno di uno specifico database di contenuti. Una raccolta siti contiene un sito principale e siti figlio facoltativi e rappresenta l'unità per la proprietà, la proteggibilità e la ripristinabilità.

• Sito. Contenitore per siti figlio, pagine e contenuti come elenchi e raccolte documenti.

• Pagina. Contenitore per aree web part e web part.

• Area web part. Contenitore per web part.

• Web part. Componente che visualizza i contenuti in una pagina in forma modulare e che rappresenta il mezzo principale per la personalizzazione delle pagine da parte degli utenti.

Figura 5. Contenitori forniti da Windows SharePoint Services (fare clic per ingrandire l'immagine)

Mentre WSS offre il supporto per lo sviluppo di raccolte siti per la collaborazione in team, MOSS fornisce funzionalità di portale basate su WSS, con ulteriori capacità. Ad esempio, MOSS offre funzionalità avanzate di ricerca, connettività ad archivi dati aziendali e Business Intelligence. In ogni caso, un portale MOSS è una raccolta siti di WSS, così come una gerarchia di siti WSS. MOSS inoltre include una raccolta web part che contiene un ampio set di web part pronte all'uso, ad esempio per l'estrazione di grafici e fogli di calcolo di Microsoft Office Excel. I provider di soluzioni possono anche fornire web part personalizzate per funzionalità specifiche a livello di applicazione o di dominio, che possono quindi essere caricate in WSS. Gli information worker possono personalizzare le pagine aggiungendo web part dalla raccolta, rimuovendo web part da una pagina o riorganizzando il layout.

La composizione nel livello di produttività

Microsoft Office System 2007 offre numerosi metodi diversi per condividere informazioni e collaborare al loro utilizzo. Ad esempio, l'archiviazione sul lato server fornisce contenitori per i documenti in-process e altri tipi di contenuti eterogenei con controllo delle versioni. Questo consente la collaborazione in situazioni impreviste o non pianificate. È difficile acquisire tutte le complesse interazioni tra persone in un sistema BPM (Business Process Management), perché il lavoro in genere non si svolge secondo i piani. Nelle tradizionali architetture a tre livelli vi è uno scarso supporto per questo aspetto al di là della memorizzazione temporanea dei documenti nei dischi rigidi dei computer personali o nei server di posta elettronica e talvolta può essere difficile decidere quale versione di un documento è quella corretta. In Microsoft Office System 2007, invece, è possibile configurare raccolte documenti con funzionalità di controllo delle versioni per la memorizzazione dei documenti nelle fasi intermedie di un processo di business, aumentando la facilità di gestione e la possibilità di un ripristino senza problemi in caso di eventi imprevisti. WSS offre i seguenti tipi di archiviazione:

• Elenco. Contenitore per elementi, che può essere di tipo predefinito o personalizzato. Tradizionalmente si trattava dell'unità atomica di archiviazione, ma ora un elenco può memorizzare grandi quantità di dati, come Knowledge Base o contenuti Web. È inoltre disponibile un supporto incorporato per indici e query.

• Raccolta documenti. Tipi speciali di elenchi che supportano il controllo delle versioni e il controllo del codice sorgente dei documenti. Ad esempio, i moduli InfoPath possono essere memorizzati in raccolte moduli, i report in raccolte report e altri documenti in raccolte documenti.

Figura 6. Architettura per i flussi di lavoro di SharePoint (fare clic per ingrandire l'immagine)

Gli information worker possono aggiungere raccolte documenti autonomamente e specificare particolari modelli di documento da utilizzare per tutti i documenti nelle raccolte. Un analista aziendale potrebbe ad esempio utilizzare lo strumento di progettazione WYSIWYG di InfoPath per creare un modulo, quindi usare questo modulo come modello per creare una raccolta moduli. Ogni volta che gli utenti creano un nuovo documento all'interno della raccolta, verrà utilizzato questo modello per creare un modulo vuoto. Microsoft Office System 2007 incorpora anche un supporto sul lato server per Windows Workflow Foundation (WF). Il motore di runtime di WF è ospitato in MOSS e opera come un contenitore per la logica business che può essere collegato a elementi di lavoro e documenti nella forma di flussi di lavoro. Questi flussi di lavoro possono essere associati a elenchi, raccolte documenti o particolari tipi di contenuti. Vengono avviati e completati da azioni da parte degli utenti e sono gestiti tramite elenchi attività di WSS. Ad esempio, le attività del flusso di lavoro creano e aggiornano elementi attività in base alle esigenze e gli utenti possono tenere traccia dell'avanzamento del flusso di lavoro mediante tabelle di cronologia. Anche le applicazioni client Microsoft Office 2007 supportano i flussi di lavoro. Possono essere utilizzate per l'avvio, la configurazione, il completamento e la personalizzazione ad hoc dei flussi di lavoro (inoltro/delega).

I flussi di lavoro possono essere associati a elenchi, raccolte documenti o particolari tipi di contenuti. Queste associazioni ai modelli di WF sono registrate in una tabella di associazione dei flussi di lavoro a livello di farm. I modelli di WF sono definiti da metadati XML e possono includere sia moduli che assembly dei flussi di lavoro. Ad esempio, quando gli utenti creano una raccolta documenti, possono scegliere di associare tale raccolta a un particolare flusso di lavoro e specificare le condizioni in cui il flusso di lavoro viene attivato (ad esempio, in caso di modifica o creazione di un documento di una raccolta). Questo flusso di lavoro può supportare un determinato processo di business o la gestione del ciclo di vita dei documenti.

L'integrazione di Microsoft Office System 2007 con WF offre numerosi vantaggi (figura 7). Semplici processi di business possono essere automatizzati in un modo completamente integrato nell'interfaccia di SharePoint. Gli utenti hanno a disposizione funzionalità self-service, come il supporto per un'ampia gamma di scenari di routing e registrazione dei documenti controllati dagli utenti, in un modo che riduce il coinvolgimento del personale IT nell'assemblaggio di semplici applicazioni. WF offre inoltre ai provider di soluzioni verticali un punto di extensibility per il deployment di regole e logiche business personalizzate nei contenitori forniti da Microsoft Office System 2007.

Figura 7. Hosting di flussi di lavoro con WSS (fare clic per ingrandire l'immagine)

Infine, il livello di produttività deve anche fornire una soluzione lightweight per la creazione e la pubblicazione di informazioni e report. Questo è supportato da Microsoft Office System 2007, che è integrato con SQL Server Reporting Services e fornisce i seguenti componenti:

• Centro report. Un modello per la creazione di siti di reporting WSS.

• Raccolta report. Una raccolta documenti con uno speciale supporto per la memorizzazione di report.

• Dashboard. Una pagina WSS assemblata a partire da web part di reporting.

• Visualizzatore report. Una web part per la visualizzazione di report resi disponibili da SQL Server Reporting Services.

• Web part. Per la visualizzazione di grafici e tabelle di Excel.

• Web part ed elenco KPI (Key Performance Indicator). Gli information worker possono scegliere le metriche per questo elemento in diversi modi.

Un dashboard può essere fornito agli utenti come modello di reporting basato su una specifica funzione di business, come vendite, marketing o gestione dell'inventario.

La composizione nel livello applicazioni

In genere, la logica business strutturata risiede nel livello applicazioni. Può trattarsi di un'applicazione line-of-business come un sistema ERP (Enterprise Resource Planning) o un'orchestrazione tra diversi sistemi come un sistema BPM. Il livello applicazioni solitamente include sia sistemi transazionali che sistemi di supporto ai processi decisionali. Vi sono diversi modi in cui le soluzioni OBA possono consentire la composizione nel livello applicazioni, oltre che utilizzare servizi compositi esposti da altre tecnologie di piattaforma (Microsoft e non Microsoft).

Il primo livello di composizione nel livello applicazioni è tramite raccolte attività pacchettizzate create utilizzando Workflow Foundation e implementate in Microsoft Office System 2007. In precedenza, è stato accennato come è possibile collegare flussi di lavoro a elenchi, raccolte documenti e particolari tipi di contenuti. La figura 7 illustra in che modo il runtime di WF fornisce un contenitore per le attività specifiche delle applicazioni che sono pacchettizzate e implementate come raccolte attività, sulla base delle quali vengono assemblati i flussi di lavoro.

Il secondo livello di composizione nel livello applicazioni fornito da Microsoft Office System 2007 è tramite Excel Services. Si tratta di un motore di calcolo di Excel sul lato server integrato in SharePoint Server. Fornisce un accesso tramite browser a fogli di calcolo dinamici e interattivi implementati sul server, oltre che un accesso tramite Web service a calcoli di Office Excel sul lato server. Con Excel Services, gli utenti avanzati di Excel ora possono fornire una logica applicativa sul lato server in un modo che risulti familiare per loro. Questo significa che MOSS è ora un contenitore per la logica applicativa, come illustrato nella figura 8.

Figura 8. Excel Services in Microsoft Office System 2007

Un terzo modo in cui le soluzioni OBA consentono la composizione nel livello applicazioni è l'utilizzo di servizi compositi esposti da altre tecnologie di piattaforma. Microsoft Office System 2007 può essere completamente integrato in un'architettura SOA. Se l'infrastruttura per i servizi di un'organizzazione è già in fase di sviluppo, queste interfacce possono essere utilizzate da Microsoft Office System 2007. Questo può essere eseguito in due modi. Il primo è richiamare interfacce Web service in attività integrate in flussi di lavoro implementati nel livello di produttività. Il secondo è tramite Catalogo dati business, descritto nella sezione seguente.

La composizione nel livello dati

Microsoft Office System 2007 include anche la funzionalità Catalogo dati business, eseguita sul server come servizio condiviso. È in grado di leggere dati da diversi tipi di origini dati (database, cubi di Analysis Services e Web service), quindi di visualizzarli nel portale tramite tabelle ed elenchi di SharePoint. Opera come repository di metadati per le descrizioni delle entità dei dati di business e dei relativi attributi, oltre che per il mapping di queste entità agli archivi dati all'interno dell'organizzazione, come illustrato nella figura 9.

Figura 9. Catalogo dati business

Anche se Catalogo dati business non può essere utilizzato per creare un'entità mappata a più archivi dati, è possibile definire relazioni che collegano entità, come ad esempio relazioni padre-figlio. Pertanto, Catalogo dati business può essere usato per creare collegamenti lightweight tra entità dati nell'organizzazione, in modo simile a un thesaurus aziendale. Le entità definite da Catalogo dati business possono quindi essere ricollegate a Microsoft Office System 2007, ad esempio in elenchi di SharePoint. Questo consente agli utenti di comporre pagine con collegamenti a dati back-end e di attraversare tabelle di dati seguendo le relazioni tra le entità.

Benché Catalogo dati business consenta la composizione dei dati, fornisce un accesso in sola lettura ai dati. Tuttavia, gli utenti possono utilizzare Catalogo dati business per modellare azioni che possono essere eseguite su un'entità dati, dove un'azione è definita da un nome, un URL e un set di attributi ricavati dalla definizione dell'entità e passati a questo URL. Questo può quindi essere utilizzato da un menu a discesa in un elenco di SharePoint. L'URL può corrispondere a un Web service o a un documento sul lato server come un modulo InfoPath, con codice code-behind per precompilare il modulo dal contesto passato da Catalogo dati business. Gli information worker possono quindi utilizzare il portale per creare applicazioni lightweight in SharePoint con tabelle ed elenchi che estraggono i dati e le azioni di Catalogo dati business.

Riepilogo delle funzionalità per la composizione

La figura 10 mostra in che modo alcune delle funzionalità di Microsoft Office System 2007 sono associate ai livelli della figura 2. La tabella 2 fornisce un elenco dei tipi di risorse che possono essere utilizzati per la composizione.

Figura 10. Funzionalità della piattaforma applicativa Microsoft Office System 2007 associate ai livelli (fare clic per ingrandire l'immagine)

Tabella 2. Elenco di risorse applicative per la composizione

Documenti in formato XML aperto	Dashboard
Flussi di lavoro	Siti
Attività di business	Pagine
Regole di business	Connessioni dati
Schemi	Autorizzazioni
Metriche	Report
Web part	Dashboard

 

Sviluppo di una soluzione Office Business Applications

Vi sono due fasi per lo sviluppo di un processo di business standard come una soluzione OBA.

1. Creare un pacchetto di processo, che contiene i metadati del processo e componenti applicativi pacchettizzati.

2. Implementare il pacchetto di processo nei sistemi di produzione. Entrambe queste fasi sono descritte in dettaglio nella sezione seguente.

Creazione di un pacchetto di processo

1. Sviluppare interfacce utente per processi basati sui documenti nelle applicazioni client Microsoft Office, utilizzando Visual Studio Tools per Office (VSTO).

2. Sviluppare siti WSS con web part specifiche per le attività, pagine, dashboard, elenchi e raccolte documenti, dove ogni sito è progettato per una particolare funzione o processo di business. Questi siti possono essere utilizzati per creare modelli di sito per la pacchettizzazione di un processo di business standard in una soluzione OBA.

3. Utilizzare Workflow Foundation per collegare tra loro elenchi e raccolte documenti nei siti, con regole e logica business sul lato server per l'elaborazione sul lato server di documenti in-process. Pacchettizzare questi flussi di lavoro in assembly per il deployment.

4. Definire punti di contatto dai flussi di lavoro nella soluzione OBA ai sistemi line-of-business back-end. I metadati del pacchetto di processo devono includere le interfacce dei Web service per questa integrazione. Le effettive connessioni dovranno essere effettuate in fase di deployment.

5. Definire entità di Catalogo dati business per le connessioni dati necessarie per i processi interfunzionali integrati nella soluzione OBA.

6. Aggiungere il supporto decisionale definendo metriche, report, dashboard, grafici e tabelle di Excel da utilizzare nei siti WSS.

7. Pacchettizzare la soluzione come pacchetto di processo (modelli di siti WSS, assembly WF, documenti di Office e così via) utilizzando i tipi di componenti nella tabella 2.

Deployment del pacchetto di processo nei sistemi di produzione

1. Implementare i siti WSS sul server SharePoint nel sistema di produzione.

2. Configurare le connessioni dai flussi di lavoro alle applicazioni line-of-business utilizzando Web service o altri adattatori personalizzati.

3. Configurare le connessioni dati collegando le definizioni delle entità dati di Catalogo dati business agli effettivi archivi di dati.

4. Effettuare il provisioning degli utenti.

Deployment di un'applicazione composita nell'organizzazione

Un modo per effettuare il deployment di una soluzione OBA nell'organizzazione potrebbe essere il seguente:

1. Implementare i siti di SharePoint a livello dei reparti.

2. Connettere diversi reparti.

3. Connettere processi di business ad applicazioni line-of-business.

4. Aggiungere connessioni dati per i processi interfunzionali.

5. Connettere i processi di business ai sistemi "perimetrali".

 

Sviluppo di siti SharePoint di reparto per l'hosting di documenti e processi

I siti SharePoint devono essere configurati a livello di reparto per consentire la collaborazione in team, come illustrato nella figura 11. Questi siti disporranno di raccolte documenti per la memorizzazione di documenti in-process. Gli information worker del team avranno a disposizione le proprie pagine, personalizzate a partire dai modelli disponibili nel sito del team.

Figura 11. Implementazione di soluzioni OBA in siti di reparto per la collaborazione in team, il coordinamento delle attività con modelli dei processi di business e la connessione a sistemi line-of-business tramite un'infrastruttura di servizi.

Si tenga presente che la figura 11 illustra una visione logica dell'architettura, dal momento che tutti i siti di reparto in genere non verrebbero eseguiti in server separati. Diversi siti potrebbero invece essere eseguiti in un solo server, come mostrato nella figura 5, e l'architettura fisica (ovvero lo scenario di deployment per i server SharePoint) potrebbe essere scelta in base ad altri fattori quali carico, disponibilità e distribuzione geografica dei team.

I documenti in-process sono memorizzati in raccolte documenti e sono associati a flussi di lavoro che vengono richiamati ogni volta che un documento viene creato o modificato. Un flusso di lavoro di questo tipo potrebbe eseguire regole di convalida sui documenti, applicare ai dati azioni e criteri di approvazione, pulire, convalidare o filtrare i dati o aggiornare sistemi back-end.

In aggiunta ai flussi di lavoro dei processi di business, i documenti in-process vengono sottoposti a uno specifico ciclo di vita, da creazione e collaborazione a gestione e pubblicazione, fino ad archiviazione ed eliminazione. Ogni volta che un documento raggiunge una di queste fasi, il flusso di lavoro appropriato può essere impostato per l'attivazione, ad esempio per la gestione del processo di archiviazione.

Connessione di diversi reparti

Come illustrato nella figura 11, i modelli dei processi di business coordinano le attività sia all'interno di un team che tra diversi reparti. All'interno di un reparto, i processi di business possono essere modellati utilizzando attività di WF implementate nel server SharePoint che supporta il reparto. Il coordinamento delle attività tra i reparti può essere realizzato tramite processi di collaborazione che gestiscono il ciclo di vita delle singole entità di business (ordini) e anche il ciclo di vita dei processi di business (procure-to-pay).

I processi di business tra diversi reparti potrebbero essere posizionati centralmente nei data center IT o più vicino agli information worker all'interno di server di reparto. Ad esempio, i flussi di lavoro centralizzati e a esecuzione prolungata potrebbero essere eseguiti in Microsoft BizTalk Server, mentre i processi di reparto potrebbero essere eseguiti in flussi di lavoro di WF all'interno del server SharePoint.

Connessione di processi di business ad applicazioni line-of-business

L'orientamento ai servizi è uno dei modi per esporre le attuali applicazioni aziendali in una soluzione OBA.

In questo senso, SOA promuove la modularizzazione nel livello applicazioni, cosa che rappresenta un requisito fondamentale per la composizione e che spiega perché soluzioni OBA e architetture SOA sono elementi complementari. Ciò consente la creazione di nuove applicazioni aziendali interfunzionali, che superano i limiti delle applicazioni attuali.

Un'architettura SOA non è l'unico modo per connettere applicazioni line-of-business a soluzioni OBA. È anche possibile esporre un'infrastruttura di servizi utilizzando altre tecnologie di integrazione, come adattatori personalizzati.

Aggiunta di connessioni dati per processi interfunzionali

Catalogo dati business (figura 9) può essere utilizzato per connettere archivi dati back-end a Microsoft Office System 2007 visualizzando i dati in elenchi e web part di SharePoint. Questo rende possibile creare applicazioni composite per processi interfunzionali nel portale SharePoint, utilizzando una combinazione di Catalogo dati business, elenchi di SharePoint e flussi di lavoro. Ad esempio, Catalogo dati business può essere utilizzato per definire entità in una relazione padre-figlio (come intestazione dell'ordine e dettagli dell'ordine) e gli elenchi di SharePoint possono essere impiegati per visualizzarle. Potrebbe così essere possibile eseguire drill-down dall'elenco che visualizza le informazioni sulle intestazioni alle informazioni dettagliate corrispondenti, seguendo le relazioni padre-figlio. Inoltre, le azioni possono essere modellate nei metadati di Catalogo dati business, il che significa che queste vengono visualizzate come voci di menu nell'elenco di SharePoint. Selezionando una voce in questo menu, il contesto della riga attualmente selezionata verrà passato nell'URL definito per l'azione.

Connessione di processi di business a sistemi perimetrali

Spesso l'ambito di una soluzione OBA non è contenuto all'interno di un'organizzazione. Ad esempio, una soluzione OBA potrebbe supportare un processo di business che deve utilizzare un servizio offerto da un provider di hosting, in uno scenario SaaS (Software as a Service). In alternativa, la soluzione OBA potrebbe dover supportare un processo di business che fornisce un servizio a un'altra organizzazione. Questo si verifica di frequente negli scenari di gestione della supply chain, in cui vengono coinvolti partner. In questi casi, occorre un metodo per trasferire documenti da un information worker a una controparte nell'organizzazione partner. Tale metodo deve essere protetto, affidabile, asincrono e trasparente.

Un modo per realizzare un'architettura end-to-end di questo tipo è illustrato nella figura 12. Sul perimetro dell'organizzazione sono stati configurati message broker per l'invio e la ricezione dei messaggi e documenti scambiati con i partner. I messaggi da differenti partner possono essere ricevuti in più formati e trasmessi tramite diversi canali, come Web service, EDI, posta elettronica, RosettaNet e così via. Inoltre, i messaggi possono essere scambiati secondo un'ampia varietà di schemi: messaggistica unidirezionale, bidirezionale asincrona o bidirezionale sincrona. I message broker devono gestire ogni combinazione di questi formati e schemi di scambio dei messaggi.

Figura 12. Connessione di soluzioni OBA a sistemi "perimetrali"

Una volta ricevuto dal message broker, il messaggio viene elaborato nel singolo formato canonico necessario per i servizi a valle e il messaggio trasformato viene salvato in modo permanente in una coda di messaggi per separare i processi pubblici da quelli privati. Il messaggio viene quindi recuperato dalla coda da un servizio di routing che esamina il messaggio e lo indirizza al destinatario previsto. Tuttavia, prima che il documento raggiunga il destinatario, potrebbe dover essere pre-elaborato da servizi applicativi aziendali come applicazioni line-of-business o orchestrazioni BPM. Regole di business potrebbero essere applicate ai messaggi, per assicurarne la validità e applicare criteri aziendali. Il risultato di tutte queste elaborazioni è un documento che può essere elaborato da un utente con informazioni sufficienti per prendere rapidamente una decisione. Ad esempio, una richiesta di ordine di acquisto ricevuta da un cliente potrebbe essere immessa in un servizio di elaborazione ordini e la risposta ottenuta da questo servizio potrebbe essere utilizzata per generare un documento XML che corrisponde a un modulo InfoPath con una proposta di conferma dell'ordine di acquisto. Il modulo generato potrebbe quindi essere inserito in una raccolta moduli di SharePoint per l'approvazione da parte di un information worker del reparto vendite.

Dopo aver esaminato la proposta di conferma e apportato eventuali modifiche, l'information worker invia il modulo. Questo attiva il flusso di lavoro per la restituzione, che aggiorna il sistema line-of-business e quindi inserisce le informazioni ricavate dal modulo come un documento XML in una coda di messaggi in uscita, come risposta alla richiesta originale. Il message broker infine esegue la conversione nel formato utilizzato dal partner.

Vi sono diversi modi di implementare i message broker sul perimetro, come ad esempio BizTalk Server. Questo offre una soluzione scalabile e gestibile che include acceleratori e adattatori basati su standard, come l'acceleratore RosettaNet per la collaborazione con i partner. Le code che separano i processi interni ed esterni potrebbero essere implementate utilizzando Microsoft SQL Service Broker 2005.

Soluzione Office Business Applications di esempio

Per offrire indicazioni e risorse tecniche sullo sviluppo di soluzioni OBA con un significativo valore di business, un'implementazione di riferimento per una soluzione OBA è disponibile online qui. Questa applicazione di riferimento per la gestione della supply chain riguarda scenari di collaborazione tra differenti livelli di una supply chain.

 

Conclusioni

Microsoft Office System 2007 offre un potente set di funzionalità per lo sviluppo di applicazioni composite, denominate Office Business Applications (OBA). Questo consente la creazione di soluzioni interfunzionali dotate di un'interfaccia utente composita che espone capacità e funzioni di business per un set eterogeneo di risorse IT back-end. Queste soluzioni forniscono inoltre funzionalità di collaborazione che superano il gap tra le tradizionali applicazioni aziendali e gli strumenti di produttività personale.

 

Informazioni sull'autore

Atanu Banerjee è un progettista che fa parte dell'Architecture Strategy Team di Microsoft. Ha 10 anni di esperienza nel settore del software e ha lavorato allo sviluppo di soluzioni per la gestione della supply chain e il controllo dei processi. È entrato in Microsoft da i2 Technologies, dove ha ricoperto il ruolo di Chief Architect per la linea di prodotti dell'azienda per la gestione degli approvvigionamenti e della domanda. In precedenza, ha lavorato nel gruppo Advanced Control Systems di Aspen Technologies. Ha ottenuto un Ph.D. presso la Georgia Tech University nel 1996, oltre a una laurea presso l'IIT Delhi, in India.

Questo articolo è stato pubblicato nell'Architecture Journal, una pubblicazione stampata e online di Microsoft. Per ulteriori articoli di questa pubblicazione, visitare il sito Web di Architecture Journal.