none
[gelöst] Fehler bei Berichten mit langer Ausführungszeit RRS feed

  • Frage

  • Hallo,

    ich habe ein Problem beim Ausführen von Berichten, das ich im folgenden kurz schildern möchte.

    Umgebung (CRM-Server):
    MS Windows Server 2003 R2 Standard Edition SP2,
    MS SQL Server 2005 Standard Edition SP3 (alle Komponenten),
    MS Dynamics CRM 4.0 Professional Edition + Update Rollup 12


    Es wurden einige Berichte auf folgende Weise erstellt:

    • Zunächst wurden auf dem CRM-Server Views erstellt, die die für die Berichte benötigten Daten zusammensammeln. Diese Views benutzen ihrerseits die Filtered...-Views des CRM-Systems. Da die in den Views enthaltenen Abfragen recht komplex sind, ist die Ausführungszeit auch relativ lang (> halbe Stunde).
    • Auf einem separaten Rechner (Entwicklungsrechner) wurden mittels Visual Studio 2005 SP1 Berichte erstellt. Dabei wurde der CRM-Server als DataSource bzw. die besagten Views als DataSets eingebunden. Beim Testen unter VS (Vorschau) funktionierten die Berichte trotz der langen Ausführungszeit einwandfrei.
    • Schließlich wurden die Berichte ins CRM importiert, über die CRM-Web-Oberfläche, mittels Berichte/Neu, Berichtstyp=Vorhandene Datei, Dateispeicherort=<von VS erstellte RDL-Datei>, etc.

    Startet man einen so erstellten Bericht jetzt direkt von CRM aus, so bricht er nach ein paar Minuten ab mit der Meldung "Fehler -- Es ist ein Fehler aufgetreten. -- Wiederholen Sie die Aktion. [...] ". Im Event-Log auf dem CRM-Server findet sich folgender Eintrag:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Ereignistyp:    Warnung
    Ereignisquelle:    ASP.NET 2.0.50727.0
    Ereigniskategorie:    Webereignis
    Ereigniskennung:    1309
    Datum:        29.11.2010
    Zeit:        13:24:54
    Benutzer:        Nicht zutreffend
    Computer:    TU-CRM02
    Beschreibung:
    Ereigniscode: 3005
    Ereignismeldung: Es ist eine unbehandelte Ausnahme aufgetreten.
    Ereigniszeit: 29.11.2010 13:24:53
    Ereigniszeit (UTC): 29.11.2010 12:24:53
    Ereignis-ID: 38f86b39a8a144bf97f36ee092b4a367
    Ereignissequenz: 39
    Vorkommen: 1
    Ereignisdetailcode: 0
     
    Anwendungsinformationen:
        Anwendungsdomäne: /LM/W3SVC/1/ROOT-1-129355064365957762
        Vertrauensebene: Full
        Virtueller Anwendungspfad: /
        Anwendungspfad: c:\inetpub\wwwroot\
        Computername: TU-CRM02
     
    Prozessinformationen:
        Prozess-ID: 4164
        Prozessname: w3wp.exe
        Kontoname: NT-AUTORITÄT\NETZWERKDIENST
     
    Ausnahmeinformationen:
        Ausnahmetyp: SoapException
        Ausnahmemeldung: System.Web.Services.Protocols.SoapException: Die Ausführung 'gqcvvfnmj5wc1bjbudbrdr45' wurde nicht gefunden. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: Die Ausführung 'gqcvvfnmj5wc1bjbudbrdr45' wurde nicht gefunden.
       --- Ende der internen Ausnahmestapelüberwachung ---
       bei Microsoft.ReportingServices.WebServer.ReportExecution2005Impl.GetExecutionInfo(ExecutionInfo& executionInfo)
       bei Microsoft.ReportingServices.WebServer.ReportExecutionService.GetExecutionInfo(ExecutionInfo& executionInfo)
     
    Anforderungsinformationen:
        [den Müll schenke ich mir jetzt mal]

    Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Ungeachtet der kryptischen Fehlermeldung scheint es sich im Grunde um ein Timeout-Problem zu handeln. Um dies zu überprüfen habe ich mal testweise die komplexe Abfrage in einem der Views durch eine triviale Abfrage ersetzt, die praktisch sofort ein Ergebnis liefert (mittels ALTER VIEW). Danach funktionierte der davon abhängige Bericht -- technisch -- korrekt (inhaltlich wurden natürlich nicht mehr die korrekten Daten angezeigt).

    Nun ist die Frage, ob es irgendwo eine "Stellschraube" gibt, mit der man CRM dazu bringen kann, auch Berichte mit langer Ausführungszeit korrekt auszuführen. Da die Ausführungszeit aus Anwendersicht nachrangig ist, wäre das Problem damit für mich gelöst.

    Ich habe übrigens auch noch mit Einträgen in der Registrierung unter HKLM\Software\Microsoft\MSCRM\ gespielt, die mit irgendwelchen Rollups eingeführt bzw. irgendwo im Netz beschrieben wurden:

    • NormalTimeout auf 36000000 (=10 Std.) raufgesetzt
    • ExtendedTimeout auf 36000000 (=10 Std.) raufgesetzt

    -- leider ohne Erfolg.


    Jetzt weiß ich nicht mehr weiter, hat jemand anders eine Idee?

    • Bearbeitet Gernot Meyer Donnerstag, 2. Dezember 2010 16:32 Problem gelöst
    Montag, 29. November 2010 15:57

