Deploying applications

When you deploy an application written in Flex, you make the application accessible to your users. The process of deploying an application is dependent on your application, your application requirements, and your deployment environment. For example, the process of deploying an application on an internal website that is only accessible by company employees might be different from the process for deploying the same application on a public website accessible by anyone.

Use the overview of the deployment process and the general checklist as a guide when you deploy your application. This topic does not attempt to define the exact set of steps that you use for deploying all applications. Instead, it contains an overview of the deployment process, and a general checklist that you might use when you deploy your application.

About deploying an application

When you deploy an application, you move the application from your development environment to your deployment environment. After you deploy it, customers have full access to the application.

The deployment process that your organization uses might only require you to copy a application's SWF file from your development server to your deployment server. In many organizations however, the deployment process is more complicated, and involves people from groups outside the development organization. For example, you might have an IT department that maintains your corporate website. The IT department might be responsible for staging, testing, and then deploying your application.

Your application architecture might also require you to deploy more than just a single SWF file. For example, your application might access Runtime Shared Libraries (RSLs) or other assets at run time. You must make sure to copy all required files to your deployment environment.

Deployment might also require you to perform operations other than just copying application files to a deployment server. Your application might access data services on your server, or on another server. You must ensure that your data services are accessible by a deployed Flex application that executes on a client's computer.

Deployment options

The following example shows a typical deployment environment for an application:

Typical deployment environment.

Deploying an application for Flex SDK might require you to perform some or all of the following actions:

  • Copy the application SWF file to your deployment server. As the previous example shows, you copy the application to webserver.example.com.

  • Copy any asset files, such as icons, media files, or other assets, to your deployment server.

  • Copy any custom RSLs to your web server or application server. For more information, see Deploying RSLs with Flex SDK.

  • Copy the framework RSLs to your deployment server. For more information, see Using the framework RSLs.

  • Copy any SWF files for your module to your deployment server in the same directory structure as you used for your development environment. Deploying modules with Flex SDK.

  • Copy any SWF files required to support Flex features, such as deep linking or runtime CSS. For more information, see Deploying additional Flex files.

  • Write a wrapper for the SWF file if you access it from an HTML, JSP, ASP, or another type of page.

    A deployed SWF file can encompass your entire web application, however it is often used as a part of the application. Therefore, users do not typically request the SWF file directly, but request a web page that references the SWF file. For more information, see Creating a wrapper.

  • Create a crossdomain.xml file on the server for data service, if you directly access any data services outside of the domain that serves the SWF file. For more information, see Accessing data services from a deployed application

Deploying RSLs with Flex SDK

When your application uses custom RSLs, you must make sure to deploy the RSL on your deployment server, in the same domain, unless you are using cross-domain RSLs. You use the runtime-shared-libraries option of the Flex compiler to specify the directory location of the RSL at compile time. Ensure that you copy the RSL to the same directory that you specified with runtime-shared-libraries.

By default, the Flex compilers dynamically link your application against the framework RSLs. This means that classes in the SDK are externally loaded at run time from the framework RSLs. The default location of these RSLs is on the Adobe® web site. If you clients do not have network connectivity, you must deploy the framework RSLs to a local location, or disable framework RSLs. To customize the location of framework RSLs, edit the flex-config.xml file. To disable framework RSLs, set the static-link-runtime-shared-libraries compiler option to true.

Flex also provides framework RSLs. These libraries are comprised of the Flex class libraries and can be used with any application built with Flex. The framework RSLs are precompiled libraries of framework classes and components. If your client does not have internet connectivity, be sure to deploy both the signed (*.SWZ) and unsigned (*.SWF) RSLs. Flash® Player will first try to load the signed RSLs from the Adobe web site, so you should not have to deploy them in most cases.

For more information, see Runtime Shared Libraries.

Deploying modules with Flex SDK

