Ferne Transaktionen im Distributed Data Manager verstehen


Übersicht

Beispiele

Kontext

Tivoli Problem Management-Verwaltung

Übersicht

Ferne Transaktionen verstehen

Eine Transaktion zu einer fernen Lage ist erfolgreich abgeschlossen, wenn alle unter Tivoli Problem Management ausgeführten Computer, Software und Netze in Ihrem Unternehmen fehlerfrei ausgeführt werden. Als Transaktionen kommen in Frage: Problemübertragung zu einer fernen Lage, Verknüpfen eines Anrufs mit einem Problem an einer fernen Lage, Anzeigen aller aktuellen Probleminformationen an einer fernen Lage usw. Weitere Informationen zu fernen Transaktionstypen finden Sie unter dem jeweiligen Hilfethema.

Transaktionen zu fernen Lagen werden im Distributed Data Manager folgendermaßen ausgeführt:

  1. Lage A packt die Daten und sendet sie zu Lage B.
  2. Lage B entpackt die Transaktionsdaten.
  3. Lage B sendet eine Bestätigung der abgeschlossenen Transaktion zu Lage A. Diese Bestätigung kann eine erfolgreiche oder eine fehlgeschlagene Transaktion zu Lage B anzeigen.
  4. Lage A führt zusätzliche Aufgaben aus, abhängig davon, ob die ferne Transaktion erfolgreich war oder fehlgeschlagen ist.

Transaktionen zu fernen Lagen werden in Ihrem Unternehmen über die Anwendungs-Server von Distributed Data Manager unter Verwendung von Steuertabellen ausgeführt. Steuertabellen sind Datenbanksätze mit Daten, die nötig sind, um Transaktionen zu starten und auszuführen, wie in der folgenden Tabelle dargestellt.

Steuertabelle Beschreibung
REMOTE_WORK Jeder Satz speichert die spezifischen Daten, die zur Ausführung einer spezifischen fernen Transaktion nötig sind. Ein REMOTE_WORK-Satz ähnelt einem PROBLEM_CLOSURE-Satz in Tivoli Problem Management.
REMOTE_TASKS Ein Satz, der für jede Lage erstellt wird, an dem eine bestimmte REMOTE_WORK-Transaktion ausgeführt werden soll.
LOCAL_WORK Ein Satz, der von einer fernen Lage bei Beginn der fernen Transaktion erstellt wird. Wenn die ferne Transaktion beendet ist, wird die lokale Lage benachrichtigt. Wenn die lokale Lage aus bestimmten Gründen nicht benachrichtigt werden kann, wird der LOCAL_WORK-Satz zur späteren Benachrichtigung der lokalen Lage verwendet.

Beispiele

Erfolgreiche Transaktion

Eine Transaktion zu einer fernen Lage ist in folgenden Fällen erfolgreich:
  1. Ein Analytiker an Lage A ruft eine Transaktion zu Lage B auf.
  2. Der Anwendungs-Server an Lage A packt und sendet die Transaktion an den Anwendungs-Server von Lage B.
  3. Der Anwendungs-Server an Lage B entpackt die Transaktion und führt die zugehörigen Arbeitsgänge aus.
  4. Der Anwendungs-Server von Lage B sendet eine Empfangsbestätigung an den Anwendungs-Server von Lage A.
  5. Der Anwendungs-Server von Lage A löscht den REMOTE_TASKS-Satz.
Anstehende Transaktion Eine Transaktion zu einer fernen Lage ist in folgenden Fällen anstehend (PEND):
  1. Ein Analytiker an Lage A ruft eine Transaktion zu Lage B auf.
  2. Der Anwendungs-Server an Lage A packt und sendet die Transaktion an den Anwendungs-Server von Lage B.
  3. Der Anwendungs-Server an Lage B entpackt die Transaktion und führt die zugehörigen Arbeitsgänge aus.
  4. Der Anwendungs-Server von Lage B kann keine Empfangsbestätigung an den Anwendungs-Server von Lage A senden.
  5. Der Anwendungs-Server von Lage A kennzeichnet den REMOTE_TASKS-Satz als anstehend.
    Ein Problem an Lage B im Bereich Netz, Anwendungs-Server oder Datenbank kann die Ursache einer anstehenden Transaktion sein.
  6. Die Lage B versucht regelmäßig, eine im LOCAL_WORK-Satz enthaltene Empfangsbestätigung an den Anwendungs-Server von Lage A zu senden. Sobald der Anwendungs-Server an Lage B eine Empfangsbestätigung senden kann, wird die Transaktion vom Anwendungs-Server von Lage A beendet.

Fehlgeschlagene Transaktion 1

Eine Transaktion zu einer fernen Lage ist in folgenden Fällen fehlgeschlagen:
  1. Ein Analytiker an Lage A ruft eine Transaktion zu Lage B auf.
  2. Der Anwendungs-Server an Lage A packt die Transaktion und kann sie nicht an den Anwendungs-Server von Lage B senden, oder der Anwendungs-Server von Lage B kann die Transaktion nicht empfangen.
    Ein Netzwerkfehler oder ein angehaltener bzw. ausgesetzter Anwendungs-Server an Lage B können zum Fehlschlagen einer Transaktion führen.
  3. Der Anwendungs-Server von Lage A kennzeichnet den REMOTE_TASKS-Satz als fehlgeschlagen.
  4. Der Anwendungs-Server an Lage A versucht regelmäßig die Transaktion erneut zu senden. Dies ist nicht der Fall, wenn der Distributed Data Manager an Lage A so konfiguriert ist, daß fehlgeschlagene Problemweitergaben zu fernen Lagen automatisch abgebrochen werden.

Fehlgeschlagene Transaktion 2

Transaktionen zu fernen Lagen können auch auf Datenbankebene fehlschlagen, und zwar in folgenden Fällen:
  1. Ein Analytiker an Lage A ruft eine Transaktion zu Lage B auf.
  2. Der Anwendungs-Server an Lage A packt und sendet die Transaktion an den Anwendungs-Server von Lage B.
  3. Der Anwendungs-Server an Lage B entpackt die Transaktion, ist aber nicht in der Lage, die zugehörigen Arbeitsgänge auf Datenbankebene auszuführen.
  4. Der Anwendungs-Server von Lage B sendet eine Empfangsbestätigung an den Anwendungs-Server von Lage A und teilt ihm das Fehlschlagen der Transaktion mit.