Condividi tramite

Procedure consigliate per lo sviluppo con Microsoft Dynamics 365

  • Articolo

 

Data di pubblicazione: gennaio 2017

Si applica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In questo argomento vengono illustrate le procedure consigliate per personalizzare Microsoft Dynamics 365 (online e locale).

Importante

Vedere Estensioni supportate per Microsoft Dynamics 365 per informazioni sulle tecniche di personalizzazione supportate e non supportate.

In questo argomento

Procedure consigliate per le prestazioni

Procedure consigliate per la personalizzazione

Procedure consigliate per la sicurezza

Procedure consigliate per l'estensibilità ISV

Procedure consigliate per le prestazioni

Le seguenti procedure consigliate consentono di scrivere il codice con migliori prestazioni.

Utilizzare thread multipli

Aggiungere il supporto di threading all'applicazione per suddividere il lavoro in più CPU. Questo suggerimento presuppone che si stia eseguendo il codice in un sistema multiprocessore.Ulteriori informazioni:Articolo sulla guida allo sviluppo avanzata di .NET Framework sul threading gestito.

Consentire al sistema di creare i GUID

Consentire al sistema di assegnare automaticamente il GUID (Id) invece di crearlo manualmente. Questo suggerimento consente a Microsoft Dynamics 365 di trarre vantaggio dai GUID sequenziali che offrono migliori prestazioni di SQL. Il seguente codice di esempio mostra come chiamare il metodo Create per ottenere un GUID assegnato al sistema.

// Instantiate an account object.Account account = new Account { Name = "Fourth Coffee" };
// Create an account record named Fourth Coffee and retrieve the GUID.accountId = serviceProxy.Create(account);

Utilizzare i tipi con associazione anticipata

Utilizzare la classe Entity quando il codice deve utilizzare le entità e gli attributi che non sono noti al momento in cui è scritto il codice. Inoltre, se il codice personalizzato viene utilizzato con migliaia di record di entità, l'utilizzo della classe Entity dà come risultato prestazioni leggermente migliori rispetto ai tipi di entità con associazione anticipata. Questa flessibilità, tuttavia, ha uno svantaggio poiché non è possibile verificare i nomi delle entità e degli attributi in fase di compilazione. Se le entità sono già definite al momento della codifica e una lieve degradazione delle prestazioni è accettabile, si consiglia di utilizzare i tipi con associazione anticipata che possono essere generati utilizzando lo strumento CrmSvcUtil.Ulteriori informazioni:Utilizzare le classi di entità con associazione anticipata nel codice

Disabilitare plug-in

Se possibile, disabilitare i plug-in registrati prima di eseguire l'applicazione.

Scrivere i plug-in che vengono eseguiti più rapidamente

Scrivere sempre un plug-in che impiega meno tempo ad eseguire l'attività desiderata. Ad esempio, il metodo Execute viene elaborato frequentemente in Microsoft Dynamics 365. Se si registra un plug-in in tale messaggio, il plug-in può avere un impatto significativo sulle prestazioni nel sistema perché viene eseguito ogni volta che il metodo Execute viene elaborato e ciò si verifica frequentemente.

Se si intende registrare i plug-in per l'esecuzione sincrona, si consiglia di progettarli in modo da completare l'operazione in meno di 10 secondi. Si consiglia di ridurre i tempi di elaborazione nei plug-in per gestire l'interattività delle applicazioni client che sono connesse allo stesso servizio dell'organizzazione che esegue il plug-in.

Limitare i dati richiamati

Quando si utilizzano i metodi che recuperano i dati dal server, richiamare la quantità minima di dati necessaria per l'applicazione. Questa operazione viene eseguita specificando il set di colonne, ovvero il set di attributi di entità da richiamare.

Ad esempio, raramente è una buona idea richiamare tutti i metadati con il messaggio RetrieveAllEntitiesRequest, specificando il filtro dell'entità EntityFilters.All per la proprietà EntityFilters. In alternativa, puoi ottenere migliori prestazioni se si limita il filtro dell'entità, oppure se si utilizza uno dei seguenti messaggi: RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest, RetrieveRelationshipRequest o RetrieveMetadataChangesRequest. Il messaggio RetrieveMetadataChanges consente la creazione di una query per restituire solo i metadati necessari o i metadati modificati.Ulteriori informazioni:Recuperare e rilevare le modifiche apportate ai metadati.

