2013-12-13

Programmatic full-reset of adf input components contained in af:switcher

Task: Reset each and every input component on a page after some action took place.

Solution: First of all requery the data that is used inside the ui input components.

Then access the Faces Context and set the ViewRoot to a newly created UiView. This can be found in the utility Java Class JSFUtils provided by Duncan Mills and Steve Muench. As an excerpt:

    public static final void refreshCurrentPage() {
        FacesContext context = getFacesContext();
        String currentView = getRootViewId();
        ViewHandler vh = context.getApplication().getViewHandler();
        UIViewRoot x = vh.createView(context, currentView);
        x.setViewId(currentView);
        context.setViewRoot(x);
    }


Issue: This does not seem to refresh components, that are dynamically generated inside an af:switcher. After recursive logging of the components that are refreshed, it seems to be that the org.apache.myfaces.trinidad.component.UIXSwitcher children are not accessed.

Solution 2: I assume that internally the "refreshCurrentPage" uses the same functionality, that is used by the getChildren() method derived by the javax.faces.component.UIComponent class. Unfortunetaly this method returns null for the UIXSwitcher component. Therefore you should use the getFacetsAndChildren() method (which works for the UIXSwitcher since there are only facet subnodes) and write your own refresh code that could look something like this:

    private void resetValueInputItems(AdfFacesContext adfFacesContext,
                                      UIComponent component) {
                     
        Iterator<UIComponent> items = component.getFacetsAndChildren();
        while(items.hasNext()){
           
            UIComponent item = items.next();
           
            resetValueInputItems(adfFacesContext, item);

            if (item instanceof RichInputText) {
                RichInputText input = (RichInputText)item;
                if (!input.isDisabled()) {
                    input.resetValue();
                    adfFacesContext.addPartialTarget(input);
                }
            } else if (item instanceof RichInputDate) {
                RichInputDate input = (RichInputDate)item;
                if (!input.isDisabled()) {
                    input.resetValue();
                    adfFacesContext.addPartialTarget(input);
                }
            } else if (item instanceof RichSelectOneChoice){
                RichSelectOneChoice lov = (RichSelectOneChoice) item;
                if (!lov.isDisabled()) {
                    lov.resetValue();
                    adfFacesContext.addPartialTarget(lov);
                }
            }
        }
        AdfFacesContext.getCurrentInstance().addPartialTarget(component);
    }


Result: Each component resets its Value, even those that are contained inside a af:switcher component.

2013-11-25

Titel: Segen oder Fluch? – Oracle Trace- und Logdateien!

Trace- und Logdateien sind ein Segen, wenn man nach der Ursache für Probleme in Datenbank, Net Services, Applicationserver oder anderen Oracle Komponenten sucht. Sie können aber auch zum Fluch werden, wenn man sie gar nicht benötigt. Unablässig protokolliert die Oracle-Software alle Aktivitäten. Die Dateien füllen langsam und unmerklich den Plattenplatz. Und dann steht plötzlich die Datenbank wegen „no space left on device“ oder der Applicationserver hängt, weil die Logdatei zu groß geworden ist.
Mit Einführung des Automatic Diagnostic Repositories (ADR) für die Datenbanksysteme hat Oracle einen Anfang gemacht Log- und Tracedateien automatisch zu kürzen bzw. aufzuräumen.
Doch die Gefahr ist nicht gebannt: Längst nicht alle Logdateien werden zentral im ADR abgelegt. Auch an anderen Speicherorten finden sich Logdateien, die nicht durch Oracle Prozesse aufgeräumt werden. Und selbst im ADR bleiben einige Logdateien ungekürzt oder werden zu lange vorgehalten.

Ein einleitendes Manuskript ist zu finden unter: 2013-K-DB-Appelbaum-Segen oder Fluch-Oracle Log&Tracedateien -Manuskript.pdf

