Diagnoseprotokollierung in Business Connectivity Services (Übersicht) (SharePoint Server 2010)

Artikel
01/22/2017

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Mithilfe von Ereignis- und Ablaufprotokollen auf Client oder Server können Sie Probleme im Zusammenhang mit Microsoft Business Connectivity Services auf Servern mit Microsoft SharePoint Server 2010 und in Microsoft Office 2010- Clientanwendungen behandeln. Jedem Eintrag im Ereignis- und Ablaufprotokoll ist außerdem eine Aktivitäts-ID zugeordnet, mit deren Hilfe Sie Probleme vom Client oder Server zur externen Datenquelle zurückverfolgen können.

Hinweis

Zusätzlich zu den in diesem Thema erörterten Protokollierungsmethoden können Sie das Microsoft System Center Operations Manager Management Pack verwenden, um eine auf Microsoft Business Connectivity Services basierende Lösung zu überwachen. Weitere Informationen zum Konfigurieren des System Center Operations Manager Management Packs finden Sie im Handbuch, das im Management Pack-Download unter Management Pack für Microsoft SharePoint 2010-Produkte (Beta) (https://go.microsoft.com/fwlink/?linkid=184971&clcid=0x407) enthalten ist.

Inhalt dieses Artikels:

Diagnoseprotokollierung in Business Connectivity Services
Informationen zu Aktivitäts-IDs
Diagnoseprotokollierung auf Servern
Diagnoseprotokollierung auf Office 2010-Clients
Beispiel: Verwenden der Diagnoseprotokollierung

Diagnoseprotokollierung in Business Connectivity Services

Die Diagnoseprotokollierung für auf Microsoft Business Connectivity Services basierende Lösungen wird auf Servern mit SharePoint Server 2010 sowie auf Office 2010-Clients ausgeführt. Es gibt zwei Protokolle: das Ereignisprotokoll und das Ablaufprotokoll. In beiden werden Diagnoseinformationen aufgezeichnet, die von Microsoft Business Connectivity Services generiert werden. In Ereignisprotokollen werden Fehlermeldungen aufgezeichnet. Ablaufprotokolle enthalten detailliertere Informationen, wie beispielsweise Stapelüberwachungen und Informationsmeldungen. Ablaufprotokolle enthalten im Allgemeinen mehr Details als Ereignisprotokolle.

Jedes protokollierte Informationselement enthält eine Aktivitäts-ID, bei der es sich um einen eindeutigen GUID-Wert handelt. Aktivitäts-ID-Werte können auch an externe Systeme gesendet werden, wenn ein Erstellungs-, Aktualisierungs- oder Löschvorgang für ein Element ausgeführt wird. Mithilfe von Aktivitäts-IDs kann eine Aktion vom Server oder Client zur externen Datenquelle verfolgt werden. Weitere Informationen zu Aktivitäts-IDs finden Sie unter Informationen zu Aktivitäts-IDs.

Sie können den Diagnoseprotokolliergrad für das Ereignisprotokoll und das Ablaufprotokoll festlegen. Dadurch werden die in die einzelnen Protokolle geschriebenen Informationstypen und -mengen begrenzt. In den folgenden Tabellen werden die verfügbaren Protokolliergrade für das Ereignisprotokoll und das Ablaufprotokoll beschrieben:

Ereignisprotokollgrade

Grad	Definition
Keine	Es findet keine Protokollierung statt.
Kritisch	Dieser Meldungstyp gibt einen schwerwiegenden Fehler an, durch den ein schwerwiegender Fehler in der Lösung verursacht wurde.
Fehler	Dieser Meldungstyp gibt eine Bedingung mit hoher Dringlichkeit an. Alle Fehlerereignisse sollten untersucht werden.
Warnung	Dieser Warnmeldungstyp gibt ein potenzielles Problem oder einen potenziellen Fehler an, das bzw. der möglicherweise überprüft werden muss. Warnmeldungen sollten beobachtet und über bestimmte Zeiträume nach Mustern untersucht werden.
Information	Informationsmeldungen erfordern keine Benutzeraktion. Sie können jedoch wichtige Daten für die Überwachung des Lösungsstatus innerhalb eines bestimmten Zeitraums enthalten.
Ausführlich	Dieser Ereignisprotokollgrade entspricht längeren Ereignissen oder Meldungen.

Ablaufprotokollgrade

Grad	Definition
Keine	Es werden keine Ablaufprotokolle geschrieben.
Unerwartet	Mit diesem Grad werden Meldungen zu Ereignissen protokolliert, die dazu führen, dass Lösungen nicht weiter verarbeitet werden. Wenn dieser Protokollgrad festgelegt ist, enthält das Protokoll nur Ereignisse mit diesem Grad.
Überwachbar	Dieser Grad wird verwendet, um Meldungen zu nicht behebbaren Ereignissen zu protokollieren, durch die zwar die Funktionalität der Lösung eingeschränkt wird, die Anwendung jedoch nicht angehalten wird. Wenn diesr Protokollgrad festgelegt ist, enthält das Protokoll außerdem kritische Fehler (Grad Unerwartet).
Hoch	Dieser Grad wird verwendet, um unerwartete Ereignisse zu protokollieren, durch die die Verarbeitung einer Lösung jedoch nicht angehalten wird. Wenn dieser Protokollgrad festgelegt ist, enthält das Protokoll Warnungen, Fehler (Grad Überwachbar) und kritische Fehler (Grad Unerwartet).
Mittel	Wenn dieser Grad festgelegt ist, enthält das Ablaufprotokoll alle außer ausführlichen Meldungen. Dieser Grad wird verwendet, um alle allgemeinen Informationen zu ausgeführten Vorgängen zu protokollieren. Mit diesem Grad werden genug Details protokolliert, um den Datenfluss und die Reihenfolge der Vorgänge zu erfassen. Dieser Protokollgrad kann von Administratoren oder Supportspezialisten für die Problembehandlung verwendet werden.
Ausführlich	Wenn dieser Protokollgrad festgelegt ist, enthält das Protokoll Meldungen mit allen anderen Graden. Wenn Sie diesen Grad verwenden, werden fast alle ausgeführten Aktionen protokolliert. Durch die ausführliche Ablaufverfolgung werden zahlreiche Protokollmeldungen erzeugt. Dieser Grad wird normalerweise nur zum Debuggen in einer Entwicklungsumgebung verwendet.

Diagnoseprotokolle sind sowohl in Entwicklungs- als auch in Produktionsumgebungen hilfreich, wobei jedoch je nach Art der Umgebung wahrscheinlich unterschiedliche Protokollgrade benötigt werden. Berücksichtigen Sie beim Planen der Diagnoseprotokollierung in Microsoft Business Connectivity Services die geschäftlichen Anforderungen und die Lebenszyklusphase der Umgebung, bevor Sie den Protokollgrad festlegen.

Sie können beispielsweise beim Lösungsentwurf zu Debuggingzwecken beide Protokollgrade auf Ausführlich festlegen, um alle Meldungen zu erfassen, die zum Systemstatus generiert werden. In einer Produktionsumgebung hingegen möchten Sie möglicherweise für Ablaufprotokolle nur Meldungen der Kategorien Hoch, Überwachbar und Unerwartet und für Ereignisprotokolle nur die Kategorien Kritisch und Fehler erfassen. Auf diese Weise sparen Sie Speicherplatz für die Protokollierung und begrenzen negative Auswirkungen der Protokollierung auf die Leistung.

Informationen zu Aktivitäts-IDs

Für jeden Erstellungs-, Aktualisierungs- oder Löschvorgang für externe Daten in einer auf Microsoft Business Connectivity Services basierenden Lösung wird auf dem Server und auf dem Office-Client ein eindeutiger GUID-Wert erstellt, der als Aktivitäts-ID bezeichnet wird. Alle im Ablauf- oder Ereignisprotokoll zu diesem Vorgang protokollierten Informationen enthalten den jeweiligen Aktivitäts-ID-Wert.

Wichtig

In den Ereignisprotokollen und Ablaufprotokolldateien auf dem Server sind die Aktivitäts-ID-Werte als CorrelationId-Werte gekennzeichnet.

Der für einen Erstellungs-, Aktualisierungs- oder Löschvorgang generierte Aktivitäts-ID-Wert wird zusammen mit weiteren Informationen zu diesem Vorgang an das externe System gesendet. Wenn das externe System über einen Protokollierungsmechanismus verfügt, kann der Wert in diesem System erfasst und protokolliert werden. Wenn durch einen Vorgang Einträge in den Protokollen auf dem SharePoint-Server oder dem Office-Client entstehen, kann daher der gesamte Vorgang anhand des Aktivitäts-ID-Werts zum externen System zurückverfolgt werden. Dadurch wird die End-to-End-Problembehandlung erleichtert.

Vorgänge wie beispielsweise Erstellungsvorgänge führen oft dazu, dass mehrere Ereignisse in die Protokolle geschrieben werden. Dabei wird für alle Ereignisse, die für einen bestimmten Vorgang protokolliert werden, der gleiche Aktivitäts-ID-Wert verwendet. Dies ist hilfreich bei der Problembehandlung, da aufgrund des wiederkehrenden Werts der Aktivitäts-ID leichter alle Ereignisse für einen bestimmten Vorgang gefunden werden können. Im Gegenzug wird für jede Instanz eines wiederholt ausgeführten Vorgangs ein eindeutiger Aktivitäts-ID-Wert generiert Wenn beispielsweise ein Element eines externen Inhaltstyps zweimal aktualisiert wird, wird jedem Aktualisierungsvorgang ein eindeutiger Aktivitäts-ID-Wert zugeordnet.

Tipp

Manchmal wird ein Vorgang, der nicht an das externe System weitergeleitet wurde, von Business Data Connectivity Service wiederholt. In diesen Fällen wird für den wiederholten Vorgang die gleiche Aktivitäts-ID verwendet.

Diagnoseprotokollierung auf Servern

Die Microsoft Business Connectivity Services-Protokollierung ist auf SharePoint Server-Servern standardmäßig aktiviert. Die Standardberechtigungsstufen lauten:

Für das Ereignisprotokoll: Kritisch und Fehler
Für das Ablaufprotokoll: Mittel

Falls die Diagnoseprotokollierung von Microsoft Business Connectivity Services deaktiviert ist, können Sie die Protokollierung aktivieren, indem Sie Business Connectivity Services auf der Seite Diagnoseprotokollierung in der SharePoint Server-Zentraladministration auswählen. Sie können zum Konfigurieren von Ereignis- und Ablaufprotokollen auf dem Server auch Windows PowerShell verwenden. Sie können beispielsweise das Laufwerk ändern, auf das die Protokolle geschrieben werden, und Sie können den Ausführlichkeitsgrad der Protokollierung festlegen.

Weitere Informationen zur Protokollierung in SharePoint Server, beispielsweise zum Festlegen des Speicherorts für die LOG-Dateien, finden Sie unter Konfigurieren der Diagnoseprotokollierung (SharePoint Server 2010).

Sie können Windows PowerShell verwenden, um die Ereignisprotokolle auf dem Server anzuzeigen, und Sie können die Protokolle exportieren, beispielsweise in ein Tabellenkalkulationsprogramm. Weitere Informationen finden Sie unter Anzeigen von Diagnoseprotokollen (SharePoint Server 2010).

Von Microsoft Business Connectivity Services werden zwei Kategorien an das Ablaufprotokoll auf SharePoint Server-Front-End-Webservern ausgegeben: BDC_Shared_Services und SS_Shared_Service. Sie können das Ablaufprotokoll mit der Ereignisanzeige öffnen und die relevanten Protokolleinträge filtern, indem Sie nach "SPS_BusinessData" (für Microsoft Business Connectivity Services-Ausgaben) und "SPS_SecureStoreService" suchen.

Diagnoseprotokollierung auf Office 2010-Clients

Ereignis- und Ablaufprotokolle für Microsoft Business Connectivity Services-Lösungen sind auf Microsoft Office 2010-Produktfamilien-Clients verfügbar, auf denen die Microsoft Business Connectivity Services-Infrastruktur verwendet wird. Die Ereignisprotokollierung für Microsoft Business Connectivity Services ist auf Clients standardmäßig aktiviert. Zum Schutz der Leistung werden jedoch nur Fehler und kritische Fehler protokolliert, und diese Einstellung kann nicht geändert werden. Clientcomputer unter Windows enthalten eine Ereignisanzeige, die Sie zum Anzeigen von Ereignisprotokollen verwenden können. Weitere Informationen zum Anzeigen von Ereignisprotokollen für eine bestimmte Version von Windows finden Sie in der Produktdokumentation.

Die Ablaufverfolgung ist auf Clientcomputern standardmäßig deaktiviert, um die Leistung zu verbessern. Sie sollten die Ablaufverfolgung nur dann auf Clientcomputern aktivieren, wenn Probleme auftreten, die Sie diagnostizieren möchten. Wenn beispielsweise ein Ereignisprotokolleintrag darauf hinweist, dass ein Fehler möglicherweise durch eine Aktivität im Zusammenhang mit Microsoft Business Connectivity Services verursacht wird, sollten Sie die Ablaufverfolgung aktivieren, um beim nächsten Auftreten des Ereignisses zusätzliche Daten zu sammeln.

Welche Methode Sie zum Aktivieren der Ablaufverfolgung und zum Lesen der Protokolle verwenden, hängt von der Windows-Version auf dem Computer ab. Auf Computern unter Windows XP beispielsweise aktivieren Sie die Ablaufverfolgung, indem Sie ein Skript ausführen, in dem der logman-Befehl verwendet wird. Unter Windows Vista und höher stehen neben dem logman-Befehl Systemtools wie beispielsweise die Zuverlässigkeits- und Leistungsüberwachung zur Verfügung. Details zum Aktivieren der Ablaufverfolgung und zum Erfassen der Ergebnisse finden Sie in der Windows-Produktdokumentation.

Im folgenden Beispielskript wird der logman-Befehl verwendet, um die Ablaufverfolgung zu aktivieren:

rem This script will enable logging, directing log messages to a file specified by the "%FILE_NAME%" given by the user.

@setlocal
@echo off
pushd %~dp0
set PATH_NAME=%TEMP%\BCS
set FILE_NAME=%PATH_NAME%\ETWTraceLog
set TRACE_COLLECTION=BCS
::tracelog -start BCS -guid #b8622a02-c377-46b1-b861-38a787a8e44a -b 128 -flags 0xFFFF -level 5 -f "%FILE_NAME%.etl"
md "%PATH_NAME%" 1>nul 2>nul
logman create trace %TRACE_COLLECTION% -p "{b8622a02-c377-46b1-b861-38a787a8e44a}" 0xFFFF 5 -o "%FILE_NAME%.etl" -ets
echo.
echo Business Connectivity Services tracing has been started. To end press any key.
echo.
pause

Wie auf dem Server wird für jeden Erstellungs-, Aktualisierungs- oder Löschvorgang für ein Element auf dem Client ein eindeutiger Aktivitäts-ID-Wert generiert. Diese Werte werden in den Protokollen aufgezeichnet und zusammen mit weiteren Informationen zu Vorgängen an externe Systeme gesendet. Eine Lösung kann auch so konfiguriert werden, dass Aktivitäts-ID-Werte in Fehlermeldungen angezeigt werden. Dadurch wird den Benutzern der Lösung die Problembehandlung erleichtert.

Wichtig

Da die erforderliche Version der Ablaufverfolgung für die Windows-Programmierschnittstelle, von der die Generierung der Aktivitäts-ID abhängig ist, im Betriebssystem Windows XP nicht verfügbar ist, wird die Generierung von Aktivitäts-IDs auf Clients unter Windows XP nicht unterstützt.

Beispiel: Verwenden der Diagnoseprotokollierung

Mit diesem kurzen vereinfachten Szenario wird die Verwendung der Diagnoseprotokollierung in einer Produktionsumgebung veranschaulicht. Ein Unternehmen hat eine neue Lösung für die Einreichung von Zeitkarten bereitgestellt, die auf Microsoft Business Connectivity Services basiert. Bei dieser Lösung wird ein externes System verwendet, um Zeitkarteninformationen für Mitarbeiter, beispielsweise Urlaub und krankheitsbedingte Abwesenheit, zu speichern und mit den Mitarbeitern und dem Lohn- und Gehaltsabrechnungssystem zu interagieren, wenn Mitarbeiter Abwesenheitszeiten melden. Die Mitarbeiter interagieren über ein Webpart mit dem System.

Die Protokollgrade in der Serverfarm sind auf die Standardwerte für Microsoft Business Connectivity Services festgelegt:

Für das Ereignisprotokoll: Kritisch und Fehler
Für das Ablaufprotokoll: Mittel

In diesem Szenario sendet ein Mitarbeiter einen Wert für die Anzahl der genommenen Urlaubstage. Jedoch erhält weder der Mitarbeiter noch der Vorgesetzte eine Bestätigungs-E-Mail, aus der hervorgeht, dass die genommenen Urlaubstage erfolgreich gesendet wurden. Der Mitarbeiter ruft den internen technischen Supportservice an und meldet das Problem.

Die Supporttechnikerin erkennt, dass die Zeitkartenanwendung auf Microsoft Business Connectivity Services basiert. Sie überprüft das Ereignisprotokoll, findet jedoch keinen der Identität des Benutzers zugeordneten Fehler für den Zeitpunkt, an dem der Benutzer die Zeitkartenanforderung gesendet hat. Die Supporttechnikerin überprüft das Ablaufprotokoll und findet dort Hinweise auf die Aktivität: einen dem Benutzer zugeordneten Aktualisierungsvorgang am entsprechenden Zeitpunkt. Der Aktualisierungsvorgang im Ablaufprotokoll enthält einen Aktivitäts-ID-Wert, den sich die Supporttechnikerin notiert.

Die Supporttechnikerin weiß, dass Protokollierung auch im externen System unterstützt wird. Anhand der Aktivitäts-ID findet sie das im externen System protokollierte Element sowie einen Hinweis darauf, dass am Ende des Aktualisierungsvorgangs ein Fehler in das Protokoll geschrieben wurde: bei der Aktualisierung ist ein Fehler aufgetreten, da der Mitarbeiter alle seine Urlaubstage aufgebraucht hatte. Sie stellt außerdem fest, dass es keinen Protokolleintrag gibt, durch den bestätigt wird, dass im externen System unmittelbar am Ende des Aktualisierungsvorgangs eine E-Mail-Nachricht generiert wurde. Die Supporttechnikerin kommt zum Schluss, dass ein Fehler in der Logik der Zeitkartenanwendung vorliegt. Obwohl die Anwendung ordnungsgemäß keine Bezahlung für die Urlaubstage zugewiesen hat, da die Zahl der dem Mitarbeiter zustehenden Urlaubstage überschritten war, wurde keine E-Mail-Nachricht generiert, um den Mitarbeiter über das Problem zu informieren. Die Supporttechnikerin meldet das Problem dem Entwicklungsteam, das die Anwendung erstellt hat, und das Entwicklungsteam aktualisiert die Anwendung.