Limitare il numero di entità abilitata per l'utilizzo offline

Valutare attentamente se un'entità deve essere disponibile agli utenti quando lavorano in modalità offline. Ogni entità abilitata per la funzionalità offline influisce direttamente sul tempo necessario agli utenti per sincronizzare i dati quando tornano online. Questo aspetto è particolarmente significativo per utenti con computer meno potenti.

Limitare le operazioni che vengono eseguite a catena sulle entità correlate

Quando si utilizza il metodo Update o il messaggio UpdateRequest, non impostare l'attributo OwnerId in un record a meno che il proprietario non sia effettivamente cambiato. Quando si imposta questo attributo, le modifiche spesso vengono eseguite a catena sulle entità correlate e ciò aumenta il tempo necessario per l'operazione di aggiornamento.Ulteriori informazioni:Comportamento a catena

Modificare le impostazioni proxy nel client (solo locale)

Un server proxy si trova tra un'applicazione client, ad esempio un browser Web e l'effettivo server di destinazione. Quando un computer si trova in una LAN, può utilizzare un server proxy per la connessione a Internet. In questo caso, il server proxy è combinato con, o fa parte del server gateway e del server firewall. Il proxy può memorizzare nella cache le richieste Web e servire più richieste del client utilizzandone i dati memorizzati nella cache. Se i dati richiesti non sono presenti nella cache del server proxy, questo inoltra la richiesta al server effettivo utilizzando il proprio indirizzo IP. Qui il server proxy agisce per conto del computer client.

Sebbene un server proxy possa agire come server della cache e possa consentire un caricamento più rapido della pagina web, a volte può diminuire le prestazioni se non è utilizzato in modo corretto. Frequentemente, gli utenti evitano configurazioni manuali del proxy e utilizzano la configurazione automatica. Questo collegamento aiuta nel bilanciamento del carico dei server proxy, ma a seconda della complessità dello script di configurazione, è possibile che si verifichi un ritardo significativo quando si utilizza la configurazione automatica del proxy.

Quando il server Microsoft Dynamics 365 è installato, è possibile ignorare il server proxy per ottenere maggiore velocità. Il server offre un indirizzo Web locale che non richiede di raggiungere alcun proxy. È possibile selezionare Ignora server proxy per gli indirizzi locali e immettere il nome dominio completo del server Microsoft Dynamics 365 nell'elenco delle eccezioni. Ciò consente una migliore velocità effettiva quando vengono creati i record utilizzando Microsoft Dynamics 365 SDK.

Ottimizzare le prestazioni di allocazione del canale di servizio

È possibile stabilire una connessione ai servizi Web Microsoft Dynamics 365 e autenticare gli utenti tramite le classi proxy del servizio OrganizationServiceProxy e DiscoveryServiceProxy. Tuttavia, un utilizzo improprio di queste classi proxy del servizio può talvolta ridurre le prestazioni dell'applicazione. Pertanto, se si comprende quando e come utilizzare le diverse classi client disponibili in SDK, è possibile ottenere migliori prestazioni dell'applicazione.

Quando si stabilisce un canale di servizio Windows Communication Foundation (WCF) utilizzando un endpoint di servizio, ad esempio, utilizzando il servizio Web dell'organizzazione, l'applicazione deve eseguire due operazioni che richiedono molto tempo: il download dei metadati dall'endpoint e l'autenticazione utente. È possibile migliorare le prestazioni se l'applicazione esegue queste operazioni un numero minimo di volte per ogni sessione dell'applicazione. Il costruttore OrganizationServiceProxy di seguito indicato esegue entrambe queste operazioni ogni volta che viene creato un oggetto proxy di servizio.

OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)

In genere si ottengono migliori prestazioni ottimali se l'applicazione utilizza questo costruttore per creare un'istanza del proxy di servizio tramite questo costruttore una volta durante la sessione dell'applicazione e memorizzare nella cache il riferimento restituito per l'utilizzo in percorsi diversi di codice nell'applicazione. Si noti che il riferimento del servizio restituito non è thread-safe, quindi le applicazioni a thread multipli dovranno allocare un'istanza per ogni thread. Le applicazioni devono inoltre chiamare Dispose nell'oggetto proxy di servizio prima di essere chiuse per liberare le risorse allocate del canale servizio.

