Deployable applications

A deployable application includes these features:

• A deployable application automatically "owns" or "controls" all forms that are in the application, as well as any workflow that has one of the included forms as its primary form. A form can be in only one deployable application, but workflow can be used to integrate two deployable applications.
• All the components of the application, including forms, workflow objects, roles, data, and other information owned by the application, are automatically exported together from the development server and imported together to a test or production server.
• Access control in a deployable application is determined by roles and implicit groups. Roles are mapped to explicit groups, and the roles travel with the application. You can therefore assign permissions to roles at development time, and then map the roles to groups specific to the local server when the application is deployed.
• Access to the application is further determined by the application state, which can be set to maintenance, test, production, or a custom value. You define different access control roles and groups for the development (maintenance), testing, and production phases.
• You can set default permissions for the application. Once defined, default permissions are assigned to objects and fields as you create them in the application.
• A deployable application can own data, and the data can be exported and imported along with the application definitions.
• A deployable application can have access points. An access point is an indication to other developers to show which forms and active link guides in your application are designed to be used as integration points with the application.
• A deployable application can be licensed. You might use application licensing together with object locking, which prevents objects from being modified in Developer Studio . For more information, see Making applications licensable for integration system vendors.
• A deployable application can be configured to track server statistics within the application only. You can collect performance information such as how many times an application is accessed in a given period of time. You can collect similar statistics on individual forms.

Users can open an application in several ways. The typical method to present an application to users is to define entry points that appear in a home page, as explained in Creating and managing fields. For web applications, you can provide links to forms using special URLs, such as encoded URLs, URLs that bypass the login page, or URLs that pass search parameters when a search form is opened. Include the URLs on a web page or form. For more information, see Providing URLs for forms and applications.

Shared workflow in a deployable application

Depending on the design, a deployable application can function as a complete application in and of itself, or a related set of deployable applications can act as modules that are part of a larger application. In either case, you might need to use shared workflow to integrate two deployable applications. 

When a deployable application is used as a module in a larger application, or otherwise interacts with another deployable application, some of the workflow components that the application owns are also associated with forms owned by other deployable applications. Such workflow components are shared workflow that integrates the two application modules or applications. 

For example, a filter might gather data from its primary form in one application module, and push it to another form owned by another application module. The filter is owned by the application that contains the primary form, and integrates with the application that contains the other form. 

You can configure the AR System server  to maintain the full list of forms used by shared workflow components, even if those forms belong to other deployable applications and do not exist on the destination server. You can also set the Integration Workflow property on shared workflow components to identify a second deployable application that shares the workflow. This allows you to export only the shared workflow objects for two related deployable applications. See Exporting and importing shared workflow and integrated applications. 

These features make it easier to implement concurrent development in your organization, using different development servers, and maintain full functionality when application modules are brought back together in the larger application.

Contents of a deployable application

A deployable application contains all the information needed to deploy the application on another AR System server , including the forms and workflow, the roles associated with the application, and other data such as form data or help contents that you add to the application.

Objects in a deployable application

When you add a form to a deployable application, the form is "owned" by that application. A form can be in only one deployable application, and when a form is in an application, all AR System server  objects related to the form are also in the application.

The objects that are included in an application by means of association with an included form are:

• Active links, active link guides, escalations, filters, and filter guides for which the form is an associated form.
• Images, flashboards, and menus referenced by fields in the form.
• Flashboard variables referenced by flashboards in the application.
• Flashboard alarms that reference flashboard variables in the application.
• Web services for which the form is the associated form.

You can also add a packing list to an application, but the objects in the packing list are not necessarily part of the application. See Creating and managing packing lists. 

To see all the objects that are included in the application, open the application from the Applications branch in Developer Studio . An expandable panel appears for each object type included in the application. For example, the following figure shows the object list for the Sample application, with the Active Link Guides panel expanded to show the list of included active link guides. Expand the panel for each object type to see the list of objects included in the application. 

 The Sample application object list in  Developer Studio


When you edit an object owned by a deployable application, the server and application names are shown in the object label in the editor as illustrated by the following figure. 

The Sample: Cities form which is owned by the Sample application

Other contents of a deployable application

In addition to the server objects it contains, a deployable application also includes the following related information:

• Roles—All roles that are used to define access control for forms, fields, active links, and active link guides in the application are part of the application.
• Data—An application can use requests to represent business rules or other required data. You specify the forms that contain the data. You can also define qualifications that select the data to include.
• Support files—An application can use external files, for example, files referenced by file menus or other data files.
• Image files—You can specify image files that the AR System server  uses as the application icon and About box.
• Help files—You can create an external help file and link it to the application.