What are Oracle APEX Collections?

Oracle APEX Collections are in-memory data structures that exist within a session. Think of them as temporary tables that live only as long as the session does. You can create, manipulate, and query these collections using PL/SQL. They provide a way to store and manage data temporarily without needing to create actual database tables.

Here's an example of fetching all the planets from SWAPI (Star Wars API):

DECLARE
  l_url           VARCHAR2(1000) := 'https://swapi.dev/api/planets/';
  l_response      CLOB;
  l_planets       JSON_OBJECT_T;
  l_planet_array  JSON_ARRAY_T;
  l_planet        JSON_OBJECT_T;
  l_next_page     VARCHAR2(4000);
BEGIN

  -- Create or truncate the PLANETS collection
  APEX_COLLECTION.CREATE_OR_TRUNCATE_COLLECTION('PLANETS');

  -- Loop through all pages of results
  LOOP
    -- Make the API call
    l_response := APEX_WEB_SERVICE.MAKE_REST_REQUEST(
      p_url         => l_url,
      p_http_method => 'GET'
    );

    -- Parse the JSON response
    l_planets := JSON_OBJECT_T.PARSE(l_response);
    l_planet_array := l_planets.GET_ARRAY('results');

    -- Loop through the planets in the current page
    FOR i IN 0 .. l_planet_array.GET_SIZE - 1 LOOP
      l_planet := TREAT(l_planet_array.GET(i) AS JSON_OBJECT_T);

      -- Add planet to the collection
      APEX_COLLECTION.ADD_MEMBER(
        p_collection_name => 'PLANETS',
        p_c001            => l_planet.GET_STRING('url'),  -- Using URL as ID
        p_c002            => l_planet.GET_STRING('name')
      );
    END LOOP;

    -- Check if there's a next page
    l_next_page := l_planets.GET_STRING('next');
    EXIT WHEN l_next_page IS NULL;

    l_url := l_next_page;
  END LOOP;
END;

Once the collection is populated you can simply query it like a table:

SELECT c001 AS planet_id, c002 AS planet_name
    FROM APEX_COLLECTIONS
    WHERE COLLECTION_NAME = 'PLANETS'
    ORDER BY c002;

The Origins of APEX Collections

Oracle introduced APEX Collections to solve a specific problem: managing multi-row data in web applications without committing it to the database. They were first available in earlier versions of Oracle APEX (back when it was called HTML DB). The goal was to allow developers to collect and work with data across multiple pages or processes without relying on database tables for storage.

Key Features and Functionalities of APEX Collections

APEX Collections come with a set of built-in functionalities:

1. Creating Collections: You can create a collection using several different API methods (example: APEX_COLLECTION.CREATE_COLLECTION). Once created, you can add, modify, or delete data in the collection. Also, see the method used in the example above of APEX_COLLECTION.CREATE_OR_TRUNCATE_COLLECTION.

2. Manipulating Collections: APEX provides a variety of procedures to manipulate collections, such as ADD_MEMBER, UPDATE_MEMBER, and DELETE_MEMBER.

3. Querying Collections: You can query collections just like you would with a regular SQL table using the APEX_COLLECTIONS view (including using them in JOINs!).

These features made Collections an essential tool in early APEX applications, especially for handling multi-row data in forms, shopping carts, and complex reports.

Modern Use Cases for APEX Collections

Even with the advancements in Oracle APEX, Collections remain useful in many scenarios. Here are a few modern applications:

1. Temporary Data Storage: Use Collections to hold temporary data that doesn’t need to be stored permanently in the database. This is useful for complex calculations or multi-step forms where data is accumulated over several pages. One example might be flags calculated on session data to drive features of the app or security requirements.

2. Multi-Row Processing: Collections allow you to handle multiple rows of data in a session. This is ideal for scenarios like batch processing, where you need to collect and process data in chunks before committing it to the database.

3. Data Staging: Before committing data to the database, you can stage it in a Collection. This allows for validation and modification before finalizing the transaction.

Migration and Compatibility Considerations

APEX Collections have remained consistent across different versions of Oracle APEX. This makes migrating legacy applications that use Collections relatively straightforward. However, it’s essential to review your Collections during migration to ensure they align with the best practices of the newer APEX versions.

