Microsoft Dynamics CRM 2011 | Kalender per SDK abfragen

AZ_2406_WorkingHoursNach wie vor beschäftige ich mich mit dem effizientesten Weg der Abfrage der “Netto-Arbeitszeit” eines Benutzers. Dabei möchte ich Arbeitsbeginn, Arbeitsende, die Pausenzeiten, mögliche arbeitsfreie Zeiten und alle Termine, wie auch Service-Aktivitäten berücksichtigt wissen.

Nach den zuvor dargestellten Abfragemöglichkeiten, möchte ich Euch heute eine weitere Möglichkeit vorstellen, mit der man den Kalender eines Nutzers abfragen kann. Wir richten uns für das folgende Beispiel erneut unsere Stammdaten ein.

Zunächst bestimmen wir die Arbeitszeit mit einer Pause.

AZ_2406_TimeOff

Anschließend richten wir auch noch eine arbeitsfreie Zeit ein.

AZ_2406_User_WorkingHours

Wir erhalten ein einfaches Arbeits-zeitenmodell, das wir über den Kalender des Nutzers nunmehr noch mit ein paar Terminen und Service-Aktivitäten anreichern. Ich verwende dabei unterschiedliche Status Angaben, um zu kontrollieren, ob dies Auswirkungen auf die Darstellung hat.

AZ_2406_User_CalendarNachdem die Daten allesamt eingetragen wurden, sollte Euer Kalender in ungefähr – wie dargestellt – aussehen.

Die verwendeten Status habe ich der Beschreibung hinzugefügt, damit Ihr vergleichbare Termine bzw. Service-Aktivitäten in Euren Tests eintragen könnt.

Kommen wir nunmehr zu der weiteren Methode. Es sich um die ExpandCalendarRequest – Abfrage. Erneut arbeite ich mit dem SoapLogger-Tool aus dem SDK. Folgenden Code füge ich zur Überwachung hinzu:

SystemUser user = (SystemUser)service.Retrieve(„systemuser“, new Guid(„60D3FD89-57E8-E011-AEEC-000C299A9455“), new ColumnSet(true));

ExpandCalendarRequest req = new ExpandCalendarRequest();

req.CalendarId = user.CalendarId.Id;

req.Start = DateTime.Today;

req.End = DateTime.Today.AddDays(1);

ExpandCalendarResponse resp = (ExpandCalendarResponse)slos.Execute(req);

if (resp.result.Length > 0)

{

Console.WriteLine(„Successfully queried the _currentUser calendar.“);

}

Bevor ich zur Ausgabe komme, ein paar Anmerkungen zum Code. Zunächst müssen wir in diesem Fall die CalendarId des einzelnen Users ermitteln. Hierzu müssen wir eine Retrieve-Abfrage vorwegschicken. Erst im weiteren Schritt können wir dann die Kalendereinträge ermitteln.

Nun zur Ausgabe:

<c:value i:type=“b:ArrayOfTimeInfo“>

<b:TimeInfo>

<b:ActivityStatusCode>-1</b:ActivityStatusCode>

<b:CalendarId>f43b6134-eadc-e211-8229-000c299a9455</b:CalendarId>

<b:DisplayText />

<b:Effort>0</b:Effort>

<b:End>2013-06-24T07:00:00Z</b:End>

<b:IsActivity>false</b:IsActivity>

<b:SourceId>f53b6134-eadc-e211-8229-000c299a9455</b:SourceId>

<b:SourceTypeCode>4004</b:SourceTypeCode>

<b:Start>2013-06-24T06:30:00Z</b:Start>

<b:SubCode>Vacation</b:SubCode>

<b:TimeCode>Unavailable</b:TimeCode>

</b:TimeInfo>

<b:TimeInfo>

<b:ActivityStatusCode>-1</b:ActivityStatusCode>

<b:CalendarId>c4bd7dbf-e9dc-e211-8229-000c299a9455</b:CalendarId>

<b:DisplayText />

<b:Effort>1</b:Effort>

<b:End>2013-06-24T06:30:00Z</b:End>

<b:IsActivity>false</b:IsActivity>

<b:SourceId>17a3c2f9-e9dc-e211-8229-000c299a9455</b:SourceId>

<b:SourceTypeCode>4004</b:SourceTypeCode>

<b:Start>2013-06-24T06:00:00Z</b:Start>

<b:SubCode>Schedulable</b:SubCode>

<b:TimeCode>Available</b:TimeCode>

