Distribuzione di Microsoft Dynamics CRM 4.0

Aaron Elder

In un riepilogo delle:

• Componenti software di un sistema CRM
• Ciclo di vita dello sviluppo
• Gli elementi di una soluzione CRM
• Uno sguardo multi-tenancy

Contenuto

Soluzione Development Lifecycle
Gli elementi di una soluzione CRM
Per quanto riguarda Multi-Tenancy?
Considerazioni di progettazione
Chiave Takeaways

Se è utilizzato per a pensare di CRM solo strumento di gestione vendite e marketing, considerare nuovamente.Customer Relationship Management di Microsoft Dynamics è una piattaforma per lo sviluppo di applicazioni che gestire e tenere traccia di informazioni e processi correlati agli oggetti reali.Questi oggetti sia i clienti, ma possono anche anche essere praticamente qualsiasi entità (o attività correlate) che è necessario gestire.

Come con qualsiasi soluzione personalizzata su larga scala, esistono alcune nozioni fondamentali correlati a distribuzione che devono essere riconosciuto.In questo articolo, mi intendo coprono alcuni concetti fondamentali correlati a distribuzione Microsoft Dynamics CRM, tra cui come questi concetti possono essere utilizzati per supportare una distribuzione di ciclo di vita del prodotto completo.Inoltre verrà illustrato più distribuzioni come parte di una versione di sola soluzione e su come multi-tenancy deve e non deve essere utilizzato come parte del ciclo di vita della intera soluzione di gestione.

SI desidera rendere chiaro in esterno di questo articolo quando fa riferimento a Microsoft Dynamics CRM "soluzioni", si intende totality dell'tutte le personalizzazioni, le estensioni, codice personalizzato, le modifiche dello schema e così via.Non è una soluzione solo una cosa; è tutte le modifiche contemporaneamente.

Dietro le quinte, una soluzione di Microsoft Dynamics CRM è un'applicazione ASP.NET 2.0 e Microsoft .NET Framework 3.5 basate sui dati Web standard.Il sistema a tre livelli include i seguenti componenti principali:

livello dati Database di SQL Server 2005 o SQL Server 2008.Utilizzo di SQL Server 2008 richiede una correzione rapida come descritto nell'articolo della Knowledge Base"Supporto per l'esecuzione di Microsoft Dynamics CRM 4.0 con Microsoft SQL Server 2008."

Livello intermedioMicrosoft Internet Information Services (IIS) 6.0 o versione successiva front-end Web, SQL Server Reporting Services (SRS, Site Replication Service) 2005 o 2008 SRS; 3.5 ASP.NET, servizi di Windows personalizzata.

Livello clientInternet Explorer 6.0 o versione successiva client di Microsoft ASP.NET 2.0 o versioni successive il client Microsoft Office Outlook 2003 o 2007 (con accesso facoltativo non in linea); altri come consumer SDK e i client mobili terze parti.

Microsoft Dynamics CRM fa inoltre affidamento su una varietà di sistemi esterni, incluso Microsoft Exchange Server 2003 o versione successiva e Active Directory.

Soluzione Development Lifecycle

Una soluzione di Microsoft Dynamics CRM passa attraverso il ciclo di stesso vita che sarebbe un progetto di sviluppo dell'applicazione personalizzata, che potrebbe aspetto come il processo descritto inNella figura 1 .

Figura 1 lo sviluppo di applicazioni ciclo

L'intero processo potrebbe essere supportata dalle diversi ambienti che insieme costituiscono i sistemi sviluppo, test e produzione.Nel mondo di qualsiasi applicazione enterprise articolato, naturalmente, possibile attivare fuori da ovviamente complessi.Se, ad esempio, si deve rispecchiare l'ambienti, è possibile terminare i con qualcosa di simile nella Figura 2 .

Nella figura 2 mirroring gli ambienti dev, test e produzione

Tre domini, tre controller di dominio, tre server di posta elettronica, tre server Web e tre server di database, e questo modello presuppone che il servizio di replica siti e CRM siano nella stessa e non accetta in operazioni account such as bilanciamento del carico.Ora si immagini è aggiungere ridondanza e alcuni servizi esterni, ad esempio Microsoft Office SharePoint Services (MOSS) è possibile terminare i con uno schema come quello nella Figura 3 .

Nella figura 3 Increasing complessità

