Thursday, January 31, 2008

%Request.GetParameterNames

I was working on an IScript that wrote WML to the browser and needed to pass the query string parameters back to the client as postfields. I thought I would just loop through the %Request.GetParameterNames array and write those parameters back to the client marked up as postfields. When I did this I saw 6 additional parameters:

PSHome
Portal
Node
ContentType
ContentID
ICScriptName

To test this, run the following IScript:

Function IScript_TestParams
Local array of string ¶ms = %Request.GetParameterNames();
Local string ¶mName;
Local number ¶mIdx;

%Response.SetContentType("text/plain");

For ¶mIdx = 1 To ¶ms.Len
¶mName = ¶ms [¶mIdx];
%Response.WriteLine(¶mName | ": " | %Request.GetParameter(¶mName));
End-For;

End-Function;

Now, the part that really, really threw me was how PeopleSoft interpreted the ICScriptName parameter. The code I wrote copied the request parameters to the response as postfields and then posted them back to a different IScript on the same server. After a good hour of troubleshooting, trying to figure out why the browser never displayed the second IScript, I realized that the psc servlet was using the IScript from the ICScriptName parameter, not the IScript in the main URL. In fact, modifying the URL a little bit, I noticed that you can leave off the Record.Field.Event.IScript_Name portion of the URL in favor of ?ICScriptName=Record.Field.Event.IScript_Name (not that you would want to do that).

So what now? How can we work around this %Request.GetParameterNames dilemma? Here is a function that will parse the %Request.QueryString into key/value pairs and print them to the browser:

Function IScript_TestParams2
Local array of string ¶ms = Split(%Request.QueryString, "&");
Local array of string &keyValue;
Local number ¶mIdx;

%Response.SetContentType("text/plain");

For ¶mIdx = 1 To ¶ms.Len
&keyValue = Split(¶ms [¶mIdx], "=");
%Response.WriteLine(&keyValue [1] | ": " | Unencode(&keyValue [2]));
End-For;

End-Function;

Of course, this function does not account for parameter arrays, etc. I'll leave that up to you.

Caveat: I was working on a PeopleTools 8.48.07 instance. I have no idea if this behavior is the same on other PeopleTools versions

5 comments:

Graham said...

Is your dilemma that you did NOT want the 6 other parameters coming back from the GetParameterNames() method?

Jim Marion said...

No. I guess I wasn't clear in stating the problem. I was surprised to see the other parameters since they weren't POST or GET parameters, but I thought I could live with them. The dilemma, the real problem, was what the ICScriptName parameter did. By copying the parameters from GetParameterNames, which included ICScriptName, into a FORM, I was effectively overriding the IScript in the FORM's action with the IScript in the <input type="hidden" name="ICScriptName" value="..."/>.

Anoop Savio said...

I just started my career in PeopleSoft when you wrote this post. And still useful :)

ramky007in said...

Hi Jim,
I am using a Component Interface to access one of the Peoplesoft component to save the data. When I run the CI via App Engine program, it errors out saying "First operand of . is null cannot access %Request.GetParameter("NAVSTACK")"

Can I by pass this %Request call if component is invoked via CI? Will there be any impact?

Thanks
Ramky

Jim Marion said...

@Ramky, I believe NAVSTACK is used to build a list of links inside manager and employee self service components. It is not necessary inside a CI. Whether or not it causes other errors depends on how the component uses the variable that received the %Request.GetParameter("NAVSTACK") value.