La classe proxy di servizio esegue il download dei metadati e l'autenticazione utente utilizzando i seguenti metodi della classe.

IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)

Il metodo CreateManagement<TService> esegue il download dei metadati mentre il metodo Authenticate autentica l'utente. Gli oggetti restituiti da questi metodi sono thread-safe e possono essere staticamente memorizzati nella cache dall'applicazione. È quindi possibile utilizzare questi oggetti per costruire un oggetto proxy di servizio che utilizza uno degli altri costruttori disponibili.

OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)

Memorizzando nella cache gli oggetti di gestione del servizio e delle credenziali autenticate, l'applicazione può costruire in modo più efficiente gli oggetti proxy di servizio più volte per ogni sessione dell'applicazione. Se si abilitano i tipi con associazione anticipata su OrganizationServiceProxy tramite uno dei metodi EnableProxyTypes, è necessario eseguire la stessa operazione in tutti i proxy di servizio creati dall'oggetto IServiceManagement<TService> memorizzato nella cache. Se nell'applicazione vengono utilizzati i metadati, è consigliabile che memorizzi nella cache i metadati che recupera e che chiami periodicamente il messaggio RetrieveTimestampRequest per determinare se è necessario aggiornare la cache.

Inoltre, monitorare il token di sicurezza di WCF (Token) e aggiornarlo prima che scada in modo da non perdere il token e dover iniziare di nuovo l'autenticazione. Per controllare il token, creare una classe personalizzata che eredita dalla classe DiscoveryServiceProxy o OrganizationServiceProxy e che implementa le regole business per controllare il token, oppure racchiudere le classi del proxy in una nuova classe. Un'altra tecnica è di controllare esplicitamente il token prima di ogni chiamata al servizio Web. Il codice di esempio che dimostra queste tecniche può essere trovato nelle classi ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy e AutoRefreshSecurityToken nell'argomento Codice dell'helper: classe di ServerConnection.

Procedure consigliate per la personalizzazione

Le seguenti procedure consigliate consentono di personalizzare ed estendere Microsoft Dynamics 365.

Procedure consigliate per Microsoft Dynamics 365 (online)

Il download del white paper Principi e modelli per generatori di soluzioni di Microsoft Dynamics CRM Online offre indicazioni specifiche per la creazione di soluzioni con Microsoft Dynamics 365 (online).

Utilizzo di entità e attributi personalizzati

Utilizzare sempre il nome dello schema di entità per fare riferimento a un'entità personalizzata nel codice e nelle query. Non utilizzare il codice tipo di oggetto (denominato anche tipo di entità) perché il relativo valore intero varia nei casi di entità personalizzate in diverse organizzazioni.

Risparmiare spazio nel server utilizzando queste tecniche:

  • Creare gli attributi personalizzati per le entità esistenti invece di creare una nuova entità.

  • Rinominare le entità esistenti per rendere le entità più significative.

Quando è consigliabile personalizzare un'entità?

Personalizzare un'entità di sistema, ad esempio l'entità opportunità, invece di sostituirla con una nuova entità personalizzata in modo da poter utilizzare le molte funzionalità predefinite in un'entità esistente. Ad esempio, le entità opportunità e caso hanno campi di ricerca per associare i clienti. I clienti possono essere account o contatti. Non è possibile creare un'entità personalizzata con lo stesso tipo di ricerca. È possibile modificare il nome visualizzato di un'entità di sistema per renderlo più significativo per l'azienda.

Quando è necessario utilizzare i plug-in invece del flusso di lavoro?

Gli sviluppatori interessati a estendere o personalizzare Microsoft Dynamics 365 possono scegliere diversi metodi per eseguire le attività. Oltre all'aggiunta del codice JavaScript sul lato client a un modulo o all'aggiunta delle pagine ASP.NET personalizzate, possono scrivere un plug-in o creare un flusso di lavoro personalizzato tramite l'interfaccia Web che chiama un'attività del flusso di lavoro personalizzata. Come decidere quando utilizzare un plug-in e quando utilizzare un flusso di lavoro? La tecnologia utilizzata dipende dall'attività da eseguire e da chi creerà la personalizzazione.

