Package a P6 app

In order to package an app, you need to have access to the Applications service, which purpose is twofold:

• Allow developers to package a Platform 6 app they have built,
• Allow end users to install or uninstall packaged apps.

A packaged P6 app is a compressed, signed and encrypted file containing all the resources required for the app to be installed on any other P6 instance.

Permissions

To see the Applications menu entry on the Portal, the applications=view permission is required. The ‘Applications’ tab displayed by the Portal is split in two sections: ‘Packaged applications’ and ‘Applications under development’.

User interface of the Applications service

The Packaged applications section shows three different types of applications:

• Applications that have been packaged on the instance and are ready to be downloaded and distributed (grey ‘Switch’ icon in the ‘Actions’ column, red cross in the ‘Installed’ column)
• Imported applications that have not yet been installed on the instance (blue ‘Switch’ icon in the ‘Actions’ column, red cross in the ‘Installed’ column)
• Imported applications currently installed on the instance (orange ‘Switch’ icon in the ‘Actions’ column, green check mark in the ‘Installed’ column)

The Applications under development section lists applications that are being developed on the instance and offers, for each of them, the ability to…

• Edit the application (name, version, status, expiration, min and max P6 Core versions, packaged service items…)
• Delete the application
• Update the service items that are part of the app package
• Package the application and create the .p6app file

To package a Platform 6 application, having access to the applications service is required. Also, an application profile must have been created and installed on an instance via the Management Console (P6 MC).

Packaging an Application

Once you have developed your application, you can package it.

Packaging an application will actually generate a Platform 6 application file (.p6app) containing the application attributes and zero or more serialised service items (configuration from individual Platform 6 services). It is the raw logic and configuration of your application. The whole application package is bundled, hashed and signed to guarantee the integrity of the bundle and ensure it is not tampered with.
Signing is performed automatically thanks to the key of the application profile when you package your application.

You can package an application only if the related application profile is installed on the instance you are working on.

Clicking on the ‘Develop’ button will create a new bundle from the application details and sign it using the key in the application profile. The newly created application bundle will be automatically added as a new application in the list of applications allowing it to be downloaded and distributed to others.

Warning

If an application already exists with the same key and version, the Application Publisher will not be allowed to build.

New applications in development mode can be deleted.

Double-clicking on a row will give access to the application build details form which allows the application publisher to define the content of the application.

The user interface allows the application publisher to select each installed service and list the service items that have an application key that matches the application that is being built. The application publisher can select items from the list to include in the application and also select the content-mode (none, read and edit) for each service item selected.

Tip

If you want to use classes from a Jar archive in your install script you have to:

• Deploy the bundled resources inside the Pre-install script
• Use those classes from Jar archive inside the Post-install script

Please read the Bundled Resources guide section to understand how to add Java archives in your application.

Notice

Notice that in order to create a Post-install script using classes from a Jar archive you need to manually deploy the resource before saving the script. This limitation is due to the compilation of the groovy script and requires the classes to be loaded to be used.

The version and the status values can be entered. Please note that Platform 6 does not manage application’s versions and status messages. They are treated as simple strings only. However, they can be used to help application’s users control what is installed on their instances.

Warning

An application can’t be packaged over the top of one that already exists! Thus the combination of the application’s version and status must be unique.

Applications can optionally expire after a given period (trial versions for example). The ‘Expires after’ field specifies this behaviour.

Pre-Install, Post-Install and Uninstall scripts can be selected. The user interface provides a list of scripts with matching application key to choose from.

The scripts should set the pipeline variable: installScriptResult to either true or false depending upon the execution outcome of the script.

Note

The Uninstall script is run BEFORE the items are un-deployed.

Finally, the application’s properties list enables a publisher to define values passed to each Install/Uninstall script. These properties are also be available at runtime to enable additional functionality.

For example, if the Application Publisher is distributing a custom service written in Java and conforming to Platform 6 ServiceComponent specification, they can add the service checksum as a property that can be validated by the Platform Manager at runtime.