If you’re maintaining or upgrading an application that uses APEX Collections, ensure that the Collections are used efficiently. Avoid keeping large amounts of data in a Collection for too long, as this can affect session performance.

Case Studies and Real-World Examples

1. Multi-Page Form Handling: In one legacy APEX application, a multi-page form needed to collect data across three pages before submission. Instead of writing the data to the database after each page, a Collection was used. This allowed the user to review and edit the data before the final submission, alleviating potential locks and increasing performance.

2. Shopping Cart Implementation: A typical e-commerce application used APEX Collections to manage the shopping cart. Items added to the cart were stored in a Collection, allowing users to modify quantities or remove items before checkout.

Common Pitfalls and Challenges

While APEX Collections are powerful, they have limitations:

1. Session Dependency: Collections exist only within a session. If the session ends, the Collection data is lost. This makes them unsuitable for long-term data storage.

2. Performance: Large Collections can/will impact session performance. It’s crucial to manage the size and lifespan of Collections carefully.

When using Collections, ensure that they are the right tool for the job. If your data needs to persist beyond a session, consider using temporary tables or other database structures.

Future Outlook: The Role of APEX Collections in Emerging APEX Features

As Oracle APEX continues to evolve, the role of Collections may change. However, their ability to manage data within a session will likely remain valuable. Developers should keep an eye on new APEX features that might integrate with or enhance Collections.

For example, you might store user responses in a collection to use as part of a RAG process for enhanced LLM interaction!

Conclusion

Oracle APEX Collections have been a reliable tool for many years. They offer a flexible way to manage data within a session, making them useful in various scenarios. Whether you’re working with legacy applications or building new ones, APEX Collections are worth exploring.

References and Further Reading

1. Oracle APEX Collections Documentation

2. YouTube Video Library - APEX Collections

Consider APEX_APP_SETTING.GET_VALUE.

If you run this command in SQL Developer Web it won't fail, but it won't work as you might either:

DECLARE
    l_value VARCHAR2 (4000);
BEGIN
    l_value := APEX_APP_SETTING.GET_VALUE (p_name => 'ROLE_READER');
    DBMS_OUTPUT.put_line (l_value);
END;

Running that command will produce no real output.

Why doesn't it just work?

You need to set a little additional context for this to work! A session must be created (and cleaned up) to provide the context to the rest of the code.

APEX_SESSION.CREATE_SESSION

APEX_SESSION.DELETE_SESSION

DECLARE
    l_value   VARCHAR2 (4000);
BEGIN
    -- Provide the context of an APEX Session
    APEX_SESSION.CREATE_SESSION(
        p_app_id => 100,  -- Use the Application ID fo your app
        p_page_id => 2,   -- Use a page id from your app
        p_username => 'jstortz' -- Use your username
    );
    l_value := APEX_APP_SETTING.GET_VALUE (p_name => 'ROLEREADER');
    DBMS_OUTPUT.put_line (l_value);
    -- Now that we're done, cleanup the session
    APEX_SESSION.DELETE_SESSION;
END;

This article provides a comparison of Oracle APEX and Microsoft Power Apps, covering a few key features, capabilities, pricing, strengths, and weaknesses.

Overview of Oracle APEX

Oracle APEX (Application Express) is a low-code / no-code platform from Oracle, designed for building web applications and enterprise solutions. Initially released in 2004, APEX has evolved into a robust tool that leverages the power of the Oracle Database to deliver scalable, secure, and feature-rich applications including reporting, process and workflow automation, integrations and analytics.

Key Features

1. Performance: Known for its high performance, APEX can handle large-scale data and complex applications, making it ideal for organizations with extensive data management needs.

2. Customization: APEX offers extensive customization capabilities, allowing developers to tailor applications to specific requirements with a high degree of control over appearance and functionality.

3. Integration: Seamlessly integrates with Oracle Databases, enabling organizations to leverage their existing infrastructure and investments. ORDS provides fantastic capabilities for integrations with other platforms as well.

4. Security: Incorporates robust security measures, ensuring compliance with industry standards and protecting sensitive information. Integrations with many Identity systems are supported out of the box.