Per motivi di costo e la complessità, potrebbero essere considerati compromessi per bilanciare la necessità di ambiente isolamento rispetto al necessario mantenere i costi verso il basso e la facilità di gestione dei.Le organizzazioni hanno era pertanto a un'ampia gamma di tecniche, quali la virtualizzazione e Microsoft Dynamics CRM funzioni multi-tenancy incorporate, per risolvere questi problemi.

Durante la progettazione di un insieme di ambienti per supportare il ciclo di vita del progetto CRM, sono presenti più scuole del pensiero e, in base alle quali principi sono importanti, è possibile passare un modo o l'altro.A un'estremità dello spettro, finestre di progettazione alzare di livello isolamento totale che utilizza la replica esatta.Questi utenti ritiene che l'unico modo per convalidare che qualcosa funzionerà di fuori della produzione siano affinché un ambiente di prova è identico a ambiente di produzione al 100 %.Tutti i server, ogni bit e tutte le impostazioni devono essere identici e completamente isolata da sviluppo e produzione di tester e IT per accettare e ritiene che qualcosa funziona in produzione.

Al contrario, altri utenti ritiene che tale tipo di isolamento non veramente importante affatto.Se possibile, si potrebbe sviluppare e testare direttamente nell'ambiente di produzione.Tendono a visualizzare la ridondanza come un rifiuti del tempo e denaro, e sono determinati recapito sarebbe più semplice se sono semplicemente Impossibile ottenere in tale posizione e creare elementi di lavoro.

Probabilmente, rientra in un punto qualsiasi tra queste extremes e verrà essere aperto l'idea che quando si tratta di una soluzione di Microsoft Dynamics CRM, è possibile sviluppare un ibrido saldi complessità, costo, isolamento e gestibilità.

Gli elementi di una soluzione CRM

Dei componenti di soluzioni di Microsoft Dynamics CRM possono essere suddiviso in quattro bucket principale e la soluzione potrebbe includere uno, due, tre o tutti i quattro.

le personalizzazioni Sono includono modulo, griglia, schema e i metadati; ruoli di protezione; i flussi di lavoro; le impostazioni di sistema e modelli.Le personalizzazioni di Microsoft Dynamics CRM sono disponibili come uno o più (in genere uno o due) compresso file XML.Vengono importati in una distribuzione di CRM tramite client Outlook o Web "Settings | Customization" area e quindi vengono "pubblicati" per rendere attivo.Tutto ciò può essere automatizzato tramite codice è scritto in Microsoft Dynamics CRM SDK.

le estensioni Questi comprendono i report e codice personalizzato, ad esempio plug-in che deve essere distribuito separatamente dalle personalizzazioni.Le informazioni di registrazione plug-in viene memorizzate come un file XML e possono essere distribuite tramite entrambi una riga di comando o applicazione Windows Form forniti da Microsoft.Questo può essere automatizzato tramite codice scritto in Microsoft Dynamics CRM SDK.

codice personalizzato Qualsiasi sviluppato come parte della soluzione, ed essere potrebbe composto esterno servizi Web, personalizzati componenti dell'applicazione Web e così via.Le regole e procedure per la distribuzione di codice personalizzato devono essere non diversi da per altre applicazione Web personalizzata.

i dati Le informazioni necessarie per essere importato in un ambiente per quell'ambiente alla funzione.Potrebbe trattarsi di dati di dominio (ad esempio un elenco di codici di prodotto) o gli utenti.I dati necessari alla soluzione possono essere distribuiti nell'istanza di Microsoft Dynamics CRM utilizzando codice di script o funzionalità di un'importazione in blocco di CRM o con un tipo di processo esterno utilizzando BizTalk o un altro strumento ETL (estrazione, trasformazione, carico).Alcuni dati, ad esempio utenti, sono necessario creare manualmente o tramite chiamate di Microsoft Dynamics CRM SDK.

Desidera considerare le distribuzioni di CRM soluzione solo come se fossero le distribuzioni di sviluppo dell'applicazione personalizzata.Ciò significa che durante lo sviluppo e test, ogni nuova build della soluzione è installato da un sistema di pulitura base e il processo è come ripetibili e script possibili.

Per quanto riguarda Multi-Tenancy?