Ad esempio, è necessario utilizzare un flusso di lavoro in tempo reale del plug-in sincrono se si desidera eseguire il codice personalizzato immediatamente prima o dopo l'esecuzione dell'operazione principale della piattaforma e prima che il risultato dell'operazione venga restituito dalla piattaforma. Non è possibile utilizzare un flusso di lavoro asincrono o un plug-in asincrono in questa situazione poiché sono messi in coda per essere eseguiti al termine dell'esecuzione dell'operazione principale. Di conseguenza, non è possibile stimare quando verranno eseguiti. Se si desidera aggiungere la funzionalità personalizzata a Microsoft Dynamics 365 (online), i flussi di lavoro e i plug-in sono supportati, ma le attività del flusso di lavoro personalizzate non lo sono.

Valuta queste tecnologie e seleziona quella che meglio si adatta agli obiettivi aziendali dopo aver preso in considerazione i problemi di distribuzione, prestazione e manutenzione della soluzione del plug-in o del flusso di lavoro.

Nella tabella seguente vengono riepilogate le caratteristiche dei plug-in e dei flussi di lavoro.

Criteri

Plug-in

Flusso di lavoro

Esecuzione prima o dopo l'operazione di piattaforma principale (creazione, aggiornamento, eliminazione e così via)

Viene eseguito immediatamente prima o dopo l'operazione principale (sincrona).

Può essere inoltre eseguito in coda dopo l'operazione principale (asincrono).

I flussi di lavoro asincroni sono eseguiti in coda dopo l'operazione principale.

I flussi di lavoro in tempo reale hanno caratteristiche simili ai plug-in.

Impatto delle prestazioni sul server

I plug-in sincroni possono aumentare il tempo di risposta della piattaforma poiché sono parte dell'elaborazione principale della piattaforma.

I plug-in asincroni hanno un minore impatto sul tempo di risposta del server poiché il codice viene eseguito in un processo diverso.

I flussi di lavoro asincroni hanno un minore impatto sul tempo di risposta del server poiché il codice viene eseguito in un processo diverso.

I flussi di lavoro in tempo reale hanno caratteristiche di prestazioni simili ai plug-in in modalità sandbox.

Restrizioni di sicurezza

Per registrare un plug-in con la piattaforma è necessario un ruolo di sicurezza di amministratore di sistema o di addetto alla personalizzazione di sistema e l'appartenenza al gruppo Amministratore distribuzione.

Gli utenti possono creare in modo interattivo i flussi di lavoro nell'applicazione Web.

Tuttavia, per registrare un'attività flusso di lavoro personalizzata, l'utente che esegue la distribuzione deve avere gli stessi ruoli di sicurezza di quelli necessari per la registrazione di plug-in.

Supporto (SKU) della versione Microsoft Dynamics 365

Supportato in Microsoft Dynamics 365 (online) una volta registrato nel sandbox. Può essere supportato in installazioni ospitate da un partner a sua discrezione.

I flussi di lavoro sono supportati da tutte le distribuzioni di Dynamics 365. Le attività del flusso di lavoro personalizzate sono supportate nel sandbox di Microsoft Dynamics 365 (online) e all'interno o all'esterno del sandbox per le distribuzioni IFD/locali.

Lunghezza dei tempi di elaborazione

Un plug-in registrato per l'esecuzione sincrona o asincrona deve completare l'esecuzione in un limite di tempo di due minuti.

Funziona bene sia per processi brevi che lunghi. Tuttavia, tutti gli impegni in un flusso di lavoro non possono impiegare più di due minuti per essere completati.

Funziona quando il client Dynamics 365 per Outlook è offline

È supportato sia online che offline.

I flussi di lavoro non vengono eseguiti in modalità offline.

Persistenza di dati e di processo

I plug-in vengono eseguiti fino a che non vengono completati. I plug-in devono essere scritti per essere senza stato quando non viene salvato in modo permanente alcun dato in memoria.

I flussi di lavoro asincroni possono essere sospesi, posticipati, annullati e ripristinati tramite le chiamate SDK o dall'utente tramite l'applicazione Web. Lo stato del flusso di lavoro viene automaticamente salvato prima di essere sospeso o posticipato.

I flussi di lavoro in tempo reale non possono avere stati di attesa. Devono essere eseguiti fino al completamento come i plug-in.

Rappresentazione

