Diagnoseprotokollierung in Business Connectivity Services – Übersicht (SharePoint Foundation 2010)

Artikel
12/02/2016

Gilt für: SharePoint Foundation 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Sie können Probleme bezüglich Microsoft Business Connectivity Services auf Servern mit Microsoft SharePoint Foundation 2010 mithilfe von Ereignisprotokollen und Ablaufverfolgungsprotokollen auf dem Client oder auf dem Server lösen. Zudem weist jeder Eintrag im Ereignisprotokoll oder Ablaufverfolgungsprotokoll eine Aktivitäts-ID auf, mit der ein Problem vom Server zur externen Datenquelle nachverfolgt werden kann.

Hinweis

Neben den in diesem Thema erörterten Protokollierungsmethoden können Sie auf Microsoft Business Connectivity Services basierende Lösungen mit Microsoft System Center Operations Manager Management Pack überwachen. Weitere Informationen zum Konfigurieren von System Center Operations Manager Management Pack finden Sie im Handbuch zum Download des Management Packs unter Management Pack für Microsoft SharePoint 2010-Produkte (https://go.microsoft.com/fwlink/?linkid=184971&clcid=0x407).

Inhalt dieses Artikels:

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

Diagnoseprotokollierung in Business Connectivity Services

Für Lösungen auf Grundlage von Microsoft Business Connectivity Services erfolgt die Diagnoseprotokollierung auf Servern, auf denen Microsoft SharePoint Foundation ausgeführt wird. Es gibt zwei Protokolle: Ereignisprotokoll und Ablaufverfolgungsprotokoll. In beiden werden von Microsoft Business Connectivity Services generierte Diagnoseinformationen aufgezeichnet. In Ereignisprotokollen werden Fehlermeldungen aufgezeichnet. Ablaufverfolgungsprotokolle enthalten ausführlichere Informationen, wie Stapelüberwachungen und Informationsmeldungen. Im Allgemeinen enthalten Ablaufverfolgungsprotokolle mehr Details als Ereignisprotokolle.

Jedes protokollierte Informationselement enthält eine Aktivitäts-ID, die einen eindeutigen GUID-Wert darstellt. Aktivitäts-ID-Werte können auch an externe Systeme gesendet werden, wenn für ein Element ein Erstellungs-, Aktualisierungs- oder Löschungsvorgang erfolgt. Mit Aktivitäts-IDs kann eine Aktion vom Server oder Client zur externen Datenquelle nachverfolgt werden. Weitere Informationen zu Aktivitäts-IDs finden Sie unter Informationen zu Aktivitäts-IDs .

Sie können den Grad der Diagnoseprotokollierung für das Ereignisprotokoll und für das Ablaufverfolgungsprotokoll festlegen. Dadurch werden die Typen und der Umfang der in die Protokolle geschriebenen Informationen beschränkt. In den folgenden Tabellen sind die verfügbaren Protokolliergrade für das Ereignisprotokoll und das Ablaufverfolgungsprotokoll definiert:

Ereignisprotokollgrade

Grad	Definition
Keine	Es erfolgt keine Protokollierung.
Kritisch	Dieser Meldungstyp zeigt einen schwerwiegenden Fehler an, der einen schwerwiegenden Fehler in der Lösung verursachte.
Fehler	Dieser Meldungstyp zeigt eine Bedingung mit hoher Dringlichkeit an. Alle Fehlerereignisse sollten untersucht werden.
Warnung	Dieser Meldungstyp zeigt einen potenziellen Fehler oder ein Problem an, das 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 Zustands der Lösung enthalten.
Ausführlich	Dieser Protokolliergrad des Ereignisprotokolls entspricht langen Ereignis- oder Meldungstexten.

Ablaufprotokollgrade

Grad	Definition
Keine	Es werden keine Ablaufverfolgungsprotokolle erstellt.
Unerwartet	Dieser Grad wird zur Protokollierung von Meldungen zu Ereignissen verwendet, die zum Abbruch der Verarbeitung von Lösungen führen. Wenn die Protokollierung auf diesen Grad festgelegt ist, enthält das Protokoll nur Ereignisse dieses Grads.
Überwachbar	Dieser Grad dient zur Protokollierung von Meldungen über nicht behebbare Ereignisse, die die Funktionalität der Lösung beeinträchtigen, aber nicht zum Abbruch der Anwendung führen. Wenn die Protokollierung auf diesen Grad festgelegt ist, enthält das Protokoll auch schwerwiegende Fehler (Grad Unerwartet).
Hoch	Bei diesem Protokolliergrad werden Ereignisse aufgezeichnet, die unerwartet sind, aber die Verarbeitung einer Lösung nicht verhindern. Wenn die Protokollierung auf diesen Grad festgelegt ist, enthält das Protokoll Warnungen, Fehler (Grad Überwachbar) und schwerwiegende Fehler (Grad Unerwartet).
Mittel	Wenn die Protokollierung auf diesen Grad festgelegt ist, enthält das Ablaufverfolgungsprotokoll alle Meldungstypen außer ausführlichen Meldungen. Dieser Grad dient zur Protokollierung allgemeiner Informationen zu ausgeführten Vorgängen. Bei diesem Grad werden genügend Details protokolliert, um den Datenfluss und die Abfolge von Vorgängen zu rekonstruieren. Dieser Protokolliergrad kann beispielsweise von Administratoren oder Supportmitarbeitern zur Behandlung von Problemen verwendet werden.
Ausführlich	Wenn die Protokollierung auf diesen Grad festgelegt ist, enthält das Protokoll Meldungen aller anderen Grade. Fast alle ausgeführten Aktionen werden bei diesem Grad protokolliert. Bei der ausführlichen Ablaufverfolgung werden umfangreiche Meldungen protokolliert. Dieser Grad wird gewöhnlich nur zum Debuggen in einer Entwicklungsumgebung verwendet.

Diagnoseprotokolle sind sowohl in Entwicklungs- als auch in Produktionsumgebungen nützlich. Die Anforderungen an den Protokolliergrad unterscheiden sich jedoch je nach Umgebung. Beim Planen der Diagnoseprotokollierung in Microsoft Business Connectivity Services sollten Sie die Geschäftsanforderungen und die Lebenszyklusphase der Umgebung berücksichtigen, bevor Sie den Protokolliergrad festlegen.

Beispielsweise ist es sinnvoll, beim Lösungsentwurf zu Debugzwecken beide Protokolliergrade auf Ausführlich festzulegen, um sämtliche Meldungen über den Zustand des Systems zu erfassen. Dagegen sollen in einer Produktionsumgebung möglicherweise nur Meldungen der Kategorien Hoch, Überwachbar und Unerwartet in Ablaufverfolgungsprotokollen sowie der Kategorien Kritisch und Fehler in Ereignisprotokollen erfasst werden. Auf diese Weise wird Speicherplatz für die Protokolle gespart und eine Leistungsbeeinträchtigung durch die Protokollierung begrenzt.

Informationen zu Aktivitäts-IDs

Für jeden Erstellungs-, Aktualisierungs- oder Löschungsvorgang für externe Dateien in einer auf Microsoft Business Connectivity Services basierten Lösung wird ein eindeutiger GUID-Wert generiert, der als Aktivitäts-ID bezeichnet wird. Alle mit dem Vorgang verbundenen Aufzeichnungen im Ablaufverfolgungs- oder Ereignisprotokoll enthalten den zugehörigen Aktivitäts-ID-Wert.

Wichtig

In den Ereignisprotokoll- und Ablaufverfolgungsprotokoll-Dateien auf dem Server werden Aktivitäts-ID-Werte als CorrelationId-Werte gekennzeichnet.

Der für einen Erstellungs-, Aktualisierungs- oder Löschungsvorgang generierte Aktivitäts-ID-Wert wird zusammen mit anderen Informationen zu dem Vorgang an das externe System gesendet. Wenn das externe System über einen Protokollierungsmechanismus verfügt, kann der Wert auf diesem System erfasst und protokolliert werden. Somit kann ein Vorgang, der Einträge in den SharePoint-Protokollen verursacht, anhand des Aktivitäts-ID-Werts im externen System nachverfolgt werden. Dies erleichtert die End-to-End-Problembehandlung.

Häufig werden für einen Vorgang, z. B. eine Erstellung, mehrere Ereignisse in den Protokollen verzeichnet. In diesem Fall wird derselbe Aktivitäts-ID-Wert für alle Ereignisse zu dem Vorgang verwendet. Dies ist für die Problembehandlung hilfreich, da der wiederkehrende Wert der Aktivitäts-ID die Suche nach allen Ereignissen zu einem Vorgang erleichtert. Umgekehrt wird bei wiederholtem Auftreten eines Vorgangstyps für jede Vorgangsinstanz ein eindeutiger Aktivitäts-ID-Wert generiert. Wenn beispielsweise ein Element von einem externen Inhaltstyp zwei Mal aktualisiert wird, wird jedem Aktualisierungsvorgang ein eindeutiger Aktivitäts-ID-Wert zugeordnet.

Tipp

Unter bestimmten Bedingungen wird ein Vorgang vom Business Data Connectivity Service wiederholt, wenn er das externe System nicht erreichen konnte. In diesen Fällen wird für den wiederholten Vorgang dieselbe Aktivitäts-ID verwendet.

Diagnoseprotokollierung auf Servern

Die Microsoft Business Connectivity Services-Protokollierung ist standardmäßig auf SharePoint Foundation-Servern aktiviert. Die Standardprotokolliergrade lauten wie folgt:

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

Sollte die Diagnoseprotokollierung von Microsoft Business Connectivity Services deaktiviert sein, können Sie sie durch Auswählen von Business Connectivity Services auf der Seite Diagnoseprotokollierung in der Zentraladministration von SharePoint Foundation aktivieren. Sie können auch mit Windows PowerShell Ereignisprotokolle und Ablaufverfolgungsprotokolle auf dem Server konfigurieren. Sie können beispielsweise das Laufwerk für die Protokollierung ändern und den Ausführlichkeitsgrad festlegen.

Weitere Informationen zur Protokollierung in SharePoint Foundation 2010, z. B. zum Festlegen des Speicherorts für die Protokolldateien, finden Sie unter Konfigurieren der Diagnoseprotokollierung (SharePoint Foundation 2010).

Sie können die Ereignisprotokolle mit Windows PowerShell auf dem Server anzeigen und beispielsweise in ein Arbeitsblatt exportieren. Weitere Informationen finden Sie unter Anzeigen von Diagnoseprotokollen (SharePoint Foundation 2010).

Von Microsoft Business Connectivity Services werden zwei Kategorien im Ablaufverfolgungsprotokoll auf SharePoint Foundation-Front-End-Webservern ausgegeben: BDC_Shared_Services und SS_Shared_Service. Sie können das Ereignisprotokoll mit der Ereignisanzeige öffnen und nach relevanten Einträgen filtern, indem Sie nach SPS_BusinessData (für Microsoft Business Connectivity Services-Ausgaben) und SPS_SecureStoreService suchen.

Beispiel: Verwenden der Diagnoseprotokollierung

Dieses kurze, vereinfachte Szenario veranschaulicht die Verwendung der Diagnoseprotokollierung in einer Produktionsumgebung. Ein Unternehmen hat eine neue, auf Microsoft Business Connectivity Services basierende Zeiterfassungslösung bereitgestellt. Diese Lösung verwendet ein externes System zur Speicherung der Zeitkarteninformationen für Mitarbeiter, wie Urlaubszeiten und Krankheitstage, und zur Interaktion mit Mitarbeitern und dem Lohnabrechnungssystem, wenn Mitarbeiter eine Abwesenheit melden. Die Mitarbeiter interagieren über ein Webpart mit dem System.

In der Serverfarm werden die Protokolliergrade auf die Standardwerte für Microsoft Business Connectivity Services festgelegt:

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

In diesem Szenario sendet ein Mitarbeiter einen Wert für die Anzahl der Fehlstunden aufgrund von Krankheit, aber weder der Mitarbeiter noch sein Manager empfangen eine Bestätigungs-E-Mail darüber, dass die Fehlzeit erfolgreich mitgeteilt wurde. Der Mitarbeiter ruft den internen technischen Support an und meldet das Problem.

Die Supportmitarbeiterin erkennt, dass die Zeiterfassungsanwendung auf Microsoft Business Connectivity Services basiert. Sie überprüft das Ereignisprotokoll, findet jedoch keinen Fehler in Verbindung mit der Identität des Benutzers zu der Zeit, als dieser die Zeitkartenanforderung gesendet hat. Im Ablaufverfolgungsprotokoll findet sie einen Nachweis für die Aktivität: ein dem Benutzer zugeordneter Aktualisierungsvorgang zur betreffenden Zeit. Der Aktualisierungsvorgang im Ablaufverfolgungsprotokoll enthält einen Aktivitäts-ID-Wert, der von der Supportmitarbeiterin notiert wird.

Die Supportmitarbeiterin weiß, dass auch im externen System die Protokollierung unterstützt wird. Sie lokalisiert das im externen System protokollierte Element mithilfe der Aktivitäts-ID und findet einen Fehler, der am Ende des Aktualisierungsvorgangs protokolliert wurde: die Aktualisierung war nicht möglich, da die dem Mitarbeiter zustehende Abwesenheitszeit wegen Krankheit verbraucht war. Ferner stellt sie fest, dass kein Protokolleintrag vorliegt, der die Generierung einer E-Mail-Nachricht im externen System am Ende des Aktualisierungsvorgangs bestätigt. Die Supportmitarbeiterin folgert, dass die Logik der Zeiterfassungsanwendung einen Fehler aufweist. Obwohl die Anwendung ordnungsgemäß die Zahlung für Krankheitszeit unterlassen hat, als die dem Mitarbeiter zustehende Anzahl an Stunden überschritten war, wurde keine entsprechende E-Mail-Nachricht an den Mitarbeiter generiert. Sie meldet das Problem dem Entwicklungsteam, das die Anwendung erstellt hat. Das Entwicklungsteam aktualisiert die Anwendung.

Share via