Modules are SWF files that can be loaded and unloaded by an application. They cannot be run independently of an application, but any number of applications can share the modules. When your application uses a module, you must make sure to deploy the module's SWF file on your deployment server in the same directory structure as you used for your development environment. For more information, see Modular applications.

Deploying additional Flex files

The implementation of some Flex features requires that you deploy additional files along with your application's SWF file. For example, if you use deep linking functionality in your application, you must deploy the historyFrame.html, history.css, and history.js files. If you use the Express Install version detection feature, you also must deploy the playerProductInstall.swf file with your SWF file. You typically deploy these files in the same location that the default HTML wrapper looks for them. For example, the deep linking files are typically in a sub directory called /history.

For a complete list of additional Flex files that you might deploy with your application, see Deployment checklist.

Accessing data services from a deployed application

In a typical Flex development environment, you build and test your application behind a corporate firewall, where security restrictions are much less strict than when a customer runs the application on their own computer. However, when you deploy the application, it runs on a customers computer outside your firewall. That simple change of location might cause the application to fail if you do not correctly configure your data services to allow external access.

Most run-time accesses to application resources fall into one of the following categories:

  • Direct access to asset files on a web server, such as image files.

  • Direct access to resources on your J2EE application server.

  • Data services requests through a proxy. A proxy redirects that request to the server that handles the data service request.

  • Direct access to a data service.

As part of deploying your application, ensure that all run-time data access requests work correctly from the application that is executing outside of your firewall.

Compiling for deployment

When you create a deployable SWF file, ensure that you compile the application correctly. Typically, you disable certain compiler features, such as the generation of debug output, and enable other options, such as the generation of accessible content.

This section contains an overview of some common compiler options that you might use when you create a deployable SWF file. For a complete list of compiler options, see Flex compilers.

Creating a release build of your application

To compile a release build on the command line, set the debug compiler option to false. This prevents debug information from being included in the final SWF file.

Enabling accessibility

The Flex accessibility option lets you create applications that are accessible to users with disabilities. By default, accessibility is disabled. You enable the accessibility features of Flex components at compile time by setting the accessible option to true for the command-line compiler, or setting the <accessible> tag in the flex-config.xml file to true.

For more information on creating accessible applications, see Accessible applications.

Disabling incremental compilation

You can use incremental compilation to decrease the time it takes to compile an application or component library with the Flex application compilers. When incremental compilation is enabled, the compiler inspects changes to the bytecode between revisions and only recompiles the section of bytecode that has changed.

For more information, see Flex compilers.

Using a headless server

A headless server is one that is running UNIX or Linux and often does not have a monitor, keyboard, mouse, or even a graphics card. Headless servers are most commonly encountered in ISPs and ISVs, where available space is at a premium and servers are often mounted in racks. Enabling the headless mode reduces the graphics requirements of the underlying system and can allow for a more efficient use of memory.

If you deploy a Flex application on a headless server, you must set the headless-server option of the compiler to true. Setting this option to true is required to support fonts and SVG images in a nongraphical environment.

Deployment checklist

The deployment checklist contains some common system configuration issues that customers have found when deploying Flex applications for production. It also contains troubleshooting tips to diagnose common deployment problems.

Application assets

When deploying a Flex application, you must make sure you also deploy all the assets that the application uses at run time. These include files that are used by the wrapper to support features such as deep linking and Express Install, as well as files that are loaded by the application such as resource bundles or RSLs.

In the case of wrapper code, you will probably be cutting and pasting it from the HTML template included with the SDK into your JSP or ASP or PHP pages.

Check that the following assets are deployed with your application if you use those assets in your Flex applications:

Feature

Assets to Deploy

Wrapper files

If you use a wrapper, be sure to include it in the deployment process. The wrapper can be any file that returns HTML, such as PHP, ASP, JSP, or ColdFusion. Typically, this file uses the SWFObject 2 logic, or includes an <object> or <embed> tag to embed the Flex application.

