Posts mit dem Label Tip werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Tip werden angezeigt. Alle Posts anzeigen

Dienstag, 17. November 2015

OSB 12c: Einfaches Tutorial mit Throttling

Im folgenden ein einfaches Tutorial, um einen simplen SOAP-Service durch den OSB zu routen und dafür ein Throttling zu konfigurieren.

Hierfür benötigen wir einen simplen SOAP Service wie den HelloWorld-Service aus dem OBTM-Tutorial.


In der WebLogic Console, auf der der Service läuft, bekommen wir die WSDL URL.


Ein Klick auf den Link öffnet die WSDL in einem neuen Tab. Diese WSDL wird lokal im Dateisystem abgespeichert, ebenso die verlinkte XSD Datei geöffnet.


Weiter geht es in der Service Bus Console, in der ein neues Projekt 'Throttling' angelegt wird. Nicht notwendig, aber zur Übersicht empfehlenswert sollten noch zwei Ordner WSDL und XSD angelegt werden.


Im XSD-Projekt wird dann ein neues Schema angelegt.


Hier einen Namen vergeben und die gespeicherte Datei auswählen.






Auf die gleiche Art wird die WSDL im entsprechenden Ordner angelegt.


Jetzt wird noch ein Fehler angezeigt, weil die WSDL ja noch das externe XSD referenziert. Um das zu korrigieren, auf den View/Edit Button klicken.


Die Zeile

<xsd:import namespace="http://helloservice/" schemaLocation="http://192.168.56.101:7007/HelloServiceApp-HelloService-context-root/HelloWorldServicePort?xsd=1"/>

muss geändert werden auf

<xsd:import namespace="http://helloservice/" schemaLocation="../XSD/HelloXSD.xsd"/>

damit statt dessen die im OSB hinterlegte XSD referenziert wird.


Jetzt kann damit ein neuer Business Service erstellt werden.



Hier wird die eben angelegte WSDL ausgewählt. Weiter mit 'Next' und auf der nächsten Seite mit 'Create' abschließen.


Dann ein Mal mit 'Activate' die Session abschließen und Per 'Launch Test Console' den Business Service testen.


Wenn bis hier alles geklappt hat, sollte die richtige Antwort zurück kommen.


Mit dem 'Create'-Button dann wieder eine neue Session anfordern und im 'Throttling'-Ordner eine Pipeline erstellen. WSDL Based Servivce auswählen, die eben angelegte WSDL auswählen und 'Expose as Proxy Service' auswählen, ggf. noch den Namen ändern.


Damit die Pipeline jetzt auch mit dem Business Service spricht, muss die Pipeline geöffnet und geändert werden.

Im Flow-Editor wird per Klick auf die Pipe eine Route hinzugefügt.

Dann per Klick auf die Route das Menü aufrufen und 'Edit Route' auswählen.

Dann Klick auf 'Add an Action' und Communication|Routing auswählen.

Dort den Service und die Operation auswählen. Dann beide Dialoge mit 'Save' verlassen.


Dann die Session aktivieren und noch einmal die Test Console aufrufen, dieses Mal für den Proxy Service.


Wenn alles geklappt hat, geht es weiter im Fusion Middleware Control. Dort navigiert man unter SOA|service-bus in das Throttling Projekt. Auf der Seite 'Operations' geht es denn weiter per Klick auf den Business Service.


Hier können unter Properties die Parameter für das Throttling eingestellt werden. Über den Test-Knopf oben kann der Service gleich mit Throtting getestet werden. Weitere Informationen zum Throttling gibt es in der Dokumentation.

Donnerstag, 30. Januar 2014

Handson: Basic Authentication zwischen OSB und SOA-Suite (Teil 2)

Im zweiten Teil soll der via Basic Authentication geschützte ProxyService aus der SOA-Suite genutzt werden. Hierzu wird zunächst der Zugriff auf den Service getestet.


Die URL für Service bekommt man in der Übersicht zum Proxy Service unter Endpoint URI, davor kommen nur noch Hostname und Port des OSB Servers. Also in diesem Fall

oel6ab:8011/Basic-Auth/Proxy_Services/HelloService-PS


Zum Testen gibt man diese URL in einen Web Browser auf dem aufrufenden System ein, gefolgt von ?WSDL, also in diesem Beispiel

oel6ab:8011/Basic-Auth/Proxy_Services/HelloService-PS?WSDL

