Can parameters be put side by side on a screen?

[deleted_user]

I have a stored process with many parameters. My question: Can I place some of these parameters next to each other? Rather than having them show up on my screen one after the other? I'm trying to decrease the length of my parameter entry screen.

Thank you in advance....looking forward to hearing suggestions!

[Cynthia_sas]

Hi:
If you are NOT using Parameter groups for you Stored Process (SP), then I recommend that you check them out. They will give you a TAB for each group, with the parameters appearing one after another on each tab.

The interface that allows the client applications to prompt for parameter values for a stored process is not a "screen" per se; not in the same way that a Microsoft Access database allows you to define a data entry "screen" or a report "screen".

You define the Stored Process (SP) parameters in the Metadata and then each and every client application uses the metadata information to build a method for prompting that is appropriate to that client. So for example, both EG and Microsoft Office use a tabbed property sheet to collect SP parameter information; but Web Report Studio has its own look and feel for collecting SP parameter information and the Information Delivery Portal has another way, using an HTML form interface.

The only way to have a custom SP interface (with parameters "side by side" or with a custom "screen" to collect parameters) for invoking a stored process would be to build a custom front end. However, you would then be moving your stored process outside the world of the existing client applications and into the world of HTML, C++, VB, Java or some other programming language.

You can, for example, invoke your stored processes using the Stored Process Web Application -- which would allow you to design an HTML form as the front end "screen"/interface -- and to the extent that you can design form fields to fit on the browser screen both horizontally and vertically -- you would be able to design a custom interface using this method (for only one example).

So, let's assume that you created a custom HTML form to invoke a stored process called WOMBAT that was stored in the Foundation repository in the My_SP stored proces repository. The HTML to invoke the stored process is shown below in a simple Anchor tag next to a FORM ACTION example -- you sort of have to image what the rest of the form would look like (imagine that the WOMBAT stored process has a lot of parameters):
[pre]
<a target="new" href="http://localhost:9090/SASStoredProcess/do?_program=//Foundation/My_SP/WOMBAT">
Invoke Wombat SP with Anchor tag</a>

<form method="get" action="http://localhost:9090/SASStoredProcess/do?" onsubmit="return false;">
<input type="hidden" name="_program" value="//Foundation/My_SP/WOMBAT">
[/pre]

For more information about the Stored Process Web Application, refer to:
http://support.sas.com/rnd/itech/doc9/dev_guide/stprocess/stpwebapp.html#defaultform

In the same way, you could use another programming language, or something like Java Server Pages or Visual C++ or Visual Basic in order to design the front end. Then the method of invoking the stored process would still be slightly different, as described mostly in the SAS Integration Technologies documentation.

Before you go down the custom front end road, it may be worthwhile to get some stored processes working that can be run in different client applications. If you need help with any of the custom front end examples that are documented, Tech Support can help you out.

cynthia

[deleted_user]

Ummm...thanks! That looks like it might be a lot of work for what I have in mind. I guess the short answer might be, it's more trouble than it's worth.

But, thank you for replying. I appreciate you taking the time to help me.

[Cynthia_sas]

Hmmm, I suppose from your standpoint, it does sound like more trouble than it's worth.

I think my real answer is "it depends" -- I recommend starting with the simple solution or the default solution and see whether that will serve your needs -- then ratchet up the complexity level or jump to a different technology, if the defaults do NOT meet your requirements.

A lot of the people who come to the stored process class are only using Web Report Studio or Microsoft Office to surface their stored processes. Some shops will be EG and Office shops. Another group plans to do all web-based reporting -- but with the Stored Process Web Application instead of the Information Delivery Portal. Then, some folks come into the stored process class already knowing that their Java or Visual C folks are going to build a custom front end. I think it shows how flexible the whole BI platform is.

Better information through technology. 😉 (with apologies to -- was it DuPont -- who had the "better living through chemistry" slogan? or maybe it was an album.)
cynthia