Views in Dynamics zijn gebaseerd op de definitie van een filter. Via een filter wordt in feite een query gedefinieerd. Bij de definitie van een filter zijn de mogelijkheden echter beperkt. In dit blog leg ik een aanpak uit waarmee het mogelijk is om meer complexe view filters te maken. Hierbij wordt gebruik gemaakt van een pre-operation RetrieveMultiple plugin, die de view filter query aanpast voordat deze in Dynamics wordt uitgevoerd. Op die manier kunnen veel complexere views worden gemaakt dan normaal mogelijk is.
De case
In dit voorbeeld maken we een dynamische view, waarmee je een lijst rapporten kunt zien van de laatste 30 dagen, maar die alleen rapporten mag tonen die gaan over onderwerpen waar jij interesse in hebt.
Een rapport kan zijn gelinkt aan 0 of meer tags (N:N relatie), waarmee voor een rapport kan worden aangegeven over welke onderwerpen dit gaat.
Je kunt aan je eigen interesses ook tags toevoegen, om aan te geven in welke onderwerpen je geïnteresseerd bent (N:N relatie).
De aanpak
Zoals gezegd is een view in Dynamics niets anders dan een query. Wanneer je als Dynamics gebruiker een view gebruikt om bepaalde records te bekijken, vindt in Dynamics onder water een RetrieveMultiple aanroep plaats waarbij de filter query wordt meegegeven, wordt uitgevoerd en de gevonden records worden geretourneerd en getoond.
De wijze waarop we de view logica dynamisch gaan maken bestaat uit de volgende stappen:
- Het definiëren van de view filter, met daarin een bepaalde specifieke conditie
- Het bouwen van een RetrieveMultiple plugin, die de view filter uit stap 1 herkent en deze aanpast
- Het toevoegen van de plugin step, zodat de plugin ook wordt gebruikt
Stap 1: definitie van de view filter
In deze stap definiëren we de view filter (als System View, zodat deze voor alle gebruikers beschikbaar is). We nemen een dummy conditie op [Name Equals CallReportsOfInterestToCurrentUser] om de filter query herkenbaar te maken aan onze te bouwen plugin.
Stap 2: bouwen van de plugin
In deze stap maken we als eerste de plugin code:
De class QueryModifierFactory bepaalt de te gebruiken modifier class, die de originele query zal aanpassen via de aanroep modifier.ModifyQuery(query).
Als laatste stap overschrijven we de oorspronkelijke query input parameter met de (eventueel aangepaste) nieuwe query.
De QueryModifierFactory GetModifier methode is betrekkelijk eenvoudig.
We kijken of de originele query een fetch query is en zo ja, gebruiken de query XML om te zoeken naar de tekst CallReportsOfInterestToCurrentUser (de dummy conditie uit stap 1). Als deze tekst wordt gevonden, wordt een CallReportQueryModifier geretourneerd die de query kan omschrijven. Anders wordt een NoModificationQueryModifier geretourneerd, welke de originele query niet aanpast:
Laten we nu kijken naar de CallReportQueryModifier class, waarin de query wordt aangepast:
Zoals je kunt zien wordt de dummy conditie, die we in stap 1 alleen hadden toegevoegd om de view query herkenbaar te maken voor onze plugin code, eerst verwijderd. Vervolgens worden de interesse tags van de huidige ingelogde gebruiker opgehaald en worden deze tags toegevoegd aan de query. Voor het aanpassen van de oorspronkelijke query XML word LINQ-to-XML gebruikt.
De plugin DLL moeten we vervolgens uploaden in onze Dynamics omgeving.
Stap 3: toevoegen van de plugin step
Als laatste moeten we een plugin step toevoegen voor de message retrieveMultiple, op de dp_callreport entiteit, tijdens de pre-operation stage, want dan kan de query nog worden aangepast.
Voilà
En voilà, na deze laatste stap wordt onze in stap 1 gemaakte view nu dynamisch aangepast door plugin code en uitgebreid met de interesse gebieden van de ingelogde gebruiker. Op deze manier kunnen dynamische views worden gemaakt in Dynamics.