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. This is especially important if you use the data wizard in Flash Builder to generate these pages.

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.

View source

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.

To enable view source and generate the ZIP file in Flash Builder, select Project > Export Release Build. Then select the Enable View Source option.

For more information, see Publish source code.

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 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.