In addition, if you use dynamic pages to query databases or perform other server-side actions for your Flex application, be sure to deploy those as well.

For more information, see Creating a wrapper.

Version detection

To support version detection or Express Install in your HTML wrapper, you must add the code based on the Flex wrapper template to your wrapper, as well as deploy the swfobject.js file. You must also deploy the playerProductInstall.swf file.

For more information, see Creating a wrapper.

Deep linking

To support deep linking, you must include the following files in your deployment:

  • history.js

  • history.css

  • historyFrame.html

You must import the first two files into your HTML wrapper, and store all of these files in a /history subdirectory.

For more information, see Deep linking.

Runtime shared libraries (RSLs)

For standard RSLs, deploy the RSL SWF files with your Flex application. You must be sure to deploy the SWF files to the same relative location that the compiler used. If you are deploying an a custom RSL, be sure to optimize the RSL's SWF file prior to deployment.

For framework RSLs, if your client does not have internet connectivity, be sure to deploy both the signed (*.SWZ) and unsigned (*.SWF) RSLs. Flash Player will first try to load the signed RSLs from the Adobe web site, so you should not have to deploy them in most cases.

For framework and cross-domain RSLs, be sure to deploy failover RSLs to the locations you specified when you compiled the application.

For more information, see Runtime Shared Libraries.

Runtime stylesheets

If you use runtime stylesheets in your application, you must deploy the SWF files so that they can be loaded. You can load run-time stylesheet SWF files either locally or remotely. However, if you load them locally, the stylesheets must be in the same relative location that you specified in the application.

For more information, see Loading style sheets at run time.

Modules

If your application uses modules, you must deploy the module SWF files so that they can be loaded.

Modules are SWF files that can be loaded and used by any number of applications. If multiple applications use your modules, then you should deploy them to a location that all applications can load them from rather than deploy them multiple times across different domains.

For more information, see Modular applications.

Runtime localization

If your application uses run-time localization (if it, for example, lets the user switch from English to Japanese language at run time), then you might need to deploy resource module SWF files. These modules can contain one or more resources bundles for one or more locales.

For more information, see Localization.

Security files

If you use container-based security, then be sure to update your security constraints to include your Flex application.

In addition, if you load assets from multiple domains, be sure to deploy any crossdomain.xml files that are required by your applications.

Miscellaneous runtime assets

Not all assets are embedded at compile time. For example, FLV and image files are usually loaded at run time to keep the SWF file as small as possible. Be sure to check that you deploy the following types of assets that are typically loaded at run time with your Flex application:

  • FLV files

  • SWF files

  • Sound files (such as MP3 files)

  • Images (such as GIF, JPG, and PNG files)

Data files

It is not uncommon for flat data files to be used as a data provider in Flex applications. Be sure to deploy any text files, which might appear in various formats such as XML, that are loaded at run time.

Types of network access

Deployed applications typically make several types of requests to services within your firewall, as the following example shows:

Requests to services within a firewall.

Most of the deployment issues that customers report are related to network security and routing, and fall into one of the following scenarios:

  1. Direct access to resources on a web server, such as image files. In the preceding example, the client directly accesses resources on webserver.example.com.

  2. Direct access to resources on your application server. In the preceding example, the client directly accesses resources on appserver.example.com. Ensure that deployed applications can access the appropriate servers.

  3. Web services requests through a proxy. A proxy redirects a request to the server that handles the web service. In the preceding example, the client accesses a resource on appserver.example.com, but that request is redirected to finance.example.com. Ensure that you configure the proxy server correctly so that deployed Flex applications can access your web services, or other data services, through the proxy.

  4. Direct access of a web service. In the preceding example, the client directly accesses a service on finance.example.com. If a deployed Flex application directly accesses web services, or other data services, ensure that access is allowed.

Step 1. Create a list of server-side resources

