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
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:
Assets to Deploy
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. This is
especially important if you use the data wizard in Flash Builder
to generate these pages.
For more information, see Creating a wrapper.
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.
more information, see Creating a wrapper.
To support deep linking, you must include
the following files in your deployment:
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.
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.
If your application uses modules, you must
deploy the module SWF files so that they can be loaded.
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.
more information, see Modular applications.
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.
If you use container-based security, then
be sure to update your security constraints to include your Flex
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:
Sound files (such as MP3 files)
Images (such as GIF, JPG, and PNG 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.
If you use the view source functionality
in Flash Builder, be sure to include the supporting files when you
deploy your application. These files include the selected source
code files, the source viewer’s SWF file, HTML and CSS files for
the source viewe, an XML file, and a ZIP file of the source code
that users can download. You must maintain the directory structure
that Flash Builder generates in the output directory.
view source and generate the ZIP file in Flash Builder, select Project
> Export Release Build. Then select the Enable View Source option.
more information, see Publish
Types of network access
Deployed applications typically make several types of requests
to services within your firewall, as the following example shows:
Most of the deployment issues that customers report are related
to network security and routing, and fall into one of the following
Direct access to resources on a web server, such as image
files. In the preceding example, the client directly accesses resources
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.
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
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:
Enter information about the server hosting the web service proxy:
Enter information about your web services or any other services
accessible from a deployed Flex application:
Step 2. Verify access from server to server within your firewall
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:
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:
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:
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
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
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
When the Flex application’s SWF file references an HTTPS
URL, and the SWF file that makes the request is not served over
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
For more information on using a cross-domain policy file, see Using cross-domain policy files.