5. Scalability: Can scale to meet the demands of large enterprises, managing complex workflows and high user loads effectively.

Limitations

1. Connectivity with Non-Oracle Databases: While integration with Oracle databases is seamless, connecting to non-Oracle databases may require additional configuration.

2. Learning Curve: Despite being user-friendly, there is a learning curve, particularly for advanced features that require a solid understanding of SQL and PL/SQL.

3. Customization Constraints: Extensive customization may introduce long-term ownership challenges, particularly beyond the provided components and templates.

Overview of Microsoft Power Apps

Microsoft Power Apps is a low-code/no-code platform launched in 2016, aimed at democratizing app development by making it accessible to users of all skill levels. Part of the Microsoft Power Platform, it includes services like Power Automate, Power BI, and Power Virtual Agents, facilitating data integration, automation, and analytics.

Key Features

1. Accessibility: Designed for users without deep technical backgrounds, enabling them to create applications quickly.

2. Ease of Use: Features an intuitive drag-and-drop interface, making it accessible to a broad audience.

3. Integration with Microsoft Ecosystem: Integrates well with other Microsoft tools, such as SharePoint, Teams, and Dynamics 365, benefiting organizations invested in the Microsoft ecosystem.

4. Rapid Prototyping: Ideal for quickly prototyping and testing ideas, prioritizing speed over depth of capability.

Limitations

1. Data Retrieval: Suited for small datasets; performance degrades with larger data volumes.

2. Concurrent Development: Does not support simultaneous development by multiple developers.

3. JavaScript Integration: Lacks support for JavaScript, limiting flexibility for professional developers.

4. External Sharing: Applications cannot be shared with users outside the organization, restricting external collaboration.

Data Integration and Management

Oracle APEX excels in integrating with Oracle Databases, offering direct access to SQL and PL/SQL for data manipulation. This tight integration allows developers to leverage existing database skills without learning new programming languages. Additionally, APEX supports calling and executing stored procedures directly from the application, making it efficient for database-centric applications. The Citizen Developer (business user) can often utilize expressions as well as new APEX Assistant capabilities to develop applications without SQL knowledge.

In contrast, Microsoft Power Apps uses a set of functions and expressions to query databases, translating these queries to SQL. However, it lacks the direct access to SQL's full power, often requiring workarounds like creating views. Stored procedures cannot be called directly within Power Apps and must be executed through Power Automate, adding complexity and potential additional costs.

Customization and Extensibility

Oracle APEX provides extensive customization options through SQL, PL/SQL, JavaScript and Template Components. Developers can create plugins and include custom JavaScript and CSS to enhance application functionality and appearance as needed. This flexibility allows for highly tailored solutions that can meet specific deep business needs. It also allows for shared functionality between applications.

Microsoft Power Apps focuses on simplicity and ease of use, limiting customization capabilities. It does not support JavaScript, which can restrict the ability to implement complex client-side behaviors. The platform is geared more towards non-professional developers, making it less flexible for those with advanced development skills.

Scalability and Performance

Oracle APEX is known for its scalability, capable of handling large user bases and complex workflows. Its performance is optimized for Oracle Databases, ensuring efficient data processing and application responsiveness.

Microsoft Power Apps performs well for small to medium-sized applications but may struggle with larger data volumes. Its scalability is limited compared to APEX, making it less suitable for enterprise-level applications requiring high performance and large-scale data management.

Pricing

Oracle APEX is cost-effective for organizations already using Oracle Database or Oracle Cloud services. It is included with Oracle Database licenses, and there are no additional costs for the platform itself. This can result in significant savings, particularly for enterprises heavily invested in Oracle products. For those without an Oracle Database the OCI Oracle APEX Service can provide a cost-efficient avenue to gain access to all Oracle APEX functionality. Oracle APEX offers unlimited users and applications.

Microsoft Power Apps offers a free plan with limited capabilities. Beware, costs can escalate as more features and higher usage are required. Licensing fees are typically per user or per app, which can become expensive as the organization grows and usage increases.

Oracle APEX Examples