Im Vortrag auf der DOAG 2013 Konferenz habe ich aus unseren Erfahrungen im Rahmen unserer Oracle Administration Services wichtige Best Practices an die Hand dargestellt, wo welche Dateien zu finden sind und wie für diese Rotation und Löschen eingerichtet werden können.
Ich habe Trace- und Logdatein und ebenso die Auditdateien bei Datenbank, Listener, Grid/Cloud Control, Agent, Application-/Weblogicserver und bei anderen Oracle Komponenten betrachtet. Erforderliche Skripte habe ich sowohl für Unix/Linux als auch für Windows Installationen vorgestellt.

Die Präsentation ist zu finden unter: 2013-K-DB-Appelbaum-Segen oder Fluch-Oracle Log&Tracedateien-Präsentation.pdf

Bei Interesse an den Skripten können Sie mich gerne kontaktieren.

2013-11-18

Man trifft sich, auf der DOAG 2013 Konferenz

Die Oracle Community trifft sich und auch TEAM ist mit einem Stand und zwei Vorträgen wieder dabei! Besuchen Sie uns und lernen Sie das umfassende Consulting-Angebot von TEAM kennen. Es gibt jede Menge aktuelle Themenschwerpunkte, über die wir uns gerne mit Ihnen an unserem Stand 204 in der 2. Etage (gelb) unterhalten möchten!

Auch zum immer wieder brisanten Thema Lizenz-Compliance, dem sich die DOAG ganz aktuell mit einem digitalen Lizenzguide widmet, sind wir als offizieller Oracle LMS JPE Partner sicher ein qualifizierter Ansprechpartner. Als in Oracle LMS Audits erfahrener und von Oracle qualifizierter Mitarbeiter diskutiere ich, Ralf Appelbaum, gerne mit Ihnen an unserem Messestand als Hersteller unabhängiger Berater Ihre Vorbehalte zu diesem Thema.

Besuchen Sie TEAM bei folgenden, spannenden Vorträgen zum Stream - Middleware & SOA sowie Oracle Datenbank:

Migration auf Knopfdruck – Macht das überhaupt Sinn?
Donnerstag, 21. November 2013, um 12:00 Uhr im Raum 5
Referent: Markus Klenke, TEAM GmbH
Detail Informationen finden Sie hier.

Segen oder Fluch? – Oracle Trace- und Logdateien!
Donnerstag, 21. November 2013, um 10:00 Uhr im Raum 19
Referent: Ralf Appelbaum, TEAM GmbH
Detail-Informationen finden Sie hier.

Wer nicht recht weiß, welche Vorträge er auf der Doag 2013 sonst noch besuchen soll, nutze doch einfach den
iConfGuide von TEAM, der bringt den Überblick
Mit dem von TEAM auf Basis von Oracle ADF entwickelten iConfGuide stellen Sie ganz bequem aus 400 Vorträgen Ihr ganz persönliches Programm zusammen - und das auf Ihrem iPhone (optimiert) oder SmartPhone! Schauen Sie rein: iconfguide.doag.org

2013-10-10

Tooltips vom Converter bei ADF af:inputText Feldern unterdrücken

Eigentlich machen die Tooltips von Convertern auf Eingabefeldern ja durchaus Sinn, denn sie helfen dabei, mögliche Fehleingaben zu verhindern.
Wenn der Kunde aber wünscht "...bitte nicht anzeigen, die Benutzer wissen, was sie da eintragen..." ist uns das Befehl.

Dieses Posting im Oracle Forum zeigt den Weg, wie es auf af:inputDate Feldern mit dem automatisch gesetzten convertDateTime Converter funktioniert: https://forums.oracle.com/message/10101349#10101349

Das funktioniert analog natürlich auch z.B. für ein af:inputText Feld, auf dem ein Converter manuell eingestellt wurde!

1.) Javascript Funktion in den Code

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
          xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:c="http://java.sun.com/jsp/jstl/core">

  <af:resource type="javascript">
     function blockHint(event) {
        var source = event.getSource();
        source.getPeer().ShouldShowHint = function() {
            return false;
        }

     }
  </af:resource>

