Invio di moduli infopath via e-mail (come allegato) da analizzare con SQL Server 2005?

Question

Stavo solo guardando i requisiti di un nuovo progetto e volevo assicurarmi che questo caso d'uso fosse valido:

• l'utente compila il modulo InfoPath (2003) localmente sul proprio PC
• un pulsante nel modulo di InfoPath intitolato "submit" fa apparire un nuovo messaggio di posta elettronica Outlook (2003) con il modulo infopath allegato. L'utente preme invia e l'e-mail viene inviata a una cassetta postale di scambio.
• il server sql controlla preiodicamente questa casella di posta, scaricando eventuali nuovi invii con il modulo infopath allegato
• sql server analizza l'allegato e i campi all'interno del modulo infopath.

SQL Server è in grado di analizzare gli allegati di posta in questo modo? Qualche avvertimento con questo approccio?

L'attrazione per l'utilizzo di Outlook come tecnologia di invio è che il processo per l'utente è lo stesso se non è in linea. Outlook si sincronizzerà automaticamente quando torneranno online. È essenziale che gli utenti dispongano di un modo per compilare i moduli offline, "inviarli" e quindi sincronizzarsi automaticamente con il server alla successiva connessione online.

modifica: per chiarire, non sto cercando un modo per memorizzare nella cache i dati del modulo dal server > client. Sto cercando di memorizzare nella cache il modulo compilato. La creazione di un'applicazione separata per memorizzare nella cache i report completati sul client non è un'opzione.

Answer 1

Le versioni successive di SQL Server sono in grado di eseguire codice .NET al loro interno e, pertanto, potresti essere in grado di eseguire il polling di una cassetta postale da SQL Server ed elaborare un modulo di InfoPath. Tuttavia, non sono sicuro che lo farei in questo modo.

Potrebbe essere meglio prendere in considerazione la scrittura di un servizio Windows che funzioni in questo modo. Il servizio Windows si avviava, ispezionava la casella di posta di un "account di servizio", leggeva i messaggi, estraeva gli allegati, elaborava l'xml e, infine, scriveva i dati in SQL. Potrebbe anche, presumibilmente, rispondere a quella mail con una conferma o errori se si sono verificate regole commerciali o errori di validazione.

Non sono sicuro di mettere tutta la logica di cui sopra in SQL - per prima cosa, sospetto che avresti avuto problemi con gli account (dovendo avere l'account SQL in esecuzione per poter accedere alla cassetta postale di Exchange account).

Il tuo chilometraggio può variare e dovresti prototiparlo per determinare quale funziona meglio per te, ma proverei a conservare il codice che utilizza Exchange come "coda di lavoro" separato da SQL e inserire solo il codice relativo alla scrittura dei dati in tabelle in SQL.

Answer 2

Non vorrei usare l'approccio sopra descritto. Esistono diversi approcci che mi sembrano più desiderabili rispetto al fatto che SQL Server guardi una cassetta postale di Exchange. Il punto principale che fai e un requisito importante è che il modulo di InfoPath possa funzionare in modalità offline. Vorrei pensare alla modalità "offline" " e il "trasferimento dati" parti del progetto come due parti distinte e separate: 1) Il modulo e i dati devono essere archiviati sul client fino a quando non è disponibile una connessione a Internet e 2) una volta che la connessione è disponibile, il modulo e i dati devono essere trasferiti al server .

Puoi configurare il tuo modulo di InfoPath in modo che invii direttamente a SQL Server e ignori Exchange " middleman " interamente. L'impostazione in InfoPath durante la progettazione del modulo è piuttosto semplice: 1) abiliti " Invia dati " per la connessione e 2) configurare le opzioni di invio. Questo articolo contiene i dettagli su come farlo. Inoltre, la tua connessione a SQL Server potrebbe essere configurata per l'uso offline, come discusso in questo articolo . L'unico avvertimento con questo approccio è che potrebbe essere necessario modificare lo schema del database per supportarlo.

Un altro approccio consiste nell'inviare il modulo InfoPath a un endpoint HTTP di SQL Server 2005. Il client InfoPath è solo un editor XML glorificato e l'endpoint HTTP è sostanzialmente un nome diverso per un servizio web. Si ricevono i dati del modulo sull'endpoint HTTP in una tabella di gestione temporanea in cui i dati sono archiviati come XML e quindi è possibile eseguire l'analisi di tali dati dall'area di gestione temporanea. Tuttavia dovrai configurare la connessione di InfoPath per l'utilizzo offline. Il principale avvertimento di questo approccio è che Microsoft deprecherà l'endpoint HTTP in SQL Server 2008 a favore di WCF.

E l'altro approccio che vorrei suggerire è usare lo stesso WCF per ricevere i dati del modulo XML dal client InfoPath. Questo approccio richiederebbe di collegare l'origine dati del modulo al servizio Web WCF in fase di progettazione e quindi di configurare il modulo per l'utilizzo offline.

Spero che questo ti sia utile e per lo meno ti punti nella giusta direzione.

Answer 3

Ho visto progetti simili che sono ricorsi a un'edizione Express sul client, salvano l'infopath (o i dati delle app) in Express e utilizzano Service Broker per consegnare al centro, a causa della semantica della consegna garantita di SSB vs. mail. Ciò offre una soluzione all SQL più semplice da vendere all'IT e non è necessario il polling sul server. Inoltre non dovrai occuparti dell'analisi MIME, è tutta l'elaborazione XML diretta. Non è per i deboli di cuore, tuttavia, mettere in funzione SSB è una sfida. Se decidi di andare con la consegna della posta, un servizio esterno sarà probabilmente più facile da costruire, eseguire il debug e risolvere i problemi. Ci sono alcuni punti più fini a cui dovresti avere una risposta: -Come manterrai coerenti le operazioni di cancellazione della posta e le operazioni di scrittura della tabella? Il componente deve coinvolgere la lettura / eliminazione di Exchange e l'inserimento di SQL in una transazione distribuita. - La tua logica è pronta a gestire i documenti di infopath che non funzionano? il trasporto di posta non fornisce assolutamente alcuna garanzia sull'ordine di consegna, quindi potresti vedere un documento "Elimina ordine" prima del documento "Crea ordine" - Come rileverai i documenti mancanti (non consegnati per posta)? Implementerai un numero di sequenza del mittente e finirai per reinventare TCP in cima alla posta? - La tua elaborazione consente un processo parallelo di documenti correlati? Se il thread 1 preleva il documento 1 e il thread 2 preleva il documento 2 dallo stesso mittente e il documento 2 è correlato al documento 1 (ad es. Fare riferimento alla stessa transazione commerciale), cosa accadrà alla scrittura del database? Si bloccherà, perderà un aggiornamento, verrà eseguito il rollback?

Ci sono molti draghi sotto il ponte davanti ...