Da der Service per Basic Authentication abgesichert ist, erscheint die Eingabeaufforderung für Benutzername/Password. Hier kann z.B. der weblogic User genommen werden.


Wenn bis hier alles geklappt hat, wird die WSDL angezeigt. Diese bitte lokal speichern, dabei auf die Dateiendung achten.


Weiter geht es im JDeveloper. Hier wird zunächst eine neue Anwendung mit 'New Application' angelegt, als Typ SOA Application ausgewählt und weiter mit 'Next'.


Wahlweise kann das Projekt einen Namen bekommen, z.B. SoaProject1. Weiter mit 'Next'.


Defaults belassen, weiter mit 'Next'


'Empty Composite' auswählen und abschliessen mit 'Finish'


Als Ergebnis gibt es eine Application mit einem Projekt für das SOA Composite. Bevor dieses jetzt mit Leben gefüllt wird, wird noch ein weiteres Projekt zum Testen des Services benötigt. Dieses wird angelegt mit 'New Projekt...'.


Das 'Generic Project' reicht aus, abschließen mit 'OK'


Namen vergeben, Web Services als Technologie auswählen und gleich abschließen mit 'Finish'


Per Rechtsklick auf das Projekt und Auswahl von 'New...' wird die New-Gallery aufrufen.


Hier 'Java Web Service from WSDL' auswählen und weiter mit 'OK'


Es erscheint der 'Create Java Web Service from WSDL' Wizard, gleich weiter mit 'Next'.


Default belassen und weiter mit 'Next'.


Hier die URL der WSDL eingeben wie oben im Browser, dann weiter mit 'Next'


Hier noch einmal Benutzername und Password eingeben, weiter mit 'OK'


Dann noch einen Namen vergeben und abschliessen mit 'Finish'


Die WSDL wird schematisch angezeigt. Zum Testen des Web Service auf den grünen Pfeil klicken.


Der 'HTTP Analyzer' wird geöffnet, hier kann eine Payload eingegeben werden und mit 'Send Request' der Web Service damit aufgerufen werden.


Es gibt einen 'Error 401 -- Unauthorized' weil der Service eine Autorisierung erfordert.


Die Basic Authentication ist Bestandteil des HTTP-Protokolls, sie muss entsprechend im HTTP-Header berücksichtig werden. Hierzu wird per kleinem Plus [+] Symbol links der HTTP-Header aufgeklappt, mit dem großen grünen Plus rechts das Menü geöffnet und 'Authorization Basic' ausgewählt.


In der neuen Headerzeile nach Doppelklick Benutzername und Password eintragen, danach wieder via 'Send Request' den Aufruf neu starten.


Mit der richtigen Authentifizierung ist der Aufruf dann auch erfolgreich. Damit konnte in diesem Abschnitt der Proxy Service aus dem letzten Teil erfolgreich im JDeveloper mit Basic Authentication aufgerufen werden. Im nächsten Schritt wird der Proxy Service dann aus einem SOA Composite aufgerufen.

---> Weiter geht es in Teil 3

Montag, 14. Oktober 2013

VBox Images schrumpfen

Die Images von virtuellen Maschinen, wie z.B. die Virtual Box Images aus den Trainings auf dieser Seite, wachsen praktischerweise automatisch. Leider schrumpfen sie nie wieder von alleine, gerade wenn man viel herumprobiert kann das schnell viel Platz kosten. Hier eine Anleitung wie man die Image-Dateien wieder schrumpfen kann.


In diesem Beispiel ist das Image ca. 52 GB groß. Wichtig: das Schrumpfen funktioniert nur mit VDI-Dateien, VMDK Dateien müssen erst konvertiert werden mit VBoxManage clonehd, z.B.

d:\programme\Oracle\VirtualBox\VBoxManage.exe clonehd OEP-11.1.1.7-Klon-disk1.vmdk OEP-11.1.1.7-Klon-disk1.vdi --format VDI

Dann gilt es, so viel Platz wie möglich freizuschaffen. Alte Installationsdateien löschen, Datenbankfiles verkleinern (die Standardgrößen vom RCU sind viel zu groß für ein kleines Testsystem auf dem Entwicklerarbeitsplatz).
Danach muss der freie Speicherplatz mit Nullen überschrieben werden, sonst wird er von VBox nicht als frei erkannt. Das geht z.B. mit

dd if=/dev/zero of=zero.file
rm zero.file