...

2.) Funktion innerhalb des af:inputText mit einem af:clientListener auf den Typ focus aufrufen lassen.

...
<af:inputText id="it6"
              simple="true"
              rows="1"
              columns="#{row.length.value}"
              maximumLength="#{row.length.value}"
              value="#{row.zahl}"
              contentStyle="text-align:right;">
   <af:clientListener method="blockHint"

                      type="focus"/>
   <f:convertNumber pattern="#"
                    type="number"/>
</af:inputText>

...

Fertig.

2013-07-11

JDeveloper 12c als public download verfügbar

Der JDeveloper und ADF haben den Sprung auf den 12c Layer von Oracle geschafft. Wie anzunehmen finden wir hier zu großen Teilen ein Versionsmerging von Release 1 und Release 2 des JDeveloper 11g, aber auch einige weitere Feinheiten.

Details sowie ein Download kann unter:

http://www.oracle.com/technetwork/developer-tools/jdev/documentation/1212-nf-1964675.html

gefunden werden.

Viel Spaß beim ausprobieren!

2013-05-15

Manuelles Standby Skripting: Data Guard für Arme?

Nein, es ist kein Data Guard, aber dessen Möglichkeiten sind auch nicht immer erforderlich. Zur reinen Absicherung einer Datenbank im Desasterfall ist eine selbst geskriptete Standby Datenbank oft ausreichend. Darüber hinaus erhält man damit die Möglichkeit Reporting in eine Read Only Datenbank auszulagern oder ein Testsystem kurzfristig mit den aktuellen Daten verfügbar zu haben.

Ja sicher ist damit ein enormer Kostenvorteil gegeben. Oracle Data Guard ist eine Option, die nur für die Enterprise Edition zur Verfügung steht. Aber wenn man nur den Desasterfall absichern möchte und ansonsten keinerlei Enterprise Edition Features benötigt, sind die Mehrkosten nicht gerechtfertigt.

Im Vortrag zeigte ich wie eine Standby Datenbank Konfiguration für eine Oracle 11gR2 Standard Edition (One) eingerichtet wird, welche Skripte erforderlich sind und was überwacht werden sollte. Dargestellt habe ich auch einige Unterschiede zu Konfigurationen zwischen Linux und Windows. Die Präsentation dazu ist zu finden als “Appelbaum-Data_Guard_für_Arme.pdf

Im Wesentlichen sind zwei Skripte beteiligt:

  1. Ein Script (stdby_sync.sh) zum Synchonisieren einer Standby Datenbank mit der produktiven Datenbank. Dieses Skript sollte auf dem Standby-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (mehrmals in der Stunde) ausgeführt werden.
    Die Einzelschritte:
    • das aktuelle Redo-Log der Primaer-DB wird gewechselt
    • alle Online Redo-Logs der Primaer-DB werden archiviert
    • die Ziel-SCN (System Change Number) fuer das Recovery wird ermittelt
    • die Archivelog Dateien werden auf den Standby Server synchronisiert
    • die Archivelogs werden in der Standby-DB bis zur Ziel-SCN recovert
    • die Differenz der Logsequenzen zwischen Prod- und Standby-DB wird geprüft
      ggf. wird eine Warn-Mail versandt
  2. Ein Script (archive_prim_remove.sh) zum Aufraumen der Archivelogs einer Primär-Datenbank. Dieses Skript sollte auf dem Primär-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (einmal am Tag bzw. nach jedem Archivelog Backup) ausgeführt werden.
    Die Einzelschritte:
    • juengste Log-Sequence-Nummer im Backup ermitteln
    • juengste auf Standby-Datenbank recoverte Log-Sequence-Nummer ermitteln
    • Archivelog Dateien mittels RMAN bis zur ältesten der ermittelten
    • Log-Sequence-Nummern loeschen

Hier einige Auszüge aus den Skripten:

stdby_sync.sh
DoLogTransport-Extract
DoLogApply-Extract 

archive_prim_remove.sh
RemoveArchivelogs-Extract