Before you start testing your network configuration, make a list of the IP addresses and DNS names of all the servers that a Flex application might access. A Flex application might directly access these servers, for example by using a web service, or another server might access them as part of handling a redirected request.

Enter the information about your servers in the following table:

Name

DNS name

IP address

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enter information about the server hosting the web service proxy:

Name

DNS Name

IP Address

 

 

 

Enter information about your web services or any other services accessible from a deployed Flex application:

Name

Location (URL)

 

 

 

 

 

 

 

 

 

 

Step 2. Verify access from server to server within your firewall

In some cases, an external request to one server can be redirected to another server behind your firewall. A redirected request can occur for a request to a web service or to any file, depending on the system configuration. Where it is necessary, ensure that your servers can communicate with each other so that a redirected request can be properly handled.

To determine if one server, called Server A in this example, can communicate with another server, called Server B, create a temporary file called temp.htm on Server A in its web root directory. Then, log in to Server B and ensure that it can access temp.htm on Server A. Try to access the file by using Server A's DNS name and also its IP address.

Servers can have multiple NIC cards or multiple IP addresses. Ensure that each server can communicate with all of the IP addresses on your other servers.

Also, log in to the server that hosts your web service proxy to make sure that it can access all web services on all other servers. You can test the web service proxy by making an HTTP request to the WSDL file for each web service. In the previous example, log in to appserver.example.com and ensure that it can access the WSDL files on finance.example.com.

If any server cannot access the other servers in your system, an external request from a Flex application might also fail. For more information, contact your system administrator.

Step 3. Verify access to your servers from outside the firewall

Some servers might have to be accessed from outside the firewall to handle HTTP, SOAP, or AMF requests from clients. You can use the following methods to determine if a deployed Flex application can access your servers from outside the firewall:

  1. On each server that can be accessed from outside the firewall, create a temporary file, such as temp.htm, on the server in its web root directory. From a computer outside the firewall, use a browser to make an HTTP request to the temporary file to ensure that an external computer can access it.

    For example, for a file named temp.htm, try accessing it by using the following URL:

    http://webserver.example.com/server1/temp.htm

  2. From a computer outside the firewall, use a browser to make an HTTP request to the WSDL file for each web service that can be accessed from outside the firewall to ensure that the WSDL file can be accessed.

    For example, try accessing the WSDL file for a web service by using the following URL:

    http://finance.example.com/server1/myWS.wsdl

You should be able to access the temp.htm file or the WSDL file on all of your servers from outside the firewall. If these requests fail, contact your IT department to determine why the files cannot be accessed.

Step 4. Configure the proxy server

In Step 3. Verify access to your servers from outside the firewall, you ensure that you can directly access your servers and server resources from outside the firewall.

After you configure your proxy server, ensure that the deployed Flex application can access web services and other server-side resources as necessary.

Step 5. Create a crossdomain policy file

Your system might be configured to allow a Flex application to directly access server-side resources on different domains or different computers without going through a proxy. These operations fail under the following conditions:

  • When the Flex application's SWF file references a URL, and that URL is outside the exact domain of the SWF file that makes the request

  • When the Flex application's SWF file references an HTTPS URL, and the SWF file that makes the request is not served over HTTPS

To make a data service or asset available to SWF files in different domains or on different computers, use a crossdomain policy file on the server that hosts the data service or asset. A crossdomain policy file is an XML file that provides a way for the server to indicate that its data services and assets are available to SWF files served from certain domains, or from all domains. Any SWF file that is served from a domain specified by the server's policy file is permitted to access a data service or asset from that server. By default, place the crossdomain.xml at the root directory of the server that is serving the data.

For more information on using a cross-domain policy file, see Using cross-domain policy files.

Navigation

Using Flex » Deploying applications

Adobe, Adobe ColdFusion, Adobe Flash and Adobe Flash Player are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries and are used by permission from Adobe. No other license to the Adobe trademarks are granted.