Monat: Juni 2023

Die Migration von Oracle Forms zu APEX: 5 Vorteile und 5 Risiken

Einleitung:

In der sich ständig weiterentwickelnden Welt der Technologie ist es für Unternehmen unerlässlich, ihre Anwendungen auf dem neuesten Stand zu halten. Eine Technologie, die in den letzten Jahren in den Fokus gerückt ist, ist Oracle Application Express (APEX), eine Plattform, die als vielversprechende Option für die Modernisierung von Oracle Forms Anwendungen gilt. In diesem Beitrag werden wir die fünf Hauptvorteile und Risiken der Migration von Oracle Forms zu APEX untersuchen.

Vorteile der Migration zu APEX:

  1. Leichtgewichtige Architektur: APEX ist eine Plattform, die in der Cloud oder On-Premises betrieben werden kann. Dies bietet Flexibilität und erleichtert die Integration in bestehende Infrastrukturen.
  2. Einfache Bedienung: APEX bietet eine benutzerfreundliche Oberfläche und eine einfache Programmierung, die sowohl Entwicklern als auch Endbenutzern zugänglich ist.
  3. Skalierbarkeit: APEX ist auf Skalierbarkeit ausgelegt und kann problemlos für kleine oder große Unternehmen verwendet werden. Es kann auf eine Vielzahl von Datenquellen zugreifen und ermöglicht die Integration von Drittanbieter-Tools.
  4. Sicherheit: APEX bietet robuste Sicherheitsfunktionen, darunter eine rollenbasierte Zugriffskontrolle, Schutz vor SQL-Injektion Angriffen und SSL-Unterstützung.
  5. Kosteneffizienz: Im Vergleich zu Oracle Forms ist APEX in den meisten Fällen kostengünstiger, insbesondere wenn eine bestehende Oracle-DB-Infrastruktur vorhanden ist.

Risiken der Migration zu APEX:

  1. Komplexe Architektur: Oracle-Forms-Anwendungen haben oft eine komplexe Architektur, die sich über Jahre hinweg entwickelt hat. Die Modernisierung erfordert ein tiefes Verständnis der Architektur und der verwendeten Technologien.
  2. Fehlende Dokumentation: Oft fehlt es an ausreichender Dokumentation, um das Verständnis der Architektur und der Funktionalität der Anwendung zu erleichtern. Dies kann die Modernisierung erschweren und den Prozess verlangsamen.
  3. Inkompatible Technologien: Oracle Forms wurde entwickelt, bevor moderne Web- und Mobiltechnologien aufkamen. Die Anwendung ist daher in der Regel nicht mit diesen Technologien kompatibel. Die Modernisierung erfordert oft eine umfassende Überarbeitung der Benutzeroberfläche und der Backend-Architektur.
  4. Komplexität der Datenmigration: Bei der Modernisierung von Oracle-Forms-Anwendungen kann die Datenmigration eine Herausforderung darstellen. Die Daten müssen oft in ein neues Datenbankschema migriert werden, was Zeit und Ressourcen erfordert.
  5. Schulung der Mitarbeiter: Die Migration von Oracle Forms nach APEX erfordert eine Umschulung der Entwickler, um sicherzustellen, dass sie die neuen Technologien verstehen und effektiv nutzen können.

Fazit

Die Migration von Oracle Forms zu APEX bietet eine Reihe von Vorteilen, darunter eine leichtgewichtige Architektur, einfache Bedienung, Skalierbarkeit, verbesserte Sicherheit und Kosteneffizienz. Gleichzeitig gibt es jedoch auch Risiken, wie die Komplexität der vorhandenen Architektur, fehlende Dokumentation, Inkompatibilität mit modernen Technologien, die Herausforderung der Datenmigration und die Notwendigkeit der Umschulung von Entwicklern. Daher ist es wichtig, dass Unternehmen eine sorgfältige Planung und Vorbereitung durchführen, um sicherzustellen, dass die Migration erfolgreich ist. Mit der richtigen Strategie und den richtigen Ressourcen können Unternehmen jedoch die Vorteile von APEX voll ausschöpfen und ihre Anwendungen erfolgreich modernisieren.

Oracle Apex 23.1

Woohooo

Beste Apex Release ever is here..

