We're just starting to look at the big picture regarding WF as a reporting solution. We're very comfortable using HTML and Java technologies to deliver solutions for our users and would like to integrate WF into our development process.

My first thought with WF is to use it as a reporting tool only and leave the interface stuff such as launch pages and non-report complexity to the pages we develop outside of the WF tool.

I've done a few simple examples and I like what I see in this approach but the junior developers who worked initially with IBI during the setup phase did everything within the WF toolset because that's how IBI taught them to develop reports. I'd like to move away from this approach but can't be comfortable due to my lack of experience with WF.

Will I eventually encounter issues that force me back to using WF for the end-to-end solution or can I stick to thinking of WF as just the report development tool?

BTW - We don't plan on using anything other than the basic WF report server.

Thanks for any insight you can provide.

-EJL

EJL, the environment you're describing has a formal name in the wf world, its called 'Self-Serv Application'; Self SErv sites are a spectacular way to deploy your wf app. Your developers have been taught to work totally w/in the toolset, because its a great way to get up and running. But the skills they learn are still all usable and important and the fexes they write still all usable within the 'self serve' world.
What differs is the nature and location of the launch pages..
The launch pages would be directly under your inetpub/wwwroot, for example, if you use a win server.
The form action on such a launch page will call the wf engine directly,and the fex. Parms pass directly from your launch page , etc. And the overall form syntax is a little different. SS sites are fun to build, and can be as creative in look as your imagination.
i'm not sure what you mean by 'we don't plan on using anything other than the basic wfrs'..does that mean you don't plan to use mre, or caster?
BTW Whats your environment? (can you put that in your signature, plz)

This message has been edited. Last edited by: susannah,

Thanks for the reply. It's nice to hear we're not going against the grain too much. With our requirements and skill sets I think the "Self-Serv" approach is what will fit best but being new at WF I'm not knowledgable enough to know for sure so a second opinion seemed like a good idea. There's no substitute for experience and this forum seems to be the best place to find that.

We've talked with IBI on these things but we always get a salespitch for their other products without any real indication they understand our situation or requirements. That makes it hard to take their recommendations seriously.

Our environment setup right now is a little goofy due to where we are in our development projects (it's really a long story) - 5.2 with IIS/New Atlanta in a psuedo production environment and 7.1 with Tomcat as the setup I'm learning and that we plan to use.

you might like to hire a consultant from ibi's consulting division for a game plan layout. different division...different p.o.v.

That might not be a bad idea. I'm late to the game with our interaction with WF but I know we've used some IBI developers to write reports for us in the past. Right now reporting with WF is just a tiny part of a much larger project and I think it's been left alone due to no one having time to figure out where we want to go with it as an enterprise reporting solution (as opposed to delivering a couple of reports)

My project is just about ready to start and I see us using WF pretty extensively to produce reports. That's why I'm trying to get things set up a little better and to get some real idea as to the direction we should go with WF.

I totally understand the different POV. Two developers recently came back from a WF class where the instructor told them if they did things "right" they would never need to develop reports using the code and could do everything with the GUI. That's a direct contrast to the experience of one of our in-house developers and to the advice of the IBI supplied developers we've used in the past. I guess it's all in what you are trying to sell.

Susannah,
I'm first quoting a portion of your response to EJL on 01/30/2006:
-------------(beginning of quotation)--------
The launch pages would be directly under your inetpub/wwwroot, for example, if you use a win server.
The form action on such a launch page will call the wf engine directly,and the fex. Parms pass directly from your launch page , etc. And the overall form syntax is a little different. SS sites are fun to build, and can be as creative in look as your imagination.
----------------(end of quotation)----
This raised some questions of my own as I am currently trying to solve some issues here involving security using IWA with WF 5.3.2 on Windows XP. Some of this might be subject for a new topic but for now I think there are a couple of basics that I want to get ironed out.

First, is it not true that a launch page should sit under approot (where cgi alias bas been set up)? Also, even though this launch page is constructed with the help of Resource Layout Manager (resulting in both .fex and .htm files), is it not true that hyperlinks are then pointed to the above mentioned htm file? So far then when a user is presented with the resulting window isn't it true that the WF Reporting Server has not yet been called? It has been my understanding that the WF Reporting server is not called until a fex is executed --presumably when a link on the html form is activated. Please correct me where I am going astray. I'm noting your words about "the form action on such a launch page will call the WF engine directly..." etc.
Most conversation threads that I have read on this forum (and have read quite a few), have either been written by, or for the understanding of those who either use MRE or come into Self Serv Apps with a WF sign-on page. I am in neither category with the use of IWA since the user is presumably already authenticated before ever reaching a self-serve app. Therefore the launch page that I am proposing would NOT be a typical sign-on page with IBIC_user and IBIC_pass.

With this in view then is it appropriate to have an html front-end page which would then have a fex-calling hyperlink in order to have the WF Rept Server know who you are so that the user may then be dynamically directed accordingly? This is all very basi I know but I still fear there's some key thing I'm missing.

yeah, you're really confusing apples and oranges.

Maybe some clarification is in order: (first EJL then Foccrawler)

EJL: There is nothing wrong with your approach, and yes there may in fact be issues that may force you back to the layout tool. The layout tool does three important things for you:
1) it produces a html page for parameter prompting (you can do this with any html builder)
2) it can provide dynamic values for select boxes (you can do the same thing with JSP's and JavaScript)
3) It will prepare the parameters before it passes them back to Webfocus. Specifically, multi-select list boxes. You can duplicate what you need to ensure the parameters are passed properly, but you may have to run a couple of tests to see the end result, and build JavaScript to perform the operation. What ever you do, DO NOT recode the report to loop for multiple values from a multi-select. It is far more trouble then what its worth, and you will be preventing yourself from having the choice of using dev studio to maintain those reports in the future.

As far as using the dev tool or not, you will find that this forum seems to be more comfortable using the edittor then the dev studio report painter. You will also find that any IBI consultant that has been around for a while will probably feel more comfortable in the code then the painter as well. This is really more a matter of prefrence. People have been using the language for many years before dev studio was available. I don't blam anyone for their choice, so long as they are comfortable with the product. That being said, the instructor was correct in that you may not have to venture from report painter to get the job done. I personally have been using the focus language for over 17 years, and I prefer using dev studio and report painter then typing ... that's just me ... I hate typing (although you wouldn't guess that from the size of this post). I have found there is very little to no reason for me to have to venture to code. If your learning the tool, take the time to learn it properly. If your an old dude like me, it is there if you take the time to find it.

Foccrawler: Go to the documentation site and download the security manual for your version of WF. Setting WF for IWA (cgi only) is not difficult. If your using the servlet version, then look for TRUSTED authentication in the same pdf file. It is documented very clearly how to set these up.

As far as WF and Html - depending on your version - the html file may call webfocus if you have a dynamically populated select or list box. Other then that, you are correct in that WF will not be called if you are calling a html page via an alias reference under IIS.