I plug-in possono eseguire le operazioni sui dati per conto di un altro utente di sistema.

I flussi di lavoro asincroni non possono utilizzare la rappresentazione, contrariamente ai flussi di lavoro in tempo reale. I flussi di lavoro in tempo reale possono eseguire come proprietario del flusso di lavoro o come utente chiamante.

Creazione

I Software engineer o i programmatori possono creare i plug-in.

Qualsiasi utente, incluso un utente finale, un business analyst o un amministratore può creare flussi di lavoro se dispongono delle autorizzazioni appropriate.

Non esiste alcun impatto significativo sulle prestazioni sul server tra un plug-in asincrono e un flusso di lavoro.

Quale tipo di flusso di lavoro è migliore?

Da una prospettiva delle prestazioni, è meglio creare un flusso di lavoro singolo o è meglio avere più flussi di lavoro figlio e chiamarli in un flusso di lavoro padre? L'approccio del flusso di lavoro figlio raggiunge una velocità effettiva più bassa, ma è più gestibile se si modifica spesso la definizione del flusso di lavoro. Il sovraccarico della compilazione non costituisce una problematica importante in quanto il flusso di lavoro viene compilato solo durante la pubblicazione. Tuttavia, Microsoft Dynamics 365 incorre nel sovraccarico quando avvia ogni istanza del flusso di lavoro. Il sovraccarico si verifica quando tutte le entità utilizzate nel flusso di lavoro vengono recuperate e il flusso di lavoro figlio è avviato in un processo a due fasi che include "Attività di espansione del flusso di lavoro" e l'istanza del flusso di lavoro effettiva. Pertanto, per aumentare la velocità, utilizzare un flusso di lavoro singolo.

Come va contrassegnata l'attività del flusso di lavoro personalizzata quando è completata?

Il valore restituito dal metodo Execute è utilizzato per dal runtime del flusso di lavoro per contrassegnare l'impegno come "completata". Usa return base.Execute(executionContext) a meno che l'impegno ignori la funzionalità delle classi di base. Evitare di restituire ActivityExecutionStatus.Closed.Ulteriori informazioni:Enumerazione ActivityExecutionStatus

Come si consiglia di segnalare le eccezioni nelle attività del flusso di lavoro personalizzate?

È necessario generare un'eccezione InvalidPlugInExecutionException nel codice. Questo errore verrà visualizzato nel modulo dell'istanza del flusso di lavoro.

È possibile definire le entità personalizzate specifiche delle business unit?

Le entità personalizzate hanno privilegi per ogni ruolo di sicurezza ma non per ogni business unit. Per definire le entità personalizzate visibili solo alle business unit specificate, è necessario creare diversi ruoli di sicurezza per ogni business unit e garantire i privilegi all'entità personalizzata nel ruolo appropriato.

Procedure consigliate per la sicurezza

Attenersi alle linee guida per consentire la protezione dei dati aziendali.

Generale

Le procedure consigliate per proteggere l'implementazione di Microsoft Dynamics 365 includono quanto segue:

  • Stabilire un piano dati di sicurezza approvato per l'implementazione Microsoft Dynamics 365 dell'organizzazione.

  • Assegnare i privilegi minimi necessari quando si installa il pool di applicazioni.

  • Richiedere agli utenti di utilizzare password complesse per i propri account. Per ulteriori informazioni, cercare "password complesse" nella guida di Windows.

Ulteriori informazioni:TechNet: Considerazioni sulla sicurezza per Microsoft Dynamics CRM

Ruoli, privilegi e i diritti di accesso

Le procedure consigliate per l'utilizzo del modello di sicurezza Microsoft Dynamics 365 includono quanto segue:

  • Limitare rigorosamente il numero di utenti assegnati al ruolo di amministratore di sistema. Non eliminare mai questo ruolo.

  • Creare i ruoli in base alle procedure consigliate di sicurezza dei privilegi minimi, consentendo l'accesso alla quantità minima di dati aziendali richiesti per l'attività. Assegnare agli utenti il ruolo appropriato per il proprio processo.

  • Creare un nuovo ruolo con questi privilegi specifici e aggiungere l'utente al nuovo ruolo se un utente ha bisogno di altri livelli o diritti di accesso. I diritti di un utente sono l'unione di tutti i ruoli a cui è stato assegnato. Non concedere i privilegi del ruolo originali necessari solo per uno o più membri.

  • Utilizzare la condivisione, se appropriato, per dare diritti specifici a utenti specifici su singoli oggetti, invece di ampi privilegi su tutti gli oggetti di un determinato tipo.

  • Utilizzare i team per creare gruppi interfunzionali in modo che gli oggetti specifici possano essere condivisi con il team.

  • Formare gli utenti con diritti di accesso di condivisione affinché condividano le minime informazioni necessarie.