Oracle APEX 23.1 has introduced a number of new features and improvements that enhance and expand the development experience. Here are some of the highlighted features:

  1. Template Components Unleashed: With APEX 23.1’s Template Components, building UI components is made easy and reusable. They can be rendered as standalone regions or within reports, and they support actions, menus, and custom attributes.
  2. PWA Push Notifications: The push notifications keep users updated whether they’re on desktop or mobile. They allow for easy subscription management and a manageable queue of notifications. The setup is very quick and straightforward.
  3. Developer Experience: The improvements to the Object Browser in APEX 23.1 offer a modernized design and enhanced editing experience. It also has improved performance and accessibility.
  4. Page Processing Improvements: With the new Page Process Type – Execution Chains, you can keep your page processes organized and under control. You can now monitor and report on running background executions, making your life as an APEX developer more efficient and enjoyable.
  5. REST Data Source Enhancements: With the REST Data Source Enhancements, you can invoke API for REST Sources, discover them with Swagger/OpenAPI, and enjoy the added flexibility of Raw Selectors.
  6. General Builder Improvements: With the General Builder Improvements, you can now copy pages from Create App, save and run pages from Code Editor, and access context-sensitive help. There is also native support for Property Graphs in Database 23c.
  7. APEX Approvals: With the Approvals component in APEX 23.1, you can keep your approval tasks on track by specifying due dates when creating them.
  8. Universal Theme and UX Improvements: The Universal Theme in APEX 23.1 has been updated and improved. It offers improved Template Components, improved icon fidelity, and an enhanced Region Display Selector.

These improvements and features contribute to making APEX an even more powerful platform for developing enterprise applications.

Exasol Virtual Schema Performancetest

In today’s world, where companies have to deal with huge amounts of data, the issue of data management efficiency becomes more and more important. One of the solutions to optimize data management and improve performance is to use Virtual Schemas in Exasol, a high-performance in-memory database.

In the following, we present a performance test of Exasol Virtual Schema to reduce the amount of data in an Exasol cluster environment. The idea behind this technique is to use a smaller Exasol cluster with a storage (memory) license and offload data to it.

Offloading data to a smaller cluster can lead to better performance by reducing the amount of active data that needs to be stored on the main Exasol instance. It also allows for greater flexibility by not having to keep the data on the main cluster all the time, resulting in better use of resources.

To perform this test, we use the Virtual Schema Adapter, which is written in Java. This adapter allows us to interact with Exasol via JDBC.

First we create the schema and the adapter:

CREATE SCHEMA X_SCHEMA_FOR_VS_SCRIPT;
CREATE OR REPLACE JAVA ADAPTER SCRIPT X_SCHEMA_FOR_VS_SCRIPT.ADAPTER_SCRIPT_EXASOL AS
    %scriptclass com.exasol.adapter.RequestDispatcher;
    %jar /buckets/bfsdefault/vschema/virtual-schema-dist-10.5.0-exasol-7.1.1.jar;
/

We then define two connections to our Exasol instance, one JDBC and one native Exasol connection:

CREATE OR REPLACE CONNECTION JDBC_CONNECTION_EXA_DEV1 
TO 'jdbc:exa:1.112.32.331..333/FINGERPRINT:8565'
USER 'SYS'
IDENTIFIED BY 'xx';
CREATE OR REPLACE CONNECTION EXA_CONNECTION_DEV1
TO '1.112.32.331..333/FINGERPRINT:8565'
USER 'SYS'
IDENTIFIED BY 'xx';

After that we create the Virtual Schema with the JDBC connection we created earlier:

CREATE VIRTUAL SCHEMA VIRTUAL_EXASOL_DEV1 
USING  X_SCHEMA_FOR_VS_SCRIPT.ADAPTER_SCRIPT_EXASOL WITH
    CONNECTION_NAME = 'JDBC_CONNECTION_EXA_DEV1'
    SCHEMA_NAME     = 'HISTORY_ARCHIVE'  
    IMPORT_FROM_EXA = 'true'
    EXA_CONNECTION  = 'EXA_CONNECTION_DEV1'
    MAX_TABLE_COUNT = '10000';

After that, the data will be merged with the data from the other source:

Since we do not want that another query is necessary than before. It should remain transparent for our customer!

create or replace view FULL_DATA
as select * from ACTUAL_DATA 
where datadate > sysdate-interval '1' MONTH
union all 
select * from VIRTUAL_EXASOL_DEV1.ARCHIVE_DATA 
where datadate < sysdate- interval '1' MONTH;

When we do a performance test we see that there is a clear difference if we do a query on a large database or on 2 databases when they are linked via Union All and Virtual Schema.

DEV1 is really slow – but cheap!

The optimizer of course passes the Where Clause, but still fetches all the necessary data over the network. And that takes time. Note: Runtime in seconds.

Conclusion: Depending on the query, the query performance has an effect. If you only need a few data for a calculation, it is of course not so dramatic, but we achieved a slowness factor between 11 upto 157 in our tests. Since we only tested with simple queries, this is still an important knowhow for us.

SPHINX.AT

YAITCON

© 2024 Sphinx Blog

Theme by Anders NorenUp ↑