Introduction to Plug-ins / Extending Microsoft Power Platform Microsoft Dataverse Flashcards
Introduction to Plug-ins
Quando utilizzare i Plug- ins?
Un plug-in è una logica imperativa che deve essere utilizzata solo quando un processo dichiarativo, come una Business Rule, un flow o un workflow, non soddisfa i requisiti.
- Fondamentalmente, un plug-in è semplicemente un assembly .NET che implementa un’interfaccia IPlugin, disponibile nel pacchetto Microsoft.CrmSdk.CoreAssemblies NuGet.
- L’interfaccia IPlugin espone un singolo metodo, Execute, che consente di inserire qualsiasi logica personalizzata che si desidera richiamare in base a qualsiasi evento si sta gestendo.
- Gli scenari comuni di quando utilizzare i plug-in sono:
- Annullamento dell’evento
- Visualizzazione di un errore per l’utente.
- Apportare modifiche ai dati nell’operazione
- Avvio di altre azioni utilizzando l’Organization Service per aggiungere l’automazione.
Introduction to Plug-ins
Alternative al Plug-ins?
Alternatives to plug-ins
I plug-in dovrebbero essere considerati l’ultima risorsa in molti casi.
- Sebbene i plug-in siano potenti e, se ben scritti, altamente performanti, è importante ridurre al minimo la quantità di personalizzazioni
- I plug-in offrono prestazioni migliori se si considerano le loro prestazioni, capacità e capacità di essere eseguiti in modo sincrono.
- Se è richiesta la logica sincrona per la tua applicazione, i plug-in potrebbero essere un’opzione richiesta per te
Le alternative comuni ai plug-in sono:
- Workflows
- Power Automate
- Calculated and Rollup Fields
- Custom Actions
Plug-ins usage scenarios
Quando usare il codice in una Model - Driven e cosa tenere in considerazione?
È consigliabile affrontare la personalizzazione di una Model - Driven con l’idea che la scrittura del codice sia l’ultima spiaggia per la funzionalità dell’applicazione aziendale desiderata.
Aree di qualità come
- maintainability( Mantenibilità)
- upgradability,(Aggiornamenti)
- stability(Stabilità)
- and performance
dovrebbero essere prese in considerazione quando si determina l’approccio migliore per un determinato scenario.
Plug-ins usage scenarios
Business rules vs. plug-ins quando scegliere il plugin?
Business rules vs. plug-ins
A volte, le Business rules non sono in grado di raggiungere determinati obiettivi, o forse la loro complessità fa sì che gli sviluppatori preferiscano scrivere la logica in un plug-in. Uno scenario potrebbe essere se hai un “if/then/else” complesso situazione che sarebbe più facile ottenere in un’istruzione switch o quando si ha a che fare con valori dinamici che non sono facilmente accessibili tramite una regola aziendale. Anche lo scripting del client è un’opzione per questo scenario.
Plug-ins usage scenarios
Workflows/flows vs. plug-ins/client script quando utilizzarli?
Workflows/flows vs. plug-ins/client script
Potrebbero verificarsi circostanze in cui le limitazioni esistenti richiedono lo sviluppo di plug-in per svolgere determinate attività.
La tabella seguente può aiutare a determinare quando potrebbe essere più appropriato utilizzare un workflow vs a plug-in or Client Script.
Custom workflow extensions
Cosa sono le CWA?
Custom workflow extensions
Le Custom workflow extensions sono un derivato dei plug-in che consentono agli sviluppatori di scrivere attività personalizzate che non sono disponibili all’interno delle process activities che si trovano all’interno del workflow designer.
Come con i plug-in, uno scenario comune in cui gli Dataverse workflow assemblies potrebbero essere più appropriati è se la logica aziendale che stai creando deve essere eseguita in modo sincrono. Attualmente, se hai bisogno della logica sincrona da eseguire all’interno del tuo ambiente Dataverse, devi configurare un workflow su richiesta o un plug-in sincrono per soddisfare questo requisito.
Custom workflow extensions
Come vengono usate le CWA assembly?
Custom workflow extension assemblies
Invece di implementare l’interfaccia IPlugin come avviene con i plug-in, le CWA ereditano una classe CodeActivity.
Questa classe espone un metodo Execute che fornisce un parametro CodeActivityContext.
Input and output arguments
Le CWA consentono di definire parametri che possono essere passati in input e in output dall’CWA utilizzando gli oggetti InArgument e OutArgument insieme alla decorazione di questi oggetti con attributi di input e output.
Le CWA espongono anche i seguenti attributi .NET che possono essere usati dai parametri di input e output.
- [Default(“DefaultValue”)] : Utilizzato per specificare i valori predefiniti per un argomento di input o output quando uno non è già stato impostato.
- [ReferenceTarget(“entityname”)] : Obbligatorio quando si definisce una proprietà per un parametro EntityReference.
- [AttributeTarget(“entityname”,”optionsetname”) : Utilizzato dai parametri OptionSetValue, definisce quale entità e attributo contiene l’insieme di valori valido per il parametro
Plug-in execution context
Quali sono i context dei plugin e delle CWA e cosa contengono?
Plug-in execution context
Ogni volta che viene eseguito un plug-in (o una CWA), Microsoft Dataverse mette a disposizione una grande quantità di dati che contengono informazioni sul contesto in cui risiede l’operazione corrente.
- CWA hanno accesso a una classe IWorkflowContext. è accessibile tramite il parametro CodeActivityContext. chiamando il metodo GetGetExtension();
- Nei plug-in, IPluginExecutionContext è accessibile tramite il parametro IServiceProvider del metodo Execute chiamando il metodo GetService().
Sia IPluginExecutionContext che IWorkflowContext implementano l’interfaccia IExecutionContext. Ciascuno espone anche informazioni specifiche per il proprio tipo.
- Due delle proprietà più importanti dell’interfaccia IExecutionContext sono
- InputParameters
- OutputParameters
- Altre proprietà usate di frequente sono
- PreEntityImages
- PostEntityImages
- SharedVariables.
Plug-in execution context
Parametri di input del plugin?
InputParameters
I parametri di input sono contenuti nella raccolta execution context’s InputParameters collection e sono di tipo Entity. Questa proprietà consente di vedere quali valori di entità sono stati passati al plug-in prima dell’implementazione di una determinata operazione.
Plug-in execution context
Quando utilizzare gli OutputParameters e quando sono disponibili?
OutputParameters
I parametri di output sono contenuti execution context’s OutputParameters collection e sono del tipo Entity.
- I parametri di output vengono forniti solo dopo che si è verificata l’operazione specificata. Pertanto, sarai in grado di utilizzare questa raccolta solo quando gestisci gli eventi nella fase PostOperation.
Plug-in execution context
Quando utilizzare una pre image e una post image?
PreEntityImages and PostEntityImages
Quando si registrano i plug-in da eseguire sul framework degli eventi, è possibile fornire una copia immutabile, o snapshot, dei dati.
- Questo è l’ideale, specialmente quando è necessario fare riferimento ai valori dei dati prima o dopo che si è verificata un’operazione,
- ad esempio per scopi di registrazione o controllo personalizzato.
- Sebbene sia possibile recuperare i valori delle entità utilizzando l’organization context all’interno di un plug-in tramite una richiesta di retrive, l’utilizzo di immagini di entità per eseguire questa attività è molto più efficiente e altamente consigliato.
Plug-in execution context
Cosa sono le Shared Value nell’ execution content?
SharedVariables
Le variabili condivise consentono di configurare i dati che possono essere passati da un plug-in a un altro step che si verifica successivamente nella pipeline di implementazione.
- Sebbene raccomandiamo vivamente di configurare i plug-in in modo che siano senza stato e non abbiano dipendenze da eventi esterni, a volte ci sono eccezioni a questa regola.
