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.