</b:TimeInfo>

<b:TimeInfo>

<b:ActivityStatusCode>-1</b:ActivityStatusCode>

<b:CalendarId>c4bd7dbf-e9dc-e211-8229-000c299a9455</b:CalendarId>

<b:DisplayText />

<b:Effort>1</b:Effort>

<b:End>2013-06-24T15:00:00Z</b:End>

<b:IsActivity>false</b:IsActivity>

<b:SourceId>17a3c2f9-e9dc-e211-8229-000c299a9455</b:SourceId>

<b:SourceTypeCode>4004</b:SourceTypeCode>

<b:Start>2013-06-24T07:00:00Z</b:Start>

<b:SubCode>Schedulable</b:SubCode>

<b:TimeCode>Available</b:TimeCode>

</b:TimeInfo>

<b:TimeInfo>

<b:ActivityStatusCode>-1</b:ActivityStatusCode>

<b:CalendarId>c4bd7dbf-e9dc-e211-8229-000c299a9455</b:CalendarId>

<b:DisplayText />

<b:Effort>0</b:Effort>

<b:End>2013-06-24T11:00:00Z</b:End>

<b:IsActivity>false</b:IsActivity>

<b:SourceId>18a3c2f9-e9dc-e211-8229-000c299a9455</b:SourceId>

<b:SourceTypeCode>4004</b:SourceTypeCode>

<b:Start>2013-06-24T10:00:00Z</b:Start>

<b:SubCode>Break</b:SubCode>

<b:TimeCode>Unavailable</b:TimeCode>

</b:TimeInfo>

</c:value>

Wir erhalten 4 Array Elemente. Von 08:30 – 09:00 unsere arbeitsfreie Zeit als “Vacation”, von 08:00 – 08:30 bzw. 09:00 – 17:00 verfügbare Arbeitszeit und von 12:00 – 13:00 unsere Pause als “Break”.

Keine Termine, keine Service-Aktivitäten…

Was fällt sonst noch auf? Wie in der Abfrage zuvor, wird die Pause nicht von der verfügbaren Arbeitszeit abgezogen – auch die Pause gilt also als verfügbare Arbeitszeit.

Da auch mit dieser Abfrage-Methode keine Termine bzw. Service-Aktivitäten zurückgeliefert werden, bedarf es auch hier einer weiteren Abfrage, um die Netto-Arbeitszeit zu ermitteln.

 

Fazit: Da diese Methode zunächst die Ermittlung der CalendarId des Nutzers voraussetzt, noch dazu kein Support für ein Multiple Request existiert, eignet sich diese Abfrage nur bedingt zur Ermittlung der Arbeitszeit.

Der Vorteil liegt jedoch darin, dass in diesem Fall Arbeitszeitbeginn und –ende, sowie die Pausen und arbeitsfreien Zeiten in einer Ausgabe zurückgeliefert werden.

Es kommt daher auf die Situation an, ob man diese Methode verwenden sollte. Auch hier für Euch zur besseren Übersicht:

ExpandCalendarRequest User.CalendarId.Id
Erhalten Arbeitsbeginn

importwizard_solidgreentick_thumb6

Erhalten Arbeitszeitende

importwizard_solidgreentick_thumb1

Erhalten Pausen

importwizard_solidgreentick_thumb1

Erhalten Arbeitsfreie Zeiten

importwizard_solidgreentick_thumb1

Erhalten Termine, die Status des Bereichs “Geplant” haben

16_error_thumb5

Erhalten Service-Aktivitäten, die Status des Bereichs “Geplant” haben

16_error_thumb6

 

Technorati Tags:

Ein Gedanke zu “Microsoft Dynamics CRM 2011 | Kalender per SDK abfragen

  1. Hallo,

    der Request „ExpandCalendarRequest“ ist zwar sehr nützlich und spart viel Arbeit ein. Die Kalenderregeln müssen dadurch nicht mühsam interpretiert werden. Leider haben wir festgestellt, dass die Anfrage zu lange dauert. Bei 10 Usern und einer Dauer von 2 Jahren kann die Anfrage zwischen 30 Sekunden und mehreren Minuten dauern. Das ist sehr schade. Da hilft nur ein eingenes internes caching und das wiederrum bringt andere Fehler mit sich. (Wann und wie oft wird der cache aktualisiert …). Kein Benutzer möchte freiwilig solange warten. Irgendwann gibt es auch Server-Timeouts wenn die Anfrage zu groß ist.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s