Ora verranno illustrati l'ambiente si intende distribuirli in dovrebbe aspetto.Potrebbe avere leggere sul supporto di Enterprise Edition di Microsoft Dynamics CRM 4.0 per una caratteristica denominata multi-tenancy, che consente di suddividere più istanze di Microsoft Dynamics CRM all'interno di una singola distribuzione.Questo significa che diverse organizzazioni completamente distinte con i propri report, flusso di lavoro, le personalizzazioni e schemi possono essere eseguite sull'insieme stesso dell'hardware utilizzando gli stessi server fisico e lo stesso istanze di database e siti Web IIS.

Questo potrebbe a prima vista sembra essere panacea che risolve tutti i nostri gestibilità, isolamento, e costi conundrums.Una soluzione di questo tipo potrebbe essere visualizzata come illustrato nella Figura 4 .

Figura 4 una soluzione più tenancy--solo

Questo sembra logico poiché ogni organizzazione ottiene il proprio database fisico di SQL Server condiviso o istanza (che include le personalizzazioni, flussi di lavoro, gli utenti, ruoli e le impostazioni) e la relativa cartella SQL Reporting Services.

Questa funziona modello perfettamente e per le organizzazioni distinte fanno parte di team diversi o soluzioni di reparto.Dopo tutto, questo è quali multi-tenancy è stata progettata per.Mentre è vero che ogni organizzazione (o il titolare) Ottiene il proprio database, tutte le condividono la stessa unità organizzativa (OU) e i gruppi di Active Directory e verranno tutti condividono la stessa piattaforma servizi e dell'applicazione front-end.Ciò significa che il servizio asincrono stesso e il sito Web IIS verranno condivisi tra le organizzazioni.Il server front-end sono in grado di per "host" queste organizzazioni diverse tramite un provider di URL che determina, basato SULL'URL, quali organizzazione a host.

Richiedere tali URL come esempio: crmserver/ContosoDevOrg/loader.aspx e crmserver/ContosoTestOrg/loader.aspx.Il server CRM esamina la directory principale per determinare il nome dell'organizzazione per soddisfare i.Se non principale dell'organizzazione viene trovato alcun nome, come nel caso di crmserver/loader.aspx, il server predefinito dell'organizzazione prima creato nella distribuzione o quella in cui l'utente chiamante ha accesso.

Poiché lo stesso sito Web viene utilizzato per entrambe le organizzazioni, se si dispone di personalizzato codice come parte della soluzione, troppo verrà condivisi da due organizzazioni, ad esempio, crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx e crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.

Entrambi selezionare il file stesso fisico su disco, ad esempio C:\inetpub\wwwroot\isv\mycustomdialog.aspx.Poiché è probabile che la versione di un'estensione personalizzata sarebbe diverse tra sviluppo, test e produzione, questo può rappresentare un problema grave.Si supponga, ad esempio, che genera 11 dell'applicazione è attualmente sviluppati, mentre crea 9 è in test di accettazione utente (i test di accettazione utente) per il test.Se si tenta di utilizzare multi-tenancy per risolvere il problema di ambiente, sarà necessario un tempo hardware isolare le generazioni due.In tal caso, alcuni potrebbero essere tempted per provare la soluzione illustrata nella Figura 5 .

Nella figura 5 attempting utilizzare diversi server IIS per segregate il codice di soluzioni personalizzate