Evitare l'elevazione dei privilegi

Gli attacchi all'elevazione di privilegi si verificano quando un utente può assumere i privilegi di un account attendibile, ad esempio un proprietario o un amministratore. Eseguire sempre con account utente con privilegi minimi e assegnare solo le autorizzazioni necessarie. Evitare di utilizzare account amministrativi o di proprietario per eseguire il codice. In questo modo viene limitata la quantità di danni che possono verificarsi se un attacco ha esito positivo. Quando si eseguono le attività che richiedono ulteriori autorizzazioni, utilizzare la firma di procedura o l'autorizzazione solo per la durata dell'attività.

Sviluppo lato server

Le procedure consigliate per lo sviluppo del codice sul lato server per Microsoft Dynamics 365 includono quanto segue:

  • Non modificare il database Microsoft Dynamics 365 con qualsiasi mezzo diverso dall'utilizzo di SDK perché in questo modo viene ignorato il modello di sicurezza di Microsoft Dynamics 365.

  • I plug-in sono in esecuzione nel contesto di un responsabile: è necessario sapere che questo codice potrebbe accedere alle informazioni a cui l'utente connesso non ha accesso.

  • Per gli assembly del flusso di lavoro e i plug-in, evitare di scrivere il codice che impiega molto tempo per l'esecuzione. È importante che il codice del plug-in registrato per essere eseguito in modo sincrono venga restituito nel più breve tempo possibile.

  • Se si stanno replicando i dati di Microsoft Dynamics 365 nel proprio archivio dati, l'utente è responsabile della sicurezza dei dati. Se si utilizza un plug-in per trasmettere i dati, assicurarsi di registrare l'esecuzione del plug-in dopo l'operazione di piattaforma principale. I controlli dei privilegi di sicurezza per l'utente connesso si verificano durante l'operazione principale di piattaforma.

  • I dati che derivano da Microsoft Dynamics 365 potrebbero non essere sicuri per il rendering. Nei dati possono essere inseriti tag HTML che non sono sicuri.

  • Soddisfare i requisiti di non accesso ai database di Microsoft Dynamics 365 direttamente tramite SQL Server Enterprise Manager. Se si ignora SDK è possibile che si venga esposti a minacce intrusive al codice SQL.

  • Per le e distribuzioni con connessione Internet, ricordare che la soluzione è sicura solo quanto il collegamento più debole. Dopo che l'applicazione viene esposta a Internet, è aperta a minacce alla sicurezza.

  • Utilizzare solo le lingue che producono il codice gestito per la maggiore sicurezza dai sovraccarichi di buffer, eccezioni e così via.

Per ulteriori informazioni sulla sicurezza, vedere i seguenti argomenti:

Sviluppo lato client

Le procedure consigliate per lo sviluppo delle personalizzazioni per l'applicazione Web di Dynamics 365 e Microsoft Dynamics 365 per Outlook includono quanto segue:

  • Utilizzare le risorse Web invece delle pagine che richiedono l'elaborazione lato server ove possibile. Se i requisiti possono essere soddisfatti solo tramite l'utilizzo dell'elaborazione lato server, rispettare il requisito secondo cui le pagine Web personalizzate devono essere installate in un sito Web diverso daMicrosoft Dynamics 365. Impostare il livello di attendibilità per il sito in modo appropriato, in base al livello di riservatezza nella sicurezza del codice. In questo modo vengono ridotte sia le minacce dallo scripting intersito che altre minacce.

  • Per maggiore sicurezza, verificare che il sito Web separato venga eseguito in un account diverso da Microsoft Dynamics 365. Questo account deve avere il minimo accesso possibile e non deve avere accesso diretto ai database di Microsoft. È possibile utilizzare, solo nell'applicazione, una password complessa che non scade se non viene eseguito l'accesso a questo account.

  • Evitare di utilizzare i controlli ActiveX poiché sono soggetti a problemi di sicurezza noti.

  • Tenere presente le limitazioni dello script client.Ulteriori informazioni:Creare il codice per moduli di Microsoft Dynamics 365

  • Utilizzare i plug-in per applicare le regole business indipendentemente da come vengono eseguite le modifiche ai dati.

  • Utilizza sempre una finestra di dialogo di conferma quando elimini i record o applichi modifiche riservate, ad esempio quando aggiungi un nuovo utente a un ruolo di sicurezza. Puoi utilizzare confirmDialog per visualizzare una finestra di dialogo. Ciò consente di impedire le tecniche come il click-jacking o il reindirizzamento dell'interfaccia utente con le quali uno sviluppatore sospetto può incorporare la propria pagina in un'altra apparentemente innocua per far eseguire all'utente azioni che potrebbero compromettere la sicurezza o per far eseguire azioni indesiderate sui dati.