Das Kommando bricht ab, sobald die Partition voll ist (Achtung: Benutzung auf eigene Gefahr, vorher Backup anlegen). Danach einfach das zero.file wieder löschen. Anschliessend die VBox herunterfahren, jetzt kann Virtual Box die Datei komprimieren mit

e:\VBox\Machines\OEP-11.1.1.7-Klon>d:\programme\Oracle\VirtualBox\VBoxManage.exe
modifyhd OEP-11.1.1.7-Klon-disk1.vdi --compact

Warten bis das Kommando bis 100% heraufzählt und das war es auch schon.


Bei meiner VM habe ich damit eine Reduktion von 52 GB auf 23 GB erreicht.

---8<------------------------------------------------------------------------------

UPDATE:
Ich bin von Lorenz Keller darauf hingewiesen worden, dass Mac Anwender beim Aufruf von VBoxManage den vollen Pfad zum VM-Image angeben müssen, ansonsten gibt es folgende Fehlermeldung:

$ VBoxManage modifyhd EM12cR4.vdi --compact
VBoxManage: error: Could not find file for the medium '/Volumes/Macintosh_HD/Users/oracle/EM12cR4.vdi' (VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component Medium, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 178 of file VBoxManageDisk.cpp

Richtig wäre

$ VBoxManage modifyhd /Volumes/Macintosh_SSD/Users/Shared/VirtualBox/EM12cR4/EM12cR4.vdi --compact

und schon klappt es auch mit dem Mac.

Freitag, 4. November 2011

Servlet für Clustering erstellen

Nachdem der vorige Betrag gezeigt hat, wie der WebLogic Cluster aufgesetzt wird, soll jetzt ein einfaches Servlet erstellt werden, um das Clustering zu demonstrieren. Das Servlet wurde bewusst simpel gestaltet um es nachvollziehbar zu machen. Für dieses Beispiel habe ich den JDeveloper 11.1.2.0.0 benutzt.


Eine neue Anwendung wird erstellt via 'New Application...'.


Hier wird die 'Custom Application' ausgewählt.


Die Anwendung benötigt einen Namen ...


... ebenso wie das Projekt. Bei den Technologien ist 'JSP and Servlets' auszuwählen, 'Java' wird dann automatisch mit ausgewählt.


Defaults belassen und 'Finish'.


Auf dem neu erzeugten Projekt per Rechtsklick 'New...' auswählen.


Dann Auswahl von 'Web Tier' -> 'Servlets' -> 'HTTP Servlet' und OK.

Next
Next
Next

Hier können noch die Namen für das Servlet und das URL Pattern geändert werden, z.B. in 'simple' und '/cluster'


Das Servlet benötigt keine Parameter, beenden mit 'Finish'.


Als Ergebnis liefert der JDeveloper ein fertiges Servlet wie oben abgebildet.

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType(CONTENT_TYPE);
        PrintWriter out = response.getWriter();
        
        HttpSession sess = request.getSession();
        Integer cnt = (Integer)sess.getAttribute("cnt");
        if(cnt==null)
            cnt=0;
                
        out.println("<html>");
        out.println("<head><title>Servlet1</title></head>");
        out.println("<body>");
        out.println("<p>The servlet has received a GET. This is the reply.</p>");
        out.println( new Date() );
        out.println( "<p>Bisherige Aufrufe: " + cnt + "</p>"  );
        out.println("</body></html>");
        out.close();
        
        System.out.println( new Date()+ ": doGet - bisherige Aufrufe: " + cnt );
        
        sess.setAttribute("cnt", ++cnt);
    }

Der Quellcode wird nun wie oben geändert. Hierdurch wird ein Zähler hinzugefügt und dieser vor jedem Aufruf aus der HttpSession gelesen, erhöht und zum Schluss wieder in die HttpSession geschrieben.


Die Klasse Date muss noch importiert werden. Der JDeveloper bietet freundlicherweise an, das zu erledigen. Einfach den Cursor auf der Klasse positionieren und Alt-Enter drücken.


In der daraufhin auftauchenden Auswahl bitte Date (java.util) auswählen, damit die richtige Klasse importiert wird.

Über den Run-Button kann das Servlet im internen WebLogic Server getestet werden.


Das Ergebnis sollte dann wie oben abgebildet aussehen.

Damit ist das Servlet selbst soweit fertig, im nächsten Schritt wird der Ablauf im Cluster gezeigt.