In tale modello (se si utilizza l'indirizzo di bilanciamento del carico di rete non è più), gli utenti potrebbero visite un URL che è simile al seguente:

Sviluppo192.168.1.100/ContosoDevOrg/Loader.aspx

Test192.168.1.105/ContosoTestOrg/Loader.aspx

Produzione192.168.1.110/Contoso/Loader.aspx

Questo modello consente di avere tre separare i server front-end che ospita tre diverse organizzazioni, con tre basi di codice diverso su disco.Purché inavvertitamente un utente non ha raggiunto l'organizzazione non valido sul server sbagliato, tutto dovrebbe funzionare uscita perfettamente.

Sfortunatamente, poiché tutti i server front-end vengono considerati parte di distribuzione stesso, problemi avviare verificarsi un po'ulteriormente downstream rispetto a può realizzare a prima vista.Questo effettivamente diventerà una sfida se la soluzione utilizza plug-in asincrona o i flussi di lavoro, in quanto mentre è possibile controllare quali server gli utenti visite, non è possibile controllare quale servizio asincrono elaborerà gli eventi e richieste per cui le organizzazioni.

Questo avviene perché tutti i servizi asincroni di una distribuzione lavoro in modo round robin, e, di conseguenza, servizio asincrono del server di sviluppo potrebbe elaborare un flusso di lavoro, processo di sistema o risposta plug-in asincrona a una richiesta dal server di prova, pertanto sapone sulla destra del requisito di isolamento all'esterno del limite.Inoltre, se il codice personalizzato che viene eseguito dal processo asincrono si basa sui file devono essere distribuiti sul disco per il server (ad esempio un file di configurazione o un file nella Global Assembly Cache o Global Assembly Cache), sarà possibile ottenere conflitti di versione.

È importante tenere presente che, nella maggior parte dei casi, questi problemi verificano solo quando si scrive codice personalizzato che deve essere distribuito su disco o se il codice personalizzato si basa sulle risorse che sarebbero disponibili solo in o da un server specifico.Se la soluzione è semplice e solo utilizza le personalizzazioni (schemi, moduli, visualizzazioni e così via), i flussi di lavoro e report, sarà possibile disporre gli eventuali problemi utilizzando l'approccio nella Figura 4 .

In modo che cos'è multi-tenancy per e quando è una soluzione valida per gli ambienti del ciclo di vita del prodotto?Multi-tenancy è stato originariamente progettato per risolvere un problema hardware correlato l'hosting di più titolari distinti in un ambiente di produzione e ciò avviene molto bene.In precedenza, in Microsoft Dynamics CRM 3.0, ogni distribuzione o il titolare doveva includere il proprio SQL server dedicato o istanza di SQL Server, nonché un server front-end.

Questo era true per molti motivi, tra cui il fatto che le impostazioni di specifici di distribuzione utilizzato per essere memorizzate nel Registro di sistema e sul disco.Queste configurazioni sono ora spostato tutto al database, in modo che un server di applicazioni unico sia in grado di gestire più organizzazioni.Multi-tenancy risulta utile per le versioni host di CRM incluso Microsoft Dynamics CRM Online.

Considerazioni di progettazione

Vengono ora che si tenere in considerazione alcuni potenziali problemi, verranno illustrati alcuni punti da tenere presenti quando si progetta la distribuzione.La risposta, naturalmente, è che varia.È certamente possibile eseguire un ambiente completo di CRM (inclusi i controller di dominio, SQL server e server Web) in una singola casella come si vede la dimostrazione di Microsoft Dynamics CRM 4.0 Virtual Machine (vedere la barra laterale "Risorse di CRM" per l'URL).È molto comune per utilizzare un'immagine di virtuale singolo computer per un ambiente di sviluppo.Per il test, tuttavia, è importante per convalidare l'ambiente di produzione chiave attentamente e, per questo motivo, consiglia con il mirror di ambiente di test l'ambiente di produzione in termini di struttura, ma non capacità.L'ambiente potrebbe essere simile quella nella Figura 6 .

Nella figura 6 la struttura di ambiente di test dovrebbe rispecchiare la struttura di produzione

In questo approccio, si tenta di ridurre al minimo hardware fisico dell'infrastruttura tramite la virtualizzazione e ulteriore tentativo di ridurre a icona risorse di virtualizzazione, virtualizing solo gli scenari chiave devono sottoporre a test.Sarà possibile consentire gli sviluppatori sviluppare un'immagine server singolo (o le immagini,) se hanno i propri computer virtuale ai desktop personali se assicurarsi che verrà prestare attenzione e conoscere l'ambiente in cui verrà distribuita la soluzione.I problemi che gli sviluppatori devono pagare l'attenzione su sono gli stessi problemi che si deve creando l'ambiente di prova per convalidare, inclusi:

Verificare le impostazioni configurabiliNon, supponga ad esempio, che il server risponderà a localhost o una porta specifica.

Essere Aware di più serverNon presupporre operazioni funzionerà senza impostare utenti proxy o di attendibilità per la delega.

mantenere il bilanciamento del carico presente del Fare attenzione molto con lo stato sessione e la memorizzazione nella cache.Si noti che Microsoft Dynamics CRM è progettato per essere completamente privo di stato e lavoro con un sistema di bilanciamento del carico round robin.

considerare Multi-Tenancy Quando più titolari sono ospitati su un unico computer, condividere lo stesso spazio di processo.In tal caso elementi, ad esempio cache necessario per la chiave dal nome dell'organizzazione in modo che gli utenti di un'organizzazione non utilizzerà inavvertitamente i dati da un'altra organizzazione.Inoltre, quando si dispone di codice sul lato client contenente i collegamenti o chiamate al server, è necessario assicurarsi che le chiamate mantenere il nome dell'organizzazione NELL'URL; in caso contrario, si potrebbe scelto l'organizzazione predefinita o un'organizzazione che non prevedono.

Risorse CRM

Guida di implementazione di Microsoft Dynamics CRM 4.0

Microsoft Dynamics CRM 4.0 come una piattaforma di sviluppo applicazioni di Business

Blog del team di Microsoft Dynamics CRM

Microsoft Dynamics CRM 4.0 macchina virtuale

L'ottimizzazione e gestione di Microsoft Dynamics CRM 4.0

Chiave Takeaways

isolamento È importante Quando si progetta la soluzione, tenere presente approccio (come illustrato dalla verifica 4, 5 o 6) verrà lavoro migliore per l'utente e prestare quando e dove il codice personalizzato può eseguire.Si tratta inoltre notare quando non è necessario preoccuparsi di tali problemi a causa del tipo di estensioni che utilizza la soluzione.

virtualizzazione La virtualizzazione consente di ridurre la complessità nella generazione di un ambiente che riflette gli scenari chiave test di produzione.Di seguito è riportato alcune istruzioni sull'impostazione.Inserire CRM e SQL Server su server separati.Questo consente di verificare attendibilità per la delega e altri problemi correlati.Server CRM deve essere con carico bilanciato, che consentirà di identificare sessione, la memorizzazione nella cache e problemi tra server.Infine, inserire il controller di dominio e la posta elettronica su server separati, in questo modo nell'identificazione dei problemi di connettività.

aggiornare l'ambiente per ogni generazione Come regola generale, consigliabile una buona creare backup di ambienti virtuali o semplicemente dei database di Microsoft Dynamics CRM (dati e di configurazione possono essere ripristinati per ottenere il server indietro a uno stato vanilla".È quindi possibile eseguire una distribuzione completa pulitura in un ambiente aggiornato ogni volta, inclusi i dati personalizzati di codice, le personalizzazioni plug-ins e dominio.

test di ridondanza e prestazioni può essere completato separatamente Tranne per grandi organizzazioni, è in genere possibile affrontare failover e test tramite simulazioni isolati e non tramite generazione del mondo reale, stampe delle prestazioni.Ciò significa che non è necessario tentare di creazione di un ambiente di test che consenta di test di queste situazioni.In alternativa, è possibile fare affidamento sull'verificarne in produzione o in ambienti a utilizzo singolo separati.

In chiusura, Microsoft Dynamics CRM è un sistema a livello aziendale scalabile, che, quando correttamente configurato e distribuito, può gestire piccoli team, soluzioni a livello di organizzazione e tutte le opzioni di.Tentativo di determinare quale ambiente di ciclo di vita del prodotto è adatto dipenderà un'ampia gamma di fattori.

In genere, multi-tenancy non è un metodo ideale per risolvere i problemi di sviluppo prodotto del ciclo di vita delle soluzioni complesse e più viene utilizzato quando viene riconosciuta completamente.Soluzioni semplici che richiedono solo semplici o che dovrebbe essere bene utilizzare correttamente codificate isolate personalizzate estensioni e che non si basano su accesso specifiche del server o delle risorse disco seguendo il modello descritto in figura 4 .

Se la soluzione richiede più isolamento, le risorse specifiche del server oppure accesso (ad esempio un servizio esterno è consentito solo tramite le VLAN da un server specifico a un altro) e così via, È consigliabile passare con il modello illustrato nella Figura 6 .E sarebbe consigliabile evitare l'approccio illustrato nella figura 5 , come nel caso un attacco ibrido nel migliore dei casi.

In definitiva, Microsoft Dynamics CRM può essere distribuita in migliaia di configurazioni e che cos'è esattamente adatto dipenderà la soluzione richiede.Con un comprendere meglio di multi-tenancy, negli ambienti di sviluppo a server singolo, ambienti di test virtuale e quali scenari verificabili sono importanti, sarà possibile progettare un distribuzione di ciclo di vita del prodotto è funzionale e conveniente.

Aaron Elder (Microsoft Dynamics CRM MVP) funziona per Ascentium, una società di consulenza tecnologia e interattiva agenzia di marketing.Visitare il blog Ascentium inascentium.com/blog/CRM.