Yes, sort of. Just set up a headless Flash Player on the server. I'm not sure if that will solve your problem, though. What do you mean when you say this one user "calls" your application? How is your current application structured? It sort of sounds like it's just a web site, and this user is programmatically interacting with it through straight HTTP POSTs/GETs and such. If that's the case, running the .swf on the server won't help, since the .swf is not listening for those requests. You *could* funnel those requests from the server to the .swf running in Flash Player, but that seems kind of insane. What exactly are you / your client trying to do?
There are two ways to use the application. One is the normal way where someone gets on the internet and goes to the web page. Once there, they fill in a form and click a button where a second page appears with the results of a calculation. (http://www.dhs.state.il.us:8080/FSCalc/FSInputCalc.do?lang=en) This was written in java/struts and is what I'm trying to rewrite in Flex.
The second way is one client will issue HTTP requests via a program. They have a phone interview and use the information collected to populate an XML stream that they append to the request. Currently, they call a servlet that then will call the calculations. It will then build an XML stream of the results that their program will collect, translate into voice and tell the caller (they are still on the phone) the results.
This method doesn't involve a person accessing the web page, but a program using low level HTTP requests sending and getting the results. It would appear that this doesn't invoke the Flash player on their system so they don't get any return from the SWF file as they never execute the SWF file.
What I want to find out is 1) is there a way to execute the SWF on the server getting around them not executing it due to not invoking a Flash reader or 2) how to get them to do that.
I don't think it's a particularly good workflow.
Even if you want to use Flash for the front-end form, you would be better off not doing the calculations in flash but pass the parameters for processing using another language on the server. That way you can have user interaction using flash, but also automated interaction going through the same calculation stream.
The most flexible way to do this would be to separate the form / user interface side of this and the actual calculations. The calculations can be performed through a standard SOAP web service, and both Flex and this low-level program can use this web service interface.
Basically, If you still need a non-Flex way to perform these calculations, I wouldn't confine that logic to the Flex app, because something like interaction with a headless Flash Player is going to be a pain. I would say that it'd be complicated enough not to be worth considering.
When you say "one user", I assume/hope you mean "one of many"? It'd be a waste to dedicate significant time and effort on a problem that only a few people experience.
I think any solution you use in the way you're asking will probably be an ugly, fragile, difficult hack (if even possible). It sounds like you're going to need to either eliminate the "second way" or implement the same functionality (which I assume you're moving to the Flex client in the first way) in parallel, which is a royal maintenance pain.
Could you have the Flex client call the existing servlet code and only replace the Struts view generation code? If I understand correctly this would at least keep a single implementation of the existing servlet logic. Probably not ideal but you are constrained by your requirements.
Could you rewrite the second application in Flex (or Flex/AIR) too?
I think something unclear here is what your goal/objectives are - not knowing this it's hard to recommend relevant strategies.
I've heard it all now.
For the one user it would appear that Flex can't be used at all. So my choice is to do the program twice (once in java that that user can use and once in Flex for all other users) or not use Flex.
I'm not sure what you are saying. Would the low level program be written in java as our current program is?
But your services could be written in Java , irrespective of the front-end technology. Anyway , if you get Flash to run as a middle-tier technology , I want to be the first to know !
I've heard it all now.
It's not really *that* crazy, provided the right use case. In fact, we did something vaguely similar. We had a reporting application, but we also needed to be able to schedule generation of the reports, à la cron, and automatically send them out. We cronned a headless Firefox pointed at the .swf (hosted on the same server) with some query string parameters to indicate which reports to generate, export them via AlivePDF, and send them to a Servlet (still on the same server) that would e-mail them out. It was terrifying, but magnificent, and it worked pretty well.
However, I don't think it's the right approach here.
By one I mean literally one. That user might be called (literally by phone) from anywhere (800-843-6154 if you are curious) by any number of people.
I think I could have Flex called from the java servlet, but if the one client that is a major deal to us can't get to Flash Reader then they wouldn't have access to the Flex side of it anyway. It is looking very strongly that we will have to abandon Flex for this project. Sigh. Unfortuanately, that one user was not able to test (no test system) the Flex until now after I"ve spent months on it. At least it was a learning experience.
I'm loving this line , it describes software development when you just HAVE to get something done , and the tools may not be there. I'm going to use this line somewhere else if you don't mind.
It was terrifying, but magnificent,
I'll be sure to post it here if it gets to work!
It seems like a line from Doctor Who.
Wish I had a Tardis right now. I'll tell myself of last November that it wasn't going to work.
Keep in mind that there are demos where you change something on one Flex
client and the changes show up on another. The second client could
certainly detect those changes and automatically make further changes that
the first client would see. Is that sort of what you are looking for? The
first client doesn't have to be Flex, it just has to make the same http or
I’m not sure. Would this work in the case where the client uses HTTP requests via a program (not a browser)? They wouldn't be able to invoke the Flex as they don't reach the level where the Flash reader is involved. So they would have to call a second, perhaps java, program that would then reach my server/my Flash Reader to invoke the Flex program.
It seems pretty involved. Our current process is a java/servlets combination where they call the servlets that invokes the java for the calculations and then it presents the results in the form of an XML stream.
I'm not saying it will be easy. I'm also not sure what Flash reader is.
In the demos, there is a shared data set. One client modifies it, the other
client is polling for changes, sees the change, etc. You don't have to use
flex to update the data set.
We had a reporting application, but we also needed to be able to schedule generation of the reports, à la cron, and automatically send them out. We cronned a headless Firefox pointed at the .swf (hosted on the same server) with some query string parameters to indicate which reports to generate, export them via AlivePDF, and send them to a Servlet (still on the same server) that would e-mail them out. It was terrifying, but magnificent, and it worked pretty well.
How did you do it?
I'm exactly in that same situation. I have a flash reporting system that exports to pdf which is great, but we need to schedule reports and be able to provide those PDFs to iPads and such.