Interessant ist, dass sich die Standby-Datenbank unter Linux anders verhält als die unter Windows:
Unter Linux waren die recoverten Archivelogs in der View v$archived_log sichtbar, unter Windows dagegen war die View v$archived_log immer leer. Damit können die Archivelogs unter Windows nicht mittels des RMAN Befehls delete noprompt archivelog until sequence … auf dem Standby-Server gelöscht werden, auf dem Linux-Standby-Server geht das dagegen schon. Unsere aktuellen Skripte benötigen das allerdings nicht.

Am Ausstellungsstand von TEAM auf der DOAG 2013 Datenbank am 14. Mai 2013 konnte die Konfiguration in einer virtuellen Umgebung dann auch auf die Probe gestellt werden. Bei Interesse diese Installation zu begutachten, wenden Sie Sich bitte an TEAM oder direkt an mich.

2013-03-25

ViewObject Query mit IN Where Clause

Anwendungsfall: Wir möchten zur Laufzeit die Abfrage an eine Datenbanktabelle durch eine Where-Clause IN Bedingung einschränken.

Beispiel: SELECT * FROM EMPLOYEES WHERE EMPLOYEE_ID IN (:dynamischeListe)

Problemstellung: Deklarativ bietet ADF nicht die Möglichkeit eine IN Abfrage innnerhalb eines ViewCriterias zu erstellen. Daher müssen wir an dieser Stelle ein ViewCriteria programmatisch erstellen.

Lösungsmöglichkeit:

Schritt 1 - Wir erstellen an dem gewünschten ViewObject eine JavaMethode, welche die IN Einschränkung durchführt.



(Die Methode kann natürlich auch auf andere Datentypen erweitert bzw. generell verallgemeinert werden.)

Schritt 2 - Wir stellen die Methode dem Client zur verfügung.
 

Schritt 3 - Test (hier mittels Test-JavaKlasse)

Was das folgende (gewünschte Ergebnis liefert)

Zum Testen: BC-ProgrammaticAdditionOfViewCriteriaINClause-11.1.1.6

2013-03-15

Benutzung von Return-fähigen TaskFlows in af:regions

Anwendungsfall: Mehrere Task-Flows mit eigenem Transaktionsmanagement soll in einer dynamischen af:region unabhängig voneinander genutzt werden können (Navigatoreintrag startet zugehörigen Task Flow in einer dynamischen af:region) .
UseCase: Navigation mit anliegender af:region und unterschiedlichen Bounded TaskFlows

Problem: Wird einer der Task-Flows in der Region durch eine Return Aktivität beendet (zB einem commit), wird die dynamische Region inaktiv geschaltet und kein Task-Flow in diesem mehr gestartet; eine Blankoseite wird angezeigt.
Trotz eines Klicks auf den NavigatorLink wird kein neuer TaskFlow in der af:region angezeigt

Lösung1: Eine Lösungsmöglichkeit ist es, die zu benutzenden TaskFlows in einen Wrapper-TaskFlow einzubinden, welcher keine Return Aktivitäten besitzt und nur die einzelnen taskFlows integriert.
Wrapper-TF der die inneren TF's beinhält
 Somit wird nach dem Durchlauf eines inneren Task Flows auf den Wrapper verwiesen, welcher dann angezeigt wird. Dadurch wird die Region niemals inaktiv.

Lösung2: Die af:region wird beim Klicken der Navigationslinks programmatisch neu geladen.
Bean, welche die Bearbeitung der Region übernimmt. In jedem TaskFlow change wird die af:region refreshed
 So kann auch nach einem durchgelaufenen Task-Flow ein weiterer gestartet werden. Vorteil dieser Lösung ist, dass die Zahl der Task Flows auf die benötigte minimiert wird und keine "überflüssigen" Elemente erstellt werden.

Beide Lösungen führen dazu, dass nach dem Durchlauf eines TaskFlows weiterhin TaskFlows in der af:region angezeigt werden können.