ActionSource Code
Once you have defined how you want your Flash application to show up in the reports, and have mapped it out to the different variables (just like you have been doing all along with page-based variables), you can then proceed to the coding of the application.

To get the basic code for using ActionSource, you first go into the Site Catalyst Admin console and select the Code Manager left-side navigation. You can then select Flash from the type of code drop-down box, select a few options, and generate the code. You will then be presented with some code.

This code is the main configuration code for your ActionSource component. You will be able to customize this code to have the visitor’s interaction with your Flash component recorded and sent to Site Catalyst. For instructions on exactly how to incorporate this code, please see the ActionSource white paper.

In the Admin console, there is a second tab the Generated Code section that holds download links to two files.

The ActionSource,mxp file is an installation file for the Omniture components to be used in the Flash environment. The OmnitureActionSource.swf file is a remote code file, similar to the s_code.js file that holds configuration and code for the JavaScript implementation of Site Catalyst.

Flash Components
After you double-click on the ActionSource.mxp file (having downloaded it from the Admin console), the Omniture components are installed and available in the Flash programming environment. You can then drag one of the components (never both) onto the canvas of your Flash application.

The component is now ready for use. Once of the things that you will need to do is give the instance the name of “s” in the properties of the instance (by selecting the component and changing the properties). This will allow you to use “s” as the name of the object, just as you have done in the JavaScript implementation. For example, the pageName variable will be referred to as s.pageName, and prop1 will be referred to ass.prop1. If you want to use a different instance name, you may. However, you will need to change the code to reference the object correctly.

Which Component Should You Use?
As mentioned above, you should never use both the ActionSource and the ActionSource_Embed components in the same Flash application. You must choose to use one or the other. A discussion of each option follows.

The ActionSource Component (Not Embedded)
This component works very much like the code used in the JavaScript implementation. In the code that is compiled into application, there will be reference to an external file, the “OmnitureActionSource.swf” file. This file is similar to the remote JS file (typically called s_code.js) in the JavaScript implementation.

Currently, approximately half of Omniture implementations use this solution. You may want to use this solution in the following instances:

  • When the Flash application is going to be out and available for a long time, and you don’t want to recompile with new code if Omniture comes out with a new update, you can simply replace the .swf file.
  • When multiple Flash applications rely on same remote code file, and you want to be able to update to new code quickly and cheaply. Otherwise, you will have to recompile all the Flash applications, which may be expensive in cash or resources.
  • When you don’t need the application to run outside of you site. This solution is not very portable, so it is best when it is running under your control on your site.
The ActionSource_Embed Component
When using this component, all of the code is contained in the component itself, so it does not reference an external file. It has the complete version of the code built inside, and could be compared to the old “full code” option of the JavaScript implementation, when all of the code was in the code to paste on the pages. This solution for the JavaScript implementation is no longer considered best practices but it is appropriate and used in about half of the Flash application implementation today.

You may want to use this solution under the following conditions:
  • When your Flash application is going to be outside of your control - on a different site, or even downloaded to someone’s desktop. Everything is self-contained and compiled into your application, so it can reside anywhere.
  • When you would rather keep all of the code in one location for portability (might just be easier to manage this way).
  • When you don’t plan on having the Flash application remain untouched for an extended period of time (you’ll probably be updating it and recompiling it at some point anyway).