Posts mit dem Label Governance werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Governance werden angezeigt. Alle Posts anzeigen
Montag, 3. Juni 2013
Oracle Business Transaction Management Handson Workshop
Der folgende Handson-Workshop gibt eine Einführung in das Oracle Business Transaction Management (OBTM). Er baut auf den vorhergehenden Workshops auf, so dass Standardtägigkeiten wie die Installation des WebLogic Servers und das anlegen einer Domain hier nicht mehr detailiert beschrieben werden. Erwähnt werden dann lediglich ggf. spezielle Konfigurations-Optionen.
OBTM: Alerting
OBTM verfügt über einen Alerting-Mechanismus um bestimmte Zustände automatisch zu erkennen. Dabei kann es sich z.B. um Fehler-Zustände oder SLA-Verletzung handeln, aber auch dass z.B. eine Nachricht mit einem bestimmten Inhalt verschickt wurde.
SLA Monitoring
Um eine SLA-Policy zu erstellen, wird zunächst die betreffende Transaktion ausgewählt.
Über den Menüpunkt 'SLA Policy|Transaction SLA' wird die Policy erstellt. Hierbei kann gewählt werden ob ein absoluter Wert, ein Wert relativ zum Durchschnitt eines Zeitraums oder eine mandantenbezogene Erfassung als Grundlage genommen wird. Für dieses Tutorial wird der Fixed Value ausgewählt.
In dem sich öffnenden Dialog kann die SLA-Policy definiert werden. Neben dem Zeitfenster können über den Button 'Choose Instruments' die Metriken festgelegt werden.
In dem sich neu öffnenden Dialog kann jetzt auch einer Menge von Metriken ausgewählt werden. Für dieses Beispiel wird 'Max Response Time' gewählt, beenden mit OK.
Die ausgewählte Metrik wird automatisch übernommen und kann jetzt konfiguriert werden. Für dieses Tutorial nehmen wir 500ms als Schwellwert für die Warnung und 1000ms als Schwellwert für den Fehlerfall. Beenden mit 'Apply'.
Die neue SLA Policy wird nun auch im Explorer unter 'SLA Policies' angezeigt.
Jetzt wird wieder ein wenig Last benötigt, daher wird der HelloProxy wieder ein paar Mal aus dem Weblogic Test Client aufgerufen.
Wenn die Transaktion etwas länger nicht benutzt wurde ist die Wahrscheinlichkeit sehr groß, dass zumindest der erste Aufruf länger dauert als in der SLA Policy festgelegt wurde. Dadurch sollte in der Operational Health Summary unter SLA Alerts jetzt etwas angezeigt werden. Falls nicht, kann die Policy auch nachträglich geändert werden. Wenn die Werte klein genug gesetzt werden, wird auch mindestens eine Warning angezeigt. Per Klick auf die Zahl hinter Warnings öffnet sich ein kleines Popup-Fenster, welches anzeigt gegen welche SLA Policy hier verstoßen wurde.
Per Klick auf das Lupensymbol lassen sich weitere Details anzeigen.
Es öffnet sich ein Detailfenster zur verletzten SLA-Policy mit einer Beschreibung. Über den Button 'Open Message Log' lassen sich die betreffenden Messages anzeigen.
Es öffnet sich eine neues Fenster mit dem Message Log. Hier lassen sich auch die beiden Nachrichten, welche die SLA-Verletzung hervorgerufen hatten, finden.
Eine weitere Stelle, an der die SLA-Alerts zu finden sind, ist direkt bei den Eigenschaften der Transaktion auf dem Reiter SLA Compliance. Per Klick auf das Lupensymbol lassen sie die Werte und Grenzwerte auch grafisch darstellen.
Condition Alerts
OBTM kann nicht nur auf Fehlerzustände monitoren, sondern auch auf Nachrichteninhalte, z.B. um bei Aufträgen in besondere Höhe eine Information zu liefern.
Eingeschaltet wird diese Möglichkeit in den Eigenschaften der Transaktion auf dem Reiter Conditions. Standardmässig ist diese ausgeschaltet, zum Einschalten den 'Edit'-Button klicken.
In dem sich öffnenden Popup-Window wird das Monitoring aktiviert, bestätigen mit Apply
Jetzt kann eine neue Bedinung erfasst werden via 'Transaction Condition|Content Condition for Greeting'
In dem sich neu öffnenden Dialog kann jetzt ein Kriterium erfasst werden, z.B. Name (die bereits bestehende Property) = 'Wichtigmann'. Beenden mit Apply.
Jetzt wird mit dem Weblogic Test Client und dem richtigen Parameter (Wichtigmann) wieder etwas Last gemacht.
Danach wird bei der Transaction auf dem Reiter Conditions unter Condition Alerts die Anzahl der entsprechenden Nachrichten angezeigt.
Auch in der Operational Health Summary werden die Condition Alerts angezeigt. Per Klick auf die Anzahl wird angezeigt, welche Conditions erfüllt wurden.
Damit ist das Handson Tutorial zum Oracle Business Transaction Management abgeschlossen.
---
Freitag, 31. Mai 2013
OBTM: Mandantenfähigkeit konfigurieren
Da Dienste im Unternehmen hoffentlich Abteilungs- oder Bereichsübergreifend eingesetzt werden, macht es Sinn das Monitoring mandantenfähig aufzusetzen. Dieses wird in OBTM durch die sog. Consumers umgesetzt. Letztendlich werden Consumers durch speziell gekennzeichnete Properties unterschieden.
Um die Mandantenfähigkeit zu aktivieren, wird also zunächst für einen Service eine neue Property angelegt über 'Create|Message Property on sayHello'
Dann wieder 'Pick from Message...' auswählen...
... und in dem sich öffnenden Dialog wieder arg0 auswählen. Beenden mit OK.
Dann wird der Haken gesetzt bei 'Map to customer through attribute'. Damit wird OBTM mitgeteilt, dass es sich um eine spezielle Property handelt, welchen den Consumer beinhaltet. Beenden mit OK.
Auch diese Property wird mit der bereits bestehenden 'Name'-Property im Properties-Tab dargestellt. Durch das Personen-Symbol vor der Property wird gekennzeichnet, dass es sich hierbei um einen Property handelt die einen Consumer identifiziert.
Ebenso wird die Consumer-Property im Properties-Tab der Transaction angezeigt.
Damit die Consumer-Property für die Greeting-Transaktion auch greift, muss in den Einstellungen der Transaction (Modify|Edit Greeting) auf dem Tab 'Segmentation' noch der Haken bei 'Enable consumer segmentation' gesetzt werden.
Um die Consumer jetzt zu erfassen, starten wir wieder den WebLogic Test Client und rufen den HelloProxy-Service ein paar Mal jeweils mit 'Bereich-1' und 'Bereich-2' auf.
Die Segmentierung der Transaktion nach Consumer lässt sich dann auf dem Tab Analysis, sub-Tab Consumer Usage anzeigen. Die 'Unknown'-Einträge sind alte Einträge aus der Zeit bevor die Segmentierung eingeschaltet war.
Auch im Bereich Consumers werden nach kurzer Zeit die beiden Bereiche angezeigt (ggf. ca. 5min. warten). Dabei werden für die beiden Mandanten unterschiedliche Laufzeiten für die Services angezeigt, nämlich für jeden Mandanten die bei der Bearbeitung seiner spezifischen Anfragen angefallenen Werte.
Verursacht man absichtlich eine Störung, z.B. indem man den SOA-Server herunterfährt und startet während der Downtime nur Anfragen für einen Mandanten (z.B. Bereich-1), dann wird auch nur für diesen das Problem angezeigt. Im Bild oben sieht man, dass die Kurven für gestartete und erfolgreich abgeschlossene Transaktionen deutlich auseinander gehen. Startet man während der Downtime keine Transaktionen für den anderen Mandanten, wird diesem auch kein Problem angezeigt.
Somit lassen sich über das Consumers-Feature von OBTM auch mandantenspezifische Auswertungen durchführen.
---> Alerting
Um die Mandantenfähigkeit zu aktivieren, wird also zunächst für einen Service eine neue Property angelegt über 'Create|Message Property on sayHello'
Dann wieder 'Pick from Message...' auswählen...
... und in dem sich öffnenden Dialog wieder arg0 auswählen. Beenden mit OK.
Dann wird der Haken gesetzt bei 'Map to customer through attribute'. Damit wird OBTM mitgeteilt, dass es sich um eine spezielle Property handelt, welchen den Consumer beinhaltet. Beenden mit OK.
Auch diese Property wird mit der bereits bestehenden 'Name'-Property im Properties-Tab dargestellt. Durch das Personen-Symbol vor der Property wird gekennzeichnet, dass es sich hierbei um einen Property handelt die einen Consumer identifiziert.
Ebenso wird die Consumer-Property im Properties-Tab der Transaction angezeigt.
Damit die Consumer-Property für die Greeting-Transaktion auch greift, muss in den Einstellungen der Transaction (Modify|Edit Greeting) auf dem Tab 'Segmentation' noch der Haken bei 'Enable consumer segmentation' gesetzt werden.
Um die Consumer jetzt zu erfassen, starten wir wieder den WebLogic Test Client und rufen den HelloProxy-Service ein paar Mal jeweils mit 'Bereich-1' und 'Bereich-2' auf.
Die Segmentierung der Transaktion nach Consumer lässt sich dann auf dem Tab Analysis, sub-Tab Consumer Usage anzeigen. Die 'Unknown'-Einträge sind alte Einträge aus der Zeit bevor die Segmentierung eingeschaltet war.
Auch im Bereich Consumers werden nach kurzer Zeit die beiden Bereiche angezeigt (ggf. ca. 5min. warten). Dabei werden für die beiden Mandanten unterschiedliche Laufzeiten für die Services angezeigt, nämlich für jeden Mandanten die bei der Bearbeitung seiner spezifischen Anfragen angefallenen Werte.
Verursacht man absichtlich eine Störung, z.B. indem man den SOA-Server herunterfährt und startet während der Downtime nur Anfragen für einen Mandanten (z.B. Bereich-1), dann wird auch nur für diesen das Problem angezeigt. Im Bild oben sieht man, dass die Kurven für gestartete und erfolgreich abgeschlossene Transaktionen deutlich auseinander gehen. Startet man während der Downtime keine Transaktionen für den anderen Mandanten, wird diesem auch kein Problem angezeigt.
Somit lassen sich über das Consumers-Feature von OBTM auch mandantenspezifische Auswertungen durchführen.
---> Alerting
Mittwoch, 15. Mai 2013
OBTM: Arbeiten mit Properties
Properties dienen hauptsächlich dazu, um bestimmte Eigenschaften einer Transaktion hervorzuheben. So kann z.B. bei einer Bestellung schnell die Kunden- oder Auftragsnummer eingesehen werden, ohne dass die kompletten SOAP-Nachrichten untersucht werden müssen.
Dadurch, dass wir bei der Erstellung der Business Transaction gleich eine Property mit angelegt haben, kann diese auch im folgenden Beispiel direkt benutzt werden.
Sofern noch keine Property angelegt wurde, kann dies auch einfach nachgeholt werden, indem man in einer beliebigen Darstellung einen Service auswählt und dann 'Create|Message Property on ...' auswählt.
Für die folgende Übung sollte der HelloProxy Service ein paar Mal mit unterschiedlichen Parametern aufgerufen werden.
Die Properties werden dann z.B. angezeigt bei der Transaktion unter Instances.
Auch im Message Log werden die Properties in separaten Spalten aufgeführt. Über den 'Choose Content...'-Link kann die Ausgabe gefiltert werden.
Die Auswahlbox hinter 'Name' wird auf 'matching' gestellt.
Dann wird ein Suchtext eingegeben, weiter mit OK.
Dann auf 'Search' klicken (und auf den Zeitrahmen links) achten, und es werden nur noch Einträge im Message Log angezeigt, die dem Suchbegriff entsprechen.
Eine weitere Möglichkeit, die Nachrichten zu durchsuchen, bietet der Menüpunkt 'View|Search Message Log'.
In einem separaten Fenster öffnet sich das Search Message Log Tool. Hier kann die Suche wieder über den 'Choose Content ...'-Link eingegrenzt werden.
Mit entsprechender Eingrenzung werden wieder nur die Messages angezeigt, bei denen ein Property einen bestimmten Wert enthält, in diesem Fall Name=Arne. In der Detail Pane werden hier zusätzlich die Details der jeweiligen Nachricht angezeigt.
Der 'View XML'-Link macht genau das: das Ergebnis in XML anzeigen.
Die Properties können also genutzt werden, um die für den jeweiligen Anwender relevanten Informationen hervorzuheben. In Real-World Szenarien wären das z.B. Kunden-, Auftrags- oder Vorgangsnummern, auf die schnell zugegriffen werden kann ohne dass die kompletten Nachrichten untersucht werden.
Ruft beispielsweise ein Kunde im Call-Center an und fragt nach seiner Bestellung, kann auf diese Weise schnell herausgefunden werden, ob die Verarbeitung des Auftrags mit der entsprechenden Nummer irgendwo hängt.
---> Mandantenfähigkeit konfigurieren
---> Mandantenfähigkeit konfigurieren
Montag, 13. Mai 2013
OBTM: Business Transaction definieren
Nachdem nun das Setup des Szenarios abgeschlossen ist, kann eine erste Business-Transaction definiert werden. Hierzu wird wieder die BTMUI gestartet.
Unter dem Menüpunkt 'Create' geht es los mit 'Transaction'
Jetzt muss eine Operation gewählt werden, mit der die Transaktion startet. In diesem Fall wird sayHello unter sayHelloProxyService ausgewählt.
Die weiteren Operationen werden aufgrund der bereits erfolgten Discovery automatisch gefunden.
Das Instance- und Message Logging wird auf dem Tab 'Logging' eingeschaltet. Für das Message Logging müssen unten die Operationen ausgewählt werden.
Anstelle von 'Pick from Message...' wird nun request.sayHello.arg0 angezeigt. Die Property bekommt noch einen Namen wie hier z.B. 'Name'. Dann den Dialog mit OK schliessen.
Der Vorgang wird für alle vier Keys wiederholt. Beim Start key von bpelprocess1_client_ep.process wird 'Name' bereits als Alternative angeboten und kann direkt ausgewählt werden.
Auf dem letzten Tab sind die Speicher-Einstellungen. Hier sollte der Haken 'Text index message content' per default gesetzt sein. Der Dialog wird mit OK geschlossen.
Die neue Transaction wird nun unter Transactions angezeigt. Weiter geht es in der WLS Console der Domain, in welcher der sayHelloProxyService läuft.
Wie im vorherigen Kapitel wird der Service jetzt wieder mehrfach ausgeführt. Dann geht es wieder zurück in die BTM UI.
Unter Transactions werden jetzt die ermittelten Informationen angezeigt. Über das Plus (+) vor Greeting werden die beteiligten Operations angezeigt. Im Detail-Fenster wird unten das Transaction Summary Dashboard angezeigt. In der schematischen Darstellung werden jetzt auch die durchschnittlichen Antwortzeiten dargestellt.
Im Tab 'Analysis' werden weitere Informationen angezeigt wie Started Transactions sowie Max und Average Response Time.
Unter 'Instances' werden - je nach Filter - die bisherigen Instanzen angezeigt. Per Klick auf eine eine Instanz öffnet sich das Fenster mit den protokollierten Messages.
Neben einer schematischen Darstellung der Transaction werden hier alle protokollierten Messages aufgeführt. Per Klick auf das Lupensymbol links lassen sich diese anzeigen.
In einem neuen Fenster wird die gespeicherte Nachricht angezeigt. Über einen der beiden 'View XML'-Links lässt sich die jeweilige Nachricht vollständig anzeigen.
Die Nachricht wird in einem neuen Browser-Fenster geöffnet. Anschliessend können die beiden extra-Fenster wieder geschlossen werden, so dass nur noch die BTM-UI geöffnet ist.
Die Messages können auch über den Tab 'Message Log' eingesehen werden.
Im Tab 'Properties' werden alle definierten Properties angezeigt.
Damit ist die erste Business Transaction definiert und kann im weiteren genutzt werden.
Unter dem Menüpunkt 'Create' geht es los mit 'Transaction'
Jetzt muss eine Operation gewählt werden, mit der die Transaktion startet. In diesem Fall wird sayHello unter sayHelloProxyService ausgewählt.
Die weiteren Operationen werden aufgrund der bereits erfolgten Discovery automatisch gefunden.
Das Instance- und Message Logging wird auf dem Tab 'Logging' eingeschaltet. Für das Message Logging müssen unten die Operationen ausgewählt werden.
Auf dem Tab 'Message Keys' können noch die Properties definiert werden. Properties werden auch protokolliert, wenn nicht die gesamte Nachricht abgespeichert wird.
Hierzu wird das Dropdown Menu mit dem Titel 'Message Fingerprint' aufgeklappt und 'New Property...' ausgewählt.
In den sich öffnenden Dialog gibt es mehrere Möglichkeiten, die Property zu definieren. In diesem Beispiel geht es weiter via 'Pick from Message...'.
Die Auswahl fällt in diesem Fall leicht, arg0 auswählen und weiter mit OK.
Anstelle von 'Pick from Message...' wird nun request.sayHello.arg0 angezeigt. Die Property bekommt noch einen Namen wie hier z.B. 'Name'. Dann den Dialog mit OK schliessen.
Der Vorgang wird für alle vier Keys wiederholt. Beim Start key von bpelprocess1_client_ep.process wird 'Name' bereits als Alternative angeboten und kann direkt ausgewählt werden.
Auf dem letzten Tab sind die Speicher-Einstellungen. Hier sollte der Haken 'Text index message content' per default gesetzt sein. Der Dialog wird mit OK geschlossen.
Die neue Transaction wird nun unter Transactions angezeigt. Weiter geht es in der WLS Console der Domain, in welcher der sayHelloProxyService läuft.
Wie im vorherigen Kapitel wird der Service jetzt wieder mehrfach ausgeführt. Dann geht es wieder zurück in die BTM UI.
Unter Transactions werden jetzt die ermittelten Informationen angezeigt. Über das Plus (+) vor Greeting werden die beteiligten Operations angezeigt. Im Detail-Fenster wird unten das Transaction Summary Dashboard angezeigt. In der schematischen Darstellung werden jetzt auch die durchschnittlichen Antwortzeiten dargestellt.
Im Tab 'Analysis' werden weitere Informationen angezeigt wie Started Transactions sowie Max und Average Response Time.
Unter 'Instances' werden - je nach Filter - die bisherigen Instanzen angezeigt. Per Klick auf eine eine Instanz öffnet sich das Fenster mit den protokollierten Messages.
Neben einer schematischen Darstellung der Transaction werden hier alle protokollierten Messages aufgeführt. Per Klick auf das Lupensymbol links lassen sich diese anzeigen.
In einem neuen Fenster wird die gespeicherte Nachricht angezeigt. Über einen der beiden 'View XML'-Links lässt sich die jeweilige Nachricht vollständig anzeigen.
Die Nachricht wird in einem neuen Browser-Fenster geöffnet. Anschliessend können die beiden extra-Fenster wieder geschlossen werden, so dass nur noch die BTM-UI geöffnet ist.
Die Messages können auch über den Tab 'Message Log' eingesehen werden.
Im Tab 'Properties' werden alle definierten Properties angezeigt.
Damit ist die erste Business Transaction definiert und kann im weiteren genutzt werden.
Abonnieren
Posts (Atom)

























