1. Large Financial Institution: A major bank used Oracle APEX to develop an internal loan management system. The platform's seamless integration with the Oracle Database allowed the bank to leverage existing data and infrastructure, resulting in a scalable and secure solution that improved processing times and user satisfaction. In a later phase they used the Workflow feature to add task management and request routing to their application.

2. Government Agency: A government agency adopted Oracle APEX to create a public-facing portal for managing citizen services. The robust security features and scalability of APEX enabled the agency to handle high user volumes while ensuring data protection and compliance with regulatory standards. In this case the agency strived to utilize only out of the box functionality with point and click configuration and eschewed all customization.

Microsoft Power Apps Examples

1. Retail Chain: A retail company implemented Power Apps to streamline inventory management across multiple locations. The integration with Microsoft 365 and Dynamics 365 allowed employees to access and update inventory data in real-time, improving efficiency and reducing errors. This use case highlights the tight integration with other Microsoft products.

2. Healthcare Provider: A local urgent care provider used Power Apps to develop a patient scheduling and tracking system. The platform's ease of use enabled non-technical staff to build and maintain the application, reducing dependency on outside IT vendors. A simple, yet impactful application that provided good business value.

Recommendations

For organizations considering which platform to use, several factors should be evaluated:

1. Existing Infrastructure: Organizations already using Oracle databases, or which are invested in Oracle products may find Oracle APEX to be the most cost-effective and seamless option. Conversely, businesses deeply integrated with Microsoft tools and services might prefer Microsoft Power Apps for its ease of use and integration capabilities.

2. Development Skills: Both platforms can be used without development skillsets. Teams with stronger development skills will find they can push Oracle APEX to greater heights than Microsoft Power Apps.

3. Project Complexity and Scale: For large-scale, data-centric applications requiring high performance and scalability, Oracle APEX is likely the better choice. For smaller, less complex applications or rapid prototyping, Microsoft Power Apps may be more acceptable.

4. Cost Considerations: Organizations should carefully evaluate the licensing and operational costs of each platform, considering both current and future needs.

Conclusion

Both Oracle APEX and Microsoft Power Apps offer solutions for low-code development, each with unique strengths and limitations. Oracle APEX excels in performance, scalability, and deep integration with Oracle databases, making it ideal for enterprise-level applications. Microsoft Power Apps shines in accessibility, ease of use, and integration within the Microsoft ecosystem.

Kicking off your project with Oracle Document Understanding Service (DUS) can be a game-changer for handling huge amounts of document data, such as invoices. However, navigating this powerful tool requires a strategic approach and a keen awareness of its nuances. Here are ten lessons learned from our extensive experience with DUS, which will help streamline your workflow and maximize efficiency.

1. Managing Millions of Invoices Across Multiple Sources

We faced the overwhelming task of processing millions of invoices from various sources, each with its unique format and structure. DUS proved invaluable, but the initial challenge was the sheer volume and diversity of the data. The key takeaway is to approach the problem systematically, categorizing and pre-processing data to ensure compatibility with DUS. This initial step is crucial for setting a solid foundation for subsequent processing.

2. Efficient Data Loading to Object Storage

One surprising discovery was the ease with which we could load significant amounts of data into Oracle Object Storage. Contrary to initial concerns, we managed this without resorting to transfer disks, even within tight timelines. The trick lies in leveraging high-bandwidth internet connections and parallel upload strategies. This lesson underscores the importance of understanding and utilizing Oracle's robust data transfer capabilities. You can do a lot more with OCI CLI than you think!

3. The Necessity of Batch Processing

Batch processing is not just a recommendation; it's a necessity. Attempting to process documents individually will significantly delay your project. By grouping documents into batches, you can optimize processing time and resource usage. This approach ensures a smoother, faster, and more efficient workflow, allowing you to handle large volumes of documents.

4. Managing Job Submissions and Status Checks

Effective management of job submissions and status checks is critical. DUS provides APIs for these tasks, and scripting these interactions is an absolute necessity. Consider using tools like Oracle APEX for a more user-friendly interface. Automation here can save considerable time and reduce the risk of errors, ensuring that you can monitor and manage job statuses efficiently.

5. Aggregating Resulting JSON Files

