Skip to Main Content
Feature Request FR-4634
Product Area Application Builder
Status CLOSED

2 Voters

Advanced Library & Component Framework for Oracle APEX

emmanuel guzmán Public · Aug 27 2025

Idea Summary
Oracle APEX is a powerful low-code platform, but developers often encounter limitations when dealing with advanced or enterprise-level requirements that go beyond standard CRUD applications. Complex scenarios—such as digital document signing, IoT integrations, and secure file handling—currently require external workarounds, custom APIs, or non-APEX technologies, which increases development complexity and reduces the overall efficiency of APEX projects.

The idea is to introduce an Advanced Library & Component Framework for Oracle APEX. This would consist of official (or community-managed under Oracle’s guidance) libraries and drag-and-drop components that simplify complex integrations. By providing prebuilt, reusable, and standardized tools, APEX developers would be able to handle advanced business needs more easily, securely, and quickly.

Key capabilities could include:

  • Native support for SSL certificate–based operations, such as digitally signing invoices or legal documents.
  • IoT integration components for biometric readers, RFID scanners, and sensors.
  • Secure connectors for file system interaction and advanced file handling.
  • A curated marketplace of reusable components and libraries that accelerate development for complex use cases.

This framework would position Oracle APEX not only as a rapid development platform but also as an enterprise-ready solution for modern, highly integrated applications.

Use Case
Electronic Invoicing

  • In many countries, companies are legally required to digitally sign invoices and official documents using SSL certificates. Currently, APEX developers must create external Java services or consume external APIs to achieve this. A native library would drastically simplify compliance with local regulations.
  • Healthcare Applications
    • Hospitals and clinics using APEX applications could integrate biometric readers for patient identification, or IoT medical devices for real-time monitoring, without needing highly complex external setups.
  • Retail & E-Commerce Marketplaces
    • APEX-based marketplaces can easily integrate credit card payments through APIs, but adding secure invoicing with digital signatures or connecting IoT devices like inventory scanners is currently very complex. Prebuilt libraries would streamline these workflows.
  • Smart Manufacturing & Logistics
    • Factories using APEX apps for operations could integrate IoT sensors that monitor machines or supply chains. Drag-and-drop components could allow real-time dashboards without requiring deep custom code.
  • Government & Public Services
    • Public institutions often require legally valid, digitally signed documents (e.g., permits, certificates). Having SSL and document-signing support within APEX would enable governments to build robust, compliant applications faster.

Preferred Solution (Optional)
The recommended implementation is to provide an Advanced Library & Component Framework as an extension to APEX, which could be distributed and updated similarly to the APEX plug-in ecosystem.

  • Libraries: Core PL/SQL packages or Oracle-maintained modules that handle cryptographic operations (e.g., SSL signing, encryption, secure certificate management).
  • Components: Drag-and-drop UI and backend modules in the APEX Builder (e.g., “Digital Invoice Signing Component,” “Biometric Authentication Component,” “IoT Data Connector”).
  • Marketplace Integration: An official or Oracle-verified repository where developers can contribute, download, and update these components, ensuring standardization and security.

This modular, marketplace-driven approach would allow Oracle to provide baseline official components while empowering the community to contribute additional ones, keeping the framework agile and up-to-date with emerging business needs.

We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Comments

Comments

  • vincent morneau Admin OP 14 hours ago

    This reads a lot like a 10 words prompt that was turned a 500 words idea using an LLM. There is nothing wrong with that, except that it's written so generically that the true purpose of the idea is lost and I'm not sure there is anything specific to action here. Please reply back with your original concepts and requirements.

  • emmanuel guzmán OP 13 hours ago

    Thank you for the feedback. Let me narrow this idea down into something more concrete and actionable:

    Specific Problem

    Today, for legal requirements such as electronic invoicing in LATAM, APEX developers must rely on external services (Java + BouncyCastle, third-party APIs, etc.) to digitally sign documents with X.509 certificates. This increases complexity, maintenance costs, and security risks since APEX lacks native support for these operations.

    Technical Requirement

    An official PL/SQL package within APEX that allows developers to:

    • Import a certificate (.pfx or .pem).
    • Digitally sign an XML or PDF document directly from PL/SQL.
    • Validate the signature of a received document.
    • Use a drag-and-drop component in APEX Builder to configure certificates without heavy custom coding.

    Pilot Use Case

    Electronic Invoicing in Mexico:

    • Input: XML of the CFDI generated in APEX.
    • Process: digitally signed using the SAT-issued .pfx certificate through a package such as apex_ssl_sign_pkg.
    • Output: digitally signed XML, ready to be sent to the PAC.
      This would address a critical business case for thousands of companies using APEX for ERP and accounting.

    Business Value

    • Reduce integration times from weeks to hours.
    • Standardize compliance in regulated industries (finance, healthcare, government).
    • Minimize risks from custom-built or third-party signing solutions.

    Future Extensions

    Once the digital signature component is validated, the same framework could extend to:

    • Biometric Authentication Plugin (fingerprint readers via WebAuthn).
    • IoT Data Connector (native WebSocket integration with sensors).
    • Secure File Handling APIs (encryption/decryption for files within APEX).

    So the proposal is not just a “generic framework,” but a first concrete component (native digital signature support) that solves a recurring, high-impact problem, while creating the foundation for a broader advanced component library in later phases. That's make sense?