Eigenschaftsname | Gültige Werte |
---|---|
Aus folgender Schablone erstellen | Name der Schablone, auf der das Collaboration-Objekt basiert. Nur Lesezugriff |
Effektive Transaktionsebene | Keine, Minimaler Aufwand, Größter Aufwand oder Stringent |
Minimale Transaktionsebene | Keine, Minimaler Aufwand, Größter Aufwand oder Stringent, abhängig von der Konstruktion der Collaboration-Schablone |
Systemtracestufe | 0 - Kein Tracing,
1 - Collaboration-Operationen, 2 - Und Collaboration-Ereignisse, 3 - Und Statustransaktionen, 4 - Und eingehende/abgehende Nachrichten, 5 - Und detaillierte Nachrichteninhalte |
Collaboration-Tracestufe | 0 bis 5 |
Adresse für E-Mail-Benachrichtigungen | Beliebiger gültiger E-Mail-Aliasname |
Bei kritischem Fehler anhalten | Markiert oder nicht markiert |
Höchstzahl gleichzeitiger Ereignisse | 0 bis 9999 |
Serviceaufruf in Übergangsstatus bestehen lassen | Markiert oder nicht markiert |
Wiederherstellungsmodus | Immer oder Verzögert |
Implizite Datenbanktransaktion | Markiert oder nicht markiert |
Maximale Ereigniskapazität | Ganzzahliger Wert zwischen 1 und 2147483647 |
Blockungstyp | Markiert oder nicht markiert |
Ereignisisolierung | Markiert oder nicht markiert |
In diesem schreibgeschützten Textfeld wird der Name der Collaboration-Schablone, auf der das Collaboration-Objekt basiert, angezeigt.
Die effektive Transaktionsebene ist ein Bereich zwischen der höchsten maximalen Transaktionsebene aller Collaboration-Objekte und der niedrigsten maximalen Transaktionsebene aller Connectors, die an das Objekt gebunden sind.
Sie können die effektive Transaktionsebene einer Collaboration verringern, wenn Sie eine Bindung an einen Connector vornehmen wollen, der eine bestimmte Transaktionsebene nicht unterstützt.
Wählen Sie zum Ändern der effektiven Transaktionsebene den gewünschten Wert in der Dropdown-Liste Effektive Transaktionsebene aus und klicken Sie anschließend OK an.
Die minimale Transaktionsebene gibt die niedrigste Transaktionsebene der Collaboration-Schablone und aller auf dieser Schablone basierenden Objekte an.
Hat der Entwickler einer Collaboration-Schablone beispielsweise eine minimale Transaktionsebene von Größter Aufwand für die Schablone angegeben, müssen alle auf dieser Schablone basierenden Objekte mit der Transaktionsebene Größter Aufwand oder Stringent arbeiten. Wie im Abschnitt Effektive Transaktionsebene beschrieben, müssen alle an das Collaboration-Objekt gebundenen Komponenten dessen effektive Transaktionsebene unterstützen. Die minimale Transaktionsebene stellt daher eine Möglichkeit dar, mit der der Entwickler einer Collaboration-Schablone die niedrigste Transaktionsebene festlegen kann, auf der alle auf dieser Schablone basierenden Collaboration-Objekte ausgeführt werden müssen.
Das Feld Minimale Transaktionsebene ist schreibgeschützt, wenn ein Collaboration-Objekt konfiguriert wird; es kann nur in der Collaboration-Schablone geändert werden.
Weitere Informationen zum Ändern von Collaboration-Schablonen finden Sie in der Dokumentation Collaboration Development Guide.
Sie können Collaboration-Objekte so konfigurieren, dass Informationen über die Ausführung der Collaboration in der Serverausgabe ausgegeben werden. Wählen Sie hierzu im Dropdown-Menü Systemtracestufe den gewünschten Wert aus. In der unten stehenden Tabelle werden die einzelnen Stufen und die jeweils ausgegebenen Informationen beschrieben:
Tabelle: Systemtracestufen
Systemtracestufe | Ausgegebene Informationen |
---|---|
0 - Kein Tracing
| Bei dieser Stufe werden keine Informationen verfolgt |
1 - Collaboration-Operationen
| Verfolgt den Empfang von Geschäftsobjekten von Connectors sowie den Start von Szenarios |
2 - Und Collaboration-Ereignisse
| Gibt Nachrichten für Stufe 1 sowie Nachrichten über den Start und die Beendigung der einzelnen Szenarios einschließlich weitergehender Ausführung und Rollbacks aus |
3 - Und Statustransaktionen
| Gibt Nachrichten für die Stufen 1 und 2 sowie Nachrichten über die Ausführung der einzelnen Entscheidungsblocks oder Aktionsknoten des Szenarios aus |
4 - Und eingehende/abgehende Nachrichten
| Gibt Nachrichten für die Stufen 1 bis 3 sowie Nachrichten über das Versenden und den Empfang der einzelnen Geschäftsobjekte in jedem Szenario aus |
5 - Und detaillierte Nachrichteninhalte | Gibt Nachrichten für die Stufen 1 bis 4 sowie die Struktur der verarbeiteten Geschäftsobjekte und den Wert der einzelnen Attribute aus |
Entwickler von Collaborations können Collaboration-Schablonen mit jeweils für die einzelnen Schablonen definierter Traceverarbeitung entwickeln. Während die Systemtraceverarbeitung (beschrieben im Abschnitt Systemtrace) Traceinformationen über die Collaboration-Ausführung im Allgemeinen bereitstellt, gibt die Collaboration-Traceverarbeitung Informationen über eine bestimmte Collaboration aus. Dies kann beispielsweise in den folgenden Fällen hilfreich sein:
Wählen Sie im Dropdown-Menü Collaboration-Tracestufe den gewünschten Wert (von 0 bis 5) aus, um die Collaboration-Tracestufe festzulegen.
Welche Informationen für eine bestimmte Collaboration in den einzelnen Tracestufen ausgegeben werden, ist in der Dokumentation für die entsprechende Collaboration-Schablone aufgeführt.
Weitere Informationen zum Ändern von Collaboration-Schablonen, um Collaboration-Traceverarbeitung zu implementieren, finden Sie in der Dokumentation Collaboration Development Guide.
Sie können ein Collaboration-Objekt so konfigurieren, dass E-Mail-Benachrichtigungen versandt werden, falls Fehler mit Bezug auf ein bestimmtes Objekt auftreten. Hierdurch wird eine schnittstellenspezifische Verwaltung ermöglicht, falls dies gewünscht ist. Eine Site kann beispielsweise einen Administrator benennen, der für Fehler in WebSphere InterChange Server zuständig ist, einen Administrator, der die Synchronisationsschnittstelle des Kundenkontos betreut und einen dritten, der für eine Schnittstelle für die Bestellabwicklung zuständig ist.
Geben Sie im Feld Adresse für E-Mail-Benachrichtigung die E-Mail-Adressen (im SMTP-konformen Format) ein, an die Fehlerbenachrichtigungen gesandt werden sollen. Sie können mehrere Adressen eingeben und diese durch Kommas voneinander trennen. Weitere Informationen zum Einrichten des Systems für das Versenden von E-Mail-Benachrichtigungen finden Sie im Abschnitt "Eigenschaften der E-Mail-Benachrichtigung mit Hilfe von System Manager konfigurieren" und in der Dokumentation "System Administration Guide".
Viele Collaboration-Schablonen bieten eine größere Konfigurierbarkeit der E-Mail-Benachrichtigungen, die über das bloße Festlegen des Werts im Feld Adresse für E-Mail-Benachrichtigung hinausgeht. Der Grad der Konfigurierbarkeit hängt ausschließlich von der Konstruktion der Collaboration-Schablone ab; daher finden Sie Informationen über die Handhabung der E-Mail-Benachrichtigung in der Dokumentation für die jeweilige Collaboration-Schablone.
In bestimmten Fällen kann durch auftretende Fehler verhindert werden, dass die Geschäftsobjektanforderungen einer Collaboration durch die Connectors, an die diese Anforderungen gesendet werden, verarbeitet werden. Zu diesen Fehlern gehören die folgenden:
Treten solche Fehler auf, sendet die Collaboration die Anforderung an den Connector; der Ablauf schlägt jedoch aufgrund des Fehlers fehl. Dies trifft auf alle gesendeten Anforderungen zu, bis der Fehler behoben wird, und kann daher zu einer großen Anzahl fehlgeschlagener Abläufe für die Schnittstelle führen, falls das Transaktionsvolumen hoch ist und der Fehler eine lange Zeit fortbesteht.
Sie können ein Collaboration-Objekt so konfigurieren, dass es das Senden von Anforderungen an einen Connector stoppt, wenn eine Anforderung aufgrund eines kritischen Fehlers fehlgeschlagen ist. Wählen Sie hierzu das Markierungsfeld Bei kritischem Fehler anhalten aus.
Weitere Informationen zu kritischen Fehlern, die Antworten eines Collaboration-Objekts auf diese Fehler und die Funktionalität dieses Merkmals finden Sie im System Administration Guide.
Sie können Collaboration-Objekte so konfigurieren, dass sie mehrere durch Ereignisse ausgelöste Abläufe gleichzeitig verarbeiten. Dies kann den Durchsatz der Schnittstelle verbessern. Wählen Sie hierzu im Dropdown-Menü Höchstzahl gleichzeitiger Ereignisse die Anzahl der Ereignisse (zwischen 0 und 9999) aus, die das Collaboration-Objekt gleichzeitig verarbeiten können soll.
Um die Vorzüge dieser Möglichkeit der Collaboration optimal nutzen zu können, müssen Sie darüber hinaus auch andere Komponenten, die Teil der Schnittstelle sind, so konfigurieren, dass sie sich ähnlich verhalten. Weitere Informationen finden Sie unter "Die gleichzeitige Verarbeitung von durch Ereignissen ausgelösten Abläufen implementieren".
Es kann vorkommen, dass ein Fehler auftritt, nachdem eine Collaboration eine Geschäftsobjektanforderung an die Zielconnectors, an die es gebunden ist, gesendet hat, aber bevor sie eine Antwort von den Connectors erhalten hat, ob die Verarbeitung der Anforderung in der jeweiligen Anwendung erfolgreich war oder nicht. Konnten die Connectors die Anforderung nicht verarbeiten, muss die Anforderung erneut verarbeitet werden, sobald der Fehler behoben wurde. Falls die Connectors die Anforderung jedoch erfolgreich verarbeiten konnten und beim Auftreten des Fehlers gerade eine Benachrichtigung über die erfolgreiche Verarbeitung an InterChange Server gesendet haben, hat InterChange Server diese Benachrichtigung nicht erhalten. Der letzte Eintrag bezüglich des Status der Anforderung würde in diesem Fall angeben, dass die Anforderung noch verarbeitet werden muss. Aufgrund dieses falschen Statuseintrags würde die Anforderung ein zweites Mal verarbeitet, was zu doppelten Daten führt.
Um dieses Problem bei der Konfiguration von nicht transaktionsorientierten Collaborations zu verhindern, können Sie das Markierungsfeld Serviceaufruf in Übergangsstatus bestehen lassen markieren. Auf diese Weise bleiben alle Geschäftsobjektanforderungen, die beim Auftreten des Fehlers auf dem Weg zu Zielanwendungen waren, in InterChange Server bestehen. Die Anforderungen werden nicht gesendet, wenn das System wiederhergestellt wird. Dies verringert das Risiko, dass eine Anforderung in der Zielanwendung doppelt verarbeitet wird. Anschließend können Sie die Anforderungen mit Flow Manager untersuchen und die Zielanwendungen überprüfen, um festzustellen, ob die Anforderungen erfolgreich verarbeitet wurden, bevor der Fehler aufgetreten ist. Löschen Sie alle Anforderungen, die bereits erfolgreich verarbeitet wurden, und wiederholen Sie alle noch nicht verarbeiteten Anforderungen.
Es gibt auch Maßnahmen der Programmierung, mit denen diese übertragungsbezogenen Probleme verarbeitet werden können. Weitere Informationen finden Sie im Collaboration Development Guide in den Anweisungen zum Verarbeiten von Ausnahmebedingungen beim Übertragen der Serviceaufrufe.
In früheren Releases wurden bei einem schwer wiegenden Systemfehler alle zum Zeitpunkt des Fehlers verarbeiteten Abläufe wiederhergestellt, wenn das System neu gestartet wurde. Diese Abläufe wurden alle aus dem persistenten Speicher gelesen und erneut an die Verarbeitung übergeben. Waren viele dieser Abläufe vorhanden, konnte es vorkommen, dass der Systemspeicher durch das Abrufen der Ereignisse in den Speicher vollständig belegt wurde. Dies konnte möglicherweise zu einem weiteren schwer wiegenden Fehler aufgrund von fehlendem Systemspeicher führen. Darüber hinaus war es unmöglich, das System effizient mit Tools zu verwalten, bis InterChange Server die Wiederherstellungsverarbeitung abgeschlossen hat.
Ab Release 4.0.0 ist es möglich, die Wiederherstellung für ein Collaboration-Objekt zurückzustellen, indem im Dropdown-Menü Wiederherstellungsmodus der Wert Verzögert ausgewählt wird. Wird ein Collaboration-Objekt auf diese Weise für die verzögerte Wiederherstellung konfiguriert, werden alle Abläufe, die zum Zeitpunkt eines schwer wiegenden Systemfehlers aktiv waren, wie fehlgeschlagene Abläufe behandelt und nicht sofort wiederhergestellt, wenn das System neu gestartet wird. Der Administrator kann dann Flow Manager verwenden, um die Abläufe neu zu übergeben, nachdem das System neu gestartet wurde und alle erforderlichen administrativen Aktionen vor der Wiederherstellung ausgeführt wurden.
In Release 4.2.0. ist die verzögerte Wiederherstellung weniger kritisch, da optimierte Wiederherstellungsverfahren implementiert wurden. Anstatt die gesamten Geschäftsobjektdaten für in der Ausführung befindliche Transaktionen in den Speicher zu lesen, liest der Server nur so viele Informationen in den Speicher, wie erforderlich sind, um das Geschäftsobjekt im persistenten Speicher zu lokalisieren. Obwohl die verzögerte Wiederherstellung weiterhin verfügbar ist, ist sie möglicherweise wegen des neuen, optimierten Wiederherstellungsverfahrens nicht erforderlich.
Wenn die Collaboration-Schablone, auf der das momentan konfigurierte Collaboration-Objekt basiert, transaktionsorientierte Datenbanklogik implementiert, müssen Sie das Collaboration-Objekt für implizite oder explizite Transaktionsklammerung konfigurieren. Wurde die Collaboration so entwickelt, dass die Transaktionssemantik explizit von dem vom Entwickler geschriebenen Code verarbeitet wird, sollten Sie das Markierungsfeld Implizite Datenbanktransaktion nicht auswählen. Wurde die Transaktion jedoch nicht mit expliziter Verwaltung der Datenbanktransaktionen entwickelt, sollten Sie das Markierungsfeld Implizite Datenbanktransaktion auswählen.
Weitere Informationen zur impliziten und expliziten Transaktionsklammerung finden Sie im Collaboration Development Guide.
Geschäftsobjekte, die von InterChange Server empfangen werden, werden bis zu ihrer Verarbeitung in die Warteschlange im Speicher eingereiht. In Releases vor 4.2.0 bestand bei Schnittstellen mit einer großen Anzahl von Transaktionen und einer niedrigen Verarbeitungsgeschwindigkeit die Gefahr, dass so viele Geschäftsobjekte in die Warteschlange eingereiht wurden, dass in InterChange Server schwer wiegende Fehler aufgrund von fehlendem Speicherplatz auftraten.
Sie können das Risiko solcher Fehler verringern, indem Sie für ein Collaboration-Objekt eine maximale Ereigniskapazität konfigurieren. Geben Sie hierzu im Feld Max. Ereigniskapazität einen Wert ein, der die maximale Anzahl an Ereignissen angibt, die für dieses Collaboration-Objekt in der Warteschlange stehen dürfen. Das System reiht daraufhin höchstens so viele Ereignisse in die Warteschlange ein, wie in dieser Eigenschaft angegeben wurden. Abhängig von der Konfiguration der Eigenschaft "Blockungstyp" für das Collaboration-Objekt reagiert das System unterschiedlich, wenn neue Geschäftsobjekte für die Collaboration empfangen werden.
Der gültige Wertebereich für diese Eigenschaft liegt zwischen 1 und 2147483647.
Weitere Informationen zur Eigenschaft Blockungstyp finden Sie im Abschnitt zum Blockungstyp.
Weitere Informationen zu den Eigenschaften der Ablaufsteuerung von Connectordefinitionen und zum Ändern der Connectordefinitionen mit Hilfe von Connector Configurator finden Sie im Abschnitt "Connectors konfigurieren".
Weitere Informationen zu Systemeigenschaften, die die Ablaufsteuerung betreffen, finden Sie in der Dokumentation "System Administration Guide".
Verwenden Sie die Eigenschaft Blockungstyp zusammen mit der Eigenschaft Maximale Ereigniskapazität, um den Ablauf der Geschäftsobjekte in einer Collaboration zu steuern.
Wenn Sie bei der Konfiguration eines Collaboration-Objekts das Markierungsfeld Blockungstyp aktivieren und die Anzahl der Collaboration-Ereignisse in der Warteschlange im Speicher den in der Eigenschaft Maximale Ereigniskapazität festgelegten Wert erreicht, setzt der Connector-Controller, der für das Senden von Geschäftsobjekten an die Collaboration verantwortlich ist, das Senden dieser Geschäftsobjekte aus. Fällt die Anzahl der Ereignisse in der Warteschlange der Collaboration wieder unter den in der Eigenschaft Maximale Ereigniskapazität angegeben Wert, nimmt der Connector-Controller das Senden von Ereignissen an die Collaboration wieder auf.
Wenn Sie dagegen das Markierungsfeld Blockungstyp bei der Konfiguration eines Collaboration-Objekts inaktiviert lassen und die Anzahl der Collaboration-Ereignisse in der Warteschlange im Speicher den in der Eigenschaft Maximale Ereigniskapazität festgelegten Wert erreicht, werden neue Ereignisse, die vom Connector-Controller an die Collaboration übergeben werden, persistent in der Datenbank gespeichert. In diesem Fall werden die Ereignisse aus der Datenbank in den Speicher gelesen, sobald die momentan in der Warteschlange der Collaboration befindlichen Ereignisse verarbeitet werden.
Weitere Informationen zur Eigenschaft Maximale Ereigniskapazität finden sie im Abschnitt "Maximale Ereigniskapazität".
Weitere Informationen zu Systemeigenschaften, die die Ablaufsteuerung betreffen, finden Sie in der Dokumentation "System Administration Guide".
Mit der Ereignisisolierung wird sichergestellt, dass zwei Collaborations nicht gleichzeitig mit denselben Daten arbeiten. Gelegentlich verarbeiten mehrere Collaborations dieselben Geschäftsobjekttypen. Ein Ereignis wird empfangen und löst eine bestimmte Collaboration aus. Diese Collaboration wird ausgeführt; während der Ausführung hat sie alleinigen Zugriff auf diese Geschäftsobjektinstanz in InterChange Server. Wenn ein weiteres Ereignis zu denselben Daten empfangen wird, stellt InterChange Server das neu empfangene Ereignis in eine Warteschlange, bis die ausführende Collaboration die Verarbeitung des ersten Ereignisses beendet hat.
Das Markierungsfeld Ereignisisolierung ist standardmäßig aktiviert. Einstellungen können bei der Ausführung geändert werden; allerdings sind die aktualisierten Eigenschaften nur für neue, noch nicht verarbeitete Ereignisse gültig, z. B. Ereignisse, die sich immer noch in MQ oder WIPQ befinden. Für diese bereits verarbeiteten Ereignisse, wird der neue Wert nicht angewendet.
Die Ereignisisolierung bezieht mehrere Collaboration-Objekte ein; wenn die Ereignisisolierung für eines inaktiviert ist, wird die Ereignisisolierung für weitere Objekte nicht ordnungsgemäß ausgeführt. Damit die Ereignisisolierung gültig ist, muss sie für alle Collaboration-Objekte mit derselben Quelle, denselben Zielconnectors und denselben Geschäftsobjektverweisen aktiviert werden.