Forms Migration Services - The clever way of Forms modernization

After several years of intensive research in cooperation with s-lab, a special interest group of the University of Paderborn supporting industrial partners in developing new technologies, TEAM proudly presents the Forms Migration Services – a process to take your Forms application to the next level using a model driven migration approach containing the TEAM Migration Assistant - a toolset for semi-automatic modernizations. Do the results justify all the effort? Yes, definitively!

In accordance with the objective to transform a Forms application into a maintainable ADF application, the project team initially followed the approach of a fully automated migration. This initial idea had to be revised, however, due to the technical differences between the two platforms Forms and ADF. A wider approach had to be taken in order to achieve appropriate/satisfactory results. Migrating a Forms application using a single blue print which transforms dialogue by dialogue and even generates a "Forms-Runtime" in ADF may represent a viable method to generate a running ADF application; however, this application would neither be maintainable nor would it offer any extension points to allow progression of the application. Thus it was obvious that a more sophisticated and abstract way of thinking was needed to solve the issues a 1:1 migration brings along.

Keeping that in mind, the project team, consisting of TEAM developers and s-lab members, developed a new approach to transforming and, at the same time, modernizing a Forms application into a “true” ADF application. A major challenge in this process was the fact that most Forms applications have been developed with a company specific Forms framework (i.e. functions and objects extending the original Oracle Forms framework). The new migration method is based on a multilevel modernization process. By using tools for source code analysis, knowledge and patterns for the specific Forms application are recognized and transformation rules can be established. These rules provide project specific patterns to the TEAM Migration Assistent which then generates the ADF application iteratively. Each iterative step is to be finished manually. After each step, our migration experts and the development team come together to discuss the lessons learned and whether or not recent development steps or code fragments can be automated in the next iteration step. This procedure ensures that the following iteration steps can be finished a lot quicker.

The Forms Migration Services offered by TEAM provide a novel integrated concept to modernize your Oracle Forms application to a "true" ADF application that is maintainable, great looking and enabled for future implementations!

Forms - Quo Vadis

Mit Oracle Forms werden seit Jahrzehnten Datenbankanwendungen entwickelt. Oracle hat versucht, Forms immer wieder an den Stand der Technik anzupassen.

Doch spätestens seit dem "Statement of Direction" im März 2012 hat Oracle klar aufgezeigt, dass neue Technologien nicht mehr mit Forms realisiert werden können. Stattdessen hat Oracle das Application Development Framework (ADF) entwickelt, um den neuen technologischen Aufgaben gewachsen zu sein. Wenn Oracle-basierte Applikationen webfähig gemacht, erweitert, integriert oder ersetzt werden sollen, führt heute kein zukunftsorientierter Weg an Oracle ADF vorbei.

Sie fragen sich, ob es sinnvoll ist, Ihre Forms Applikation nach ADF zu migrieren oder welcher Weg der Migration der richtige ist? Lassen Sie sich am 18. März 2014 durch diese kostenlose Veranstaltung auf den neuesten Stand bringen!

Speziell ausgebildete und projekterfahrene TEAM-Mitarbeiter zeigen Ihnen, unter anderem anhand einer Live-Demo, ob und wie eine Migration von Forms zu ADF sinnvoll durchgeführt werden kann.
Erfahren Sie alles Wissenswerte zu den Themen Migrationsstrategien, Projektvorgehen und welchen Mehrwert Sie durch eine Migration von Forms zu ADF erhalten können.



Agenda:

13:00	Registrierung und gemeinsamer Imbiss
13:45	Begrüßung und Vorstellung TEAM Harry Jules Mayo, TEAM GmbH
14:00	Aufbruch in eine neue Welt: Warum Oracle den Wechsel von Forms zu ADF vollzogen hat Jürgen Menge, ORACLE Deutschland B.V. & Co. KG
14:30	Wenn eine "Migration nach Kochrezept" keinen Sinn macht Marvin Grieger, s-lab, Universität Paderborn
15:00	Kaffeepause
15:15	Von Forms zur erweiterbaren ADF-Anwendung: Der TEAM Migration Assistant Markus Klenke, TEAM GmbH
16:15	Mit der neuen ADF Applikation in die Zukunft: Die TEAM ADF-Tools Christian Kunzmann, TEAM GmbH
16:35	Migration im Projekt: Von der Analyse bis zur ADF-Anwendung Wolf G. Beckmann und Harry Jules Mayo, TEAM GmbH
17:00	Ende der Veranstaltung

Haben wir Ihr Interesse geweckt? Dann laden Sie hier den Einladungsflyer zur Veranstaltung "Forms Quo Vadis" inklusive Anmeldeformular herunter.

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.

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.