Structure of multiple applications

When creating applications, the less repeating work is done, the better. Within an application you can use shared components for this purpose. If our application (or better said, system) consists of more application modules than one big application, we need another approach. Between multiple applications in the same workspace, we can use the less known subscribe feature of APEX.

By using the subscribe and publish mechanism of APEX, we can create a structure of multiple applications that can serve as a good starting point. Some benefits:

• Better maintainable look and feel across multiple applications

• The use of shared components across applications

• Modular structure

• Reusable centralized functionality, such as authorization, authentication, auditing, and logging

Subscribe and publish

The subscribe and publish mechanism is very straightforward. In the following screenshot, we can see the Subscription part of a template definition:

Subscription part of a template

Subscribing and publishing can be compared to pull and push. When defining a template, for instance, it's possible to reference a master template from another application. This is shown in the following screenshot:

Subscribed to a master template

As we can see, there's a button for refreshing the template. After clicking on the button, the definition of the master template is loaded and copied over the current template. This is the pulling method. On the template overview screen, there's also a column Subscribed that shows which templates subscribe to a master template. Multiple template refreshing can be accomplished by clicking on the Subscription tab on the Templates overview screen.

The pushing method is done via the master template and it is shown in the following screenshot:

Subscribed from a master template

When we click on the Publish Template button, APEX published this master template to all subscribed templates from other applications. Multiple template publishing can be accomplished by clicking on the Publish tab on the Templates overview screen.

The shared components that can be subject for the subscribe and publish mechanism of APEX are as follows:

• Templates (themes)

• List of values

• Navigation bar entries

• Shortcuts

• Plug-ins

• Authentication schemes

• Authorization schemes

Notes:

• Subscribed objects are updatable, but refreshing them will overwrite these changes.

• Subscribing and publishing only works within a single workspace. It's not possible to reference, for instance, a template from an application in another workspace.

Creating a framework

A well thought out structure of applications can serve as a framework for all our future development. To create such a framework, we need a number of applications, depending on the complexity of the system and our specific needs. The applications to build are a master application, template application, and optionally a login application and/or a system application. The template application serves as a basis for the actual applications to build (application 1 to n), as we can see in the following diagram:

Application framework

Master and template application

Create a master application that contains publishable shared components such as authentication schemes, authorization schemes, lists of values, and templates. Changes can be pushed from the master application to all subscribing applications. Other applications will reference the standard templates by subscribing to the master application.

To make newly created applications subscribe to the master application, we need to create a template application. Create the template application as a copy of the master application and change the subscription of all the shared components to reference the master application. To change the subscription of multiple templates, you can replace templates in this application with templates from another application. This can only be done for currently used templates. Another option is to delete templates and recreate them as a copy (and subscribe) from the master application. The remaining templates and shared components can be modified manually.

The template application is also the place where Page Zero is added.

In more complex situations, the master can have more than one theme or more variants of shared components. We can then create more than one template—which serve as a starting point for the applications.

To create a new application, we simply need to make a copy of the template application. Because the new application is a copy, all the subscriptions to the master application are also copied. For the shared components, it's always possible to unsubscribe. To unsubscribe from multiple templates, the Unsubscribe Templates option from the Task menu can be selected.

Login application—optional

When more than one application in the workspace share the same authentication, we can extend the framework with an application dedicated to the authentication process. This application will handle the login and can serve as a starting menu for the other applications.

We can create this login application as a copy of the template application. The authentication of this application is different than the other applications. Here we create the actual authentication schema, which we want to use in all our applications.

When switching between applications without having to log in again, we need to share the session state between the applications. To do so we have to give the session cookie the same name. We do that in the authentication schema of the master application.

We also need to get redirected to this application when a user tries to log in directly to one of the applications. We can accomplish this by redirecting to this application by setting the Session Not Valid property of the authentication schema in the master application to redirect to the login application. In APEX 4.1.1, you are automatically redirected to the calling application after successful login.

Optionally, we can also set the logout URL to point to a specific page in the login application.

In the following screenshot, we can see the relevant authentication scheme settings for the master application:

Authentication scheme settings

Other examples of pages that can be included in this application are as follows:

• User registration page for self-service applications: It can also have the functionality to send a confirmation e-mail with a link in it, which leads to an activation page.

• Application start page.

• Personal account settings page.

• Password forgotten page to reset an old password: An email with the new password is sent to the user. The e-mail can also contain a link to a landing page to change it immediately.

• Change the password page to let passwords expire after a given period of time.

• Help pages for the application(s).

System application—optional

Besides a login application, we can also create a system application for the more technically oriented system administrator or DBA. This application will offer control and maintenance functionality for all other applications and/or the whole system.

Possible functionality includes:

• Controlling e-mail queues.

• Performance reports of the pages and applications: This is also possible in APEX itself, but it could be useful to be able to access it in a convenient way within the application.

• Reading the APEX Feedback.

• Dealing with user approval of a self-service application.

• Inspecting (error) logs.

• Setting system parameters such as mail host address, mail host port, colors, and so on.

• Inspecting jobs.

• A structure for maintaining user and access roles: On this structure we can build some functionality that can be incorporated into the authorization scheme of the master application.

• Maintaining system parameters.

Depending on the situation, a part of this functionality can be part of the normal application administrator tasks of the system as well.

Deploying

To deploy these applications, we just need to export them and then do an import in the target environment, just as a single application. If it applies to the situation, also deploy the login and system application. It's not necessary to deploy the master or template application.

Template workspace

If you develop many projects for different companies with different needs, we need to create a framework for every new customer/system. What we need is in fact a template workspace as the starting point for creating the actual workspace, with a master template and login/system applications in it with the minimal used common functionality.

When we start a new project, we need to create a new workspace and place all the applications in it with export and import. If we want to use the same application IDs, we have to set up such a template workspace in a separate database.