Antworten

  • Hallo Gernot,

    es gibt noch weitere RegKeys, die du versuchen kannst. Es gibt dazu einen sehr schönen beitrag von Carsen Groth, den du hier finden kannst:

    http://carstengroth.wordpress.com/2010/11/08/microsoft-dynamics-crm-4-0-wichtige-registry-settings/

     


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website
    • Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:25
    Montag, 29. November 2010 17:20
  • Hallo,

     

    ich habe durch Zufall doch noch eine Lösung gefunden:

    Es gibt in der Datei C:\Inetpub\wwwroot\web.config, das ist die web.config in dem Basisverzeichnis für die MSCRM-Website, also wo die CRM-relevanten Dateien für den IIS abgelegt sind, ein Attribut executionTimeout:

    <configuration>
      <system.web>
       <httpRuntime executionTimeout="300"
    
     maxRequestLength="8192"/>
      </system.web>
    </configuration>
    

    (Dieser Codeblock entspricht dem Inhalt der Datei web.config in stark verkürtzer Form, um zu zeigen, wo genau in der XML-Struktur sich das besagte Attribut befindet.)

    Setzt man den Wert von 300 auf z. B. 3000 hoch, also von 300sek=5min auf 50min, dann werden die Berichte korrekt erstellt.

    Seltsamerweise werden die kryptischen EventLog-Einträge ("Es ist eine unbehandelte Ausnahme aufgetreten.") immer noch erzeugt, jedesmal, wenn ein Bericht erstellt wird. Also besteht, anders als ursprünglich vermutet, zwischen diesen Einträgen und dem Fehler, der zunächst bei der Berichtserstellung auftrat, gar kein ursächlicher Zusammenhang.

    • Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:22
    Donnerstag, 2. Dezember 2010 16:31

Alle Antworten

  • Hallo Gernot,

    es gibt noch weitere RegKeys, die du versuchen kannst. Es gibt dazu einen sehr schönen beitrag von Carsen Groth, den du hier finden kannst:

    http://carstengroth.wordpress.com/2010/11/08/microsoft-dynamics-crm-4-0-wichtige-registry-settings/

     


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website
    • Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:25
    Montag, 29. November 2010 17:20
  • Hallo Michael,

     

    vielen Dank für die Antwort!

    Allerdings kommt von den RegKeys m. E. nur noch OLEDBTimeout in Betracht, um einen Timeout festzulegen. Das habe ich jetzt auch getestet, d. h. ich habe den Wert auf 86400 (=24 Std.) hochgesetzt, allerdings ohne Erfolg.

    Die anderen RegKeys sind 0/1-Flags, mit denen man irgendwelche Rollup-Verbesserungen aus- und einschalten kann. Die hatte ich beim Einspielen des Rollups ohnehin bereits entsprechend der Dokumentation in der Knowledgebase gesetzt, d. h. ich hatte vorsichtshalber alle Features eingeschaltet, damit mir sozusagen nichts entgeht.


    Viele Grüße

     

    Dienstag, 30. November 2010 14:40
  • Hallo Gernot,

    weitere Stellschrauben kenne ich nicht. Was hälst du von der Idee, die Reports zeitgesteuert auszuführen und dann für eine bestimmte Zeit schreibzuschützen und diesen bereits ermittelten Report anzuzeigen. Gerade bei Reports mit langen Laufzeiten macht dies aus meiner Sicht Sinn.

    Ob das allerdings das Timeout-Problem löst, müsstest du erst einmal ausprobieren.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website
    Dienstag, 30. November 2010 15:43
  • Hallo,

     

    ich habe durch Zufall doch noch eine Lösung gefunden:

    Es gibt in der Datei C:\Inetpub\wwwroot\web.config, das ist die web.config in dem Basisverzeichnis für die MSCRM-Website, also wo die CRM-relevanten Dateien für den IIS abgelegt sind, ein Attribut executionTimeout:

    <configuration>
      <system.web>
       <httpRuntime executionTimeout="300"
    
     maxRequestLength="8192"/>
      </system.web>
    </configuration>
    

    (Dieser Codeblock entspricht dem Inhalt der Datei web.config in stark verkürtzer Form, um zu zeigen, wo genau in der XML-Struktur sich das besagte Attribut befindet.)

    Setzt man den Wert von 300 auf z. B. 3000 hoch, also von 300sek=5min auf 50min, dann werden die Berichte korrekt erstellt.

    Seltsamerweise werden die kryptischen EventLog-Einträge ("Es ist eine unbehandelte Ausnahme aufgetreten.") immer noch erzeugt, jedesmal, wenn ein Bericht erstellt wird. Also besteht, anders als ursprünglich vermutet, zwischen diesen Einträgen und dem Fehler, der zunächst bei der Berichtserstellung auftrat, gar kein ursächlicher Zusammenhang.

    • Als Antwort markiert Michael Sulz Montag, 13. Dezember 2010 15:22
    Donnerstag, 2. Dezember 2010 16:31