To give an update on the Active Wizard Enhancements we were working on last month, we recently finished up all development and testing of the Flex-based checkin/checkout interface against Documentum. We delivered to our client this week, but I wanted to share some of the challenges we ran into, specifically related to running an application using Flash.
At first, this interface seemed like it would be a straightforward implementation, as we thought about just giving the user a Save As dialog box upon clicking Checkout, to save and edit their content, and an Open dialog box upon Checkin, to browse to their new content. However, things became a little tricky because our design did not popup the Save As dialog box immediately after the user clicked Checkout. In the backend, upon clicking Checkout, we would call our web services layer, OpenContent, to communicate with Documentum and check out the document at the repository level. The web services layer would get the content of the document from Documentum first, and then go back to the Flex side and launch the Save As dialog box. Due to this design, the Flash player was not allowing us to popup the dialog box since it was not a result of a direct user input event. It was a result of the content coming back. This is a restriction that was introduced as part of Adobe Flash Player 10 and is part of a larger group of constraints that are known as UIA (User-Initiated Action) requirements. For more information about the changes in Adobe Flash Player 10 that address security, visit the following link:
We found that the only way around this was to alter our design a bit. There wasn’t much we could do within our browser to turn off this security constraint, or anything programmatically within the application to make an exception for this case. What we ended up doing was creating an intermediate Save button that would appear after the Checkout was completed. At that point, the content would already be in memory from Documentum, and when the user clicks Save, all we would need to do is popup the Save As dialog box. Since there were no more intermediate calls or actions from the time the user clicked Save to the time the Save As dialog was launched, the Flash player had no complaints about this.
The other security constraint we noticed was that Flash does not allow you to host a SWF on one domain and have it read data from another domain. In order to accomplish this, you have to add a crossdomain.xml file to the root directory of the web server. This crossdomain.xml specifies what domains are allowed. For example, it would look something like this:
DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<allow-access-from domain="*.company.com" />
On the Apache Tomcat web server, you can drop this XML file into the ROOT web application for it to take effect. However, in the IBM WebSphere Application Server, we had to create a crossdomain.war file that contained this XML file and replace the default root application in WebSphere, with our crossdomain application.
Regardless of what web server you are using, the best way to test that your crossdomain.xml is in the right location is to navigate to the following URL:
If this serves up the content of your crossdomain.xml, you’ve deployed it in the right location.
Please contact us for any questions regarding our Flex solutions.