icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij Integration & Application Talents
Blog 27/09/2012

Deployment of Application Express applications

Tips & Tricks

The most common method of deployment in Apex is to export the application via the web interface, and import it into another. However, there are some things you need to consider, such as supporting objects and shared components. Also, administrators have their own requirements, such as that all deployments should be scriptable. This can lead to problems. In this blog I give some tips and guidelines to facilitate the process.

Deployment via the web interface (“manual”)

Export

First, export the workspace, select the Application Builder dropdown “Export”:

Here, you can find all export options in one place. Select “Workspace” and click “Export Workspace”. The export script is stored locally on your computer.

Before the Database Application can be exported, it is useful to export “shared components” such as css scripts, files and images (these are an exception because they do not explicitly take into the standard export!) in a single take. This can be done by including them as “Supporting Objects”. This way, a so called Packaged Application is created.

With Supporting objects you can add scripts, validations and conditions add to your application exports. It’s also useful for adding the Static Files from Shared Components to the application. There is only one way you can do this without errors:

Go to the Supporting Objects of your application in the Application Builder.

Click Installation Scripts:

Click Create:

Click Create Scripts to Install Files. The method “Create from file” produces error messages when importing!

Click Check All and then click Create Script:

The Static Files are now added as scripts to the export definition.

Now the application can be exported, and the Supporting Object scripts are included by default. Make sure you set “Export Supporting Objects” to “Yes” in the export process.

Import

An important rule when exporting and importing is: keep all workspaces and applications together. Make sure that the used workspaces on the development, test and production environments are identical.

Preferrably, do not change Application IDs on import. At each database instance, each application ID can only be used once: even across different workspaces.

The workspace will only be created once. It can be exported from the Application Builder, but can only imported through the Administration pages. All users in the workspace will be included in the export. This is convenient, but also a potential security risk, developers can use their Apex user to log on to production and modify production data. Take action by deleting users or changing rights!

Import the application definition in the same workspace. The wizard automatically asks whether the supporting objects also need to be installed. These are the Shared Components (static files and images).

Commandline deployment (“automated”).

Oracle doesn’t offer standard tools for command line export of applications, but John Scott wrote an interesting blog about a possible way: http://jes.blogs.shellprompt.net/2006/12/12/backing-up-your-applications/ .

When importing workspaces and applications through the command prompt (or a SQL script of course) a few things are important. First, you must log in as the right user. The manuals of Oracle indicate that you must log on as SYSTEM or FLOWS_0xxxxx user (where xxxxx depends on the Apex version). I prefer to use the FLOWS user as SYSTEM threw errors.

Workspace import scripts do not overwrite any existing workspaces; Oracle throws an error message. Application-import scripts remove any existing application and then install the new version. Shared component objects are removed and not replaced. Even if they are in the export definition.

The images, CSS and static files should be exported separately via the web interface and reimported after each deployment of the application from the SQL command prompt.

Finally, it is wise to change some properties of the production application definition; debugging and logging might be turned of for performance reasons. It is also a good idea to change the Build status from “Run and Build” to “Run application only”, so no adjustments can be done to the application definition. This option can be undone in the Administration pages if necessary.

Overzicht blogs

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.

Geen HTML

  • Geen HTML toegestaan.
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.

Wil je deel uitmaken van een groep gedreven en ambitieuze experts? Stuur ons jouw cv!