After processing, DUS outputs JSON files, which need to be aggregated and transformed before being loaded into a final system. Scripting the API to handle this aggregation is essential. This step consolidates the data, making it easier to work with and analyze. Proper aggregation scripts can significantly streamline the data handling process, facilitating better data management and insights. Warning, DUS analysis is very detailed and produces a LOT of data!

6. Reconciling and Resubmitting Errors

Errors are inevitable, and having a strategy to reconcile and resubmit them is vital. We encountered situations where DUS was overwhelmed, leading to processing errors. Establish a robust error-handling mechanism to identify, correct, and resubmit these errors. This proactive approach minimizes disruptions and ensures a more consistent data processing pipeline.

7. Understanding Job Limits

DUS imposes a limit of 2,000 documents per job. This constraint necessitates careful planning of how you batch your documents. Avoiding errors based on this limit will require splitting your data into smaller, manageable batches. Additionally, smaller batch sizes can mean reprocessing smaller numbers of documents in the case of errors.

8. Handling 429 Error Codes

When submitting more than 200 to 220 jobs, you might begin to encounter 429 error codes, indicating too many requests. This throttling is a protective measure by Oracle to maintain system integrity. Implement a strategy to handle these errors, such as back-off and retry mechanisms, to maintain a smooth processing flow.

9. Dealing with Incomplete Data Extraction

DUS can occasionally fail to identify certain data points, resulting in empty values. It's crucial to create reports to identify these instances and establish a manual process for correction. This step ensures data completeness and accuracy, maintaining the integrity of your processed data. Again, consider APEX to assist in this post-processing phase.

10. Monitoring Costs

While the cost of using DUS is minimal, it is not negligible especially at volume. Regular monitoring of your usage and associated costs is essential to avoid surprises. Implementing cost-monitoring scripts or tools can help keep track of expenses, ensuring that your project remains within budget.

Conclusion

Oracle Document Understanding Service (DUS) offers powerful capabilities for processing large volumes of document data. By learning from these ten lessons, you can optimize your workflow, avoid common pitfalls, and make the most of what DUS has to offer. Remember, strategic planning and proactive management are key to a successful implementation.

Feel free to reach out if you have any questions or need further assistance with your Oracle Cloud projects. Happy processing!

Before you begin you must have an Oracle Cloud Account as well as Docker Desktop all setup and be able to execute this command in your terminal:

docker -h

We will assume you already have a docker image locally and you want to push it to OCI Container Registry.

List your local docker images with the docker images command:

> docker images

myapp-server    latest        9fcb20691b9b   39 hours ago    137MB

Before you can push that image to OCI you need to do two things

1. Sign into OCI.

2. Tag the local image with a specifically formatted name.

Sign into OCI

Here's an example of signing into OCI:

> docker login ord.ocir.io

User: yourtenancy/oracleidentitycloudservice/jstortz
Password: <your oci auth token here>

As you can see, you'll need to get an OCI Auth token before you can complete the sign-in step. To do this:

1. In the top-right corner of the Console, open the Profile menu and then click User settings to view the details.

2. On the Auth Tokens page, click Generate Token.

3. Enter a friendly description for the auth token. Avoid entering confidential information.

4. Click Generate Token. The new auth token is displayed.

5. Copy the auth token immediately to a secure location from where you can retrieve it later, because you won't see the auth token again in the Console.

6. Close the Generate Token dialog.

Now you can attempt to sign-in with OCI.

Tag and Push

First, tag the image. You can see what "ID" you need to use by running docker images.

The basic syntax to tag your image looks like this:

docker tag <image-id> <region-domain>/<tenancy>/<container-name>:<version>

Example:

docker tag d2973444a992 ord.ocir.io/redstone/myapp:v1

The "ord.ocir.io" part depends on what OCI Region you want to use.

Use docker images to list your local images and confirm you now see this new tag

Then push with:

docker push <region-domain>/<tenancy>/<container-name>:version

Like this:

docker push ord.ocir.io/redstone/myapp:v1

Voila! Your image is in OCI Registry and ready for you to deploy with various technologies like OCI Container Instances.

References

Pushing Images Using the Docker CLI (oracle.com)

Container Instances Documentation (oracle.com)