Le procedure consigliate di sicurezza per il sito Web includono quanto segue:

  • Non utilizzare l'accesso anonimo.

  • Utilizzare l'autenticazione Windows integrata, NTLM o l'autenticazione di base in Transport Layer Security (TLS) o Secure Sockets Layer (SSL).

  • Usa TLS/SSL per evitare l'invio di dati non crittografati in rete se il sito Web si trova in un computer diverso da Microsoft Dynamics 365.

Per ulteriori informazioni, vedere gli articoli seguenti:

Procedure consigliate per l'estensibilità ISV

Uno dei principi chiave dell'estendibilità ISV è che l'utente non dovrebbe presumere che la soluzione ISV è l'unica ad essere installata. Viene di seguito riportato un elenco delle procedure consigliate da seguire.

Procedure consigliate per l'utilizzo dei servizi Web di Microsoft Dynamics 365

Inserire l'URL del servizio Web di Microsoft Dynamics 365 in un file di configurazione, ad esempio, in un file app.config, in modo che il codice sia isolato dalle modifiche apportate all'URL. Ad esempio, ci sono diversi URL per i tre data center di Microsoft Dynamics 365 (online) in tutto il mondo.

Dove vanno inseriti i plug-in e le attività personalizzate del flusso di lavoro?

Per i plug-in su disco o per le attività del flusso di lavoro personalizzate, posizionare gli assembly nella cartella <installdir>\Server\bin\assembly.

Dove vanno inserite le applicazioni Web o le pagine Web personalizzate?

Fare riferimento all'argomento Implementare Single Sign-On da una pagina Web ASPX o IFRAME.

Come va eseguito un plug-in quando la visualizzazione della griglia dell'applicazione Web viene aggiornata?

Registrare il plug-in nella richiesta di messaggio RetrieveMultipleRequest e non specificare alcun tipo di entità durante la registrazione.

Quando è necessario creare un nuovo sito Web?

Creare un nuovo sito Web per il codice quando si verifica una delle seguenti condizioni:

  • L'applicazione deve essere associata a un dominio, un protocollo o una porta diversa dall'applicazione Microsoft Dynamics 365; o deve essere eseguita in un pool di applicazioni diverso.

  • L'applicazione può esistere ed è possibile accedervi in modo autonomo. Ad esempio, un portale che interagisce con Microsoft Dynamics 365 come server (tramite i servizi Web) deve essere ospitato come nuovo sito Web.

  • Nell'applicazione si utilizza sempre Active Directory o l'autenticazione Windows integrata (non IFD) e lo scripting tra domini non è un problema. Ad esempio, l'applicazione interagisce con un back-end utilizzando i servizi Web e interagisce con i moduli Microsoft Dynamics 365. Una pagina ospitata in un IFRAME caricato nell'applicazione Microsoft Dynamics 365 che non interagisce con il modulo Microsoft Dynamics 365 rientra in questa categoria.

Vedere anche

Estendere Microsoft Dynamics 365 nel server
Impostare flag bit
Creare il codice per moduli di Microsoft Dynamics 365
Scrivere plug-in per estendere i processi aziendali
Attività personalizzate del flusso di lavoro (assembly del flusso di lavoro)

Microsoft Dynamics 365

© 2017 Microsoft. Tutti i diritti sono riservati. Copyright