Blogging About Oracle Applications

About Java class, HTTP POST and viewContentURL

As of PeopleTools 8.52 it is possible to use REST services for POST/GET functionality. However what do you do if you are on an older PeopleTools version, but still need to make a HTTP POST and then GET the response? To solve this, we created a Java class that was called from PeopleSoft. The Java class handled the POST/GET of a token and returned the response to PeopleSoft.


The Java code:


public class UrlToken

public String getToken(String PSurl)

String token = “”;
URL url = new URL(PSurl);
URLConnection conn = url.openConnection();
InputStream contentFileUrlStream = conn.getInputStream();
BufferedReader buff = new BufferedReader (new InputStreamReader(contentFileUrlStream));
token = buff.readLine();

catch (Exception e)

token = “Error: ” + e;

return token;


In PeopleSoft we used the following code to retrieve the call the Java class:

&java_test = CreateJavaObject(“UrlToken”);
&java_message = &java_test.getToken(&TokenURL);

So now, the URL needed to be opened using the really long URL string in FileNet. The string was 366 characters long to be precise. Even though there is no mention of a limit of the number of characters you can use with the function ViewContentURL(), it still wouldn’t open properly. A hint that the URL was too long, was the fact that the URL table also was unable to accommodate this string. The workaround was found in the use of an iScript.

The PeopleCode to generate the link:

&myscripturl = GenerateScriptRelativeURL(%Portal, %Node, Record.WEBLIB_XXXXX, Field.XXXXX, “FieldFormula”, “IScript_OpenURL”, XXXXXXXXXX.DESCRLONG);

The iScript contains:

&tmpVar = %Request.GetParameter(“DESCRLONG”);

One more thing to note is the fact that the “&” character inside the URL first needed to be replaced (in this case with %26) before sending it to the iScript, which then needed to be replaced back again (&tmpVar = Substitute(&tmpVar, “%26″, “&”);) before calling %Response.RedirectURL().

Many thanks to Dineke Ploeg who managed to figure out the Java class and the iScript solution.

Posted under: Technical

Tagged as: ,

One comment

  • Jeffrey, thank you for sharing a Java example. It is good to see people reaching outside the PeopleCode box. %IntBroker.ConnectorRequestUrl is great for GET, but not for POST. I have POST’d data through Integration Broker before using a transform to convert posted data to non-XML, but I won’t say it is easy. Personally, I’m a big fan of commons-httpclient for this type of thing, which is similar to your solution, but doesn’t require you to code the lower level HTTP protocol information.

    I had a couple of questions about the solution presented in this blog post:

    1. In your Java code I can see you reading the response, but I don’t see you actually POST’ing data. I would have expected a call to getOutputStream() as well as some HTTP request headers such as Content-Type, etc.

    2. It looks like you are fetching a URL from FileNet, and then passing that URL into an iScript. The iScript does a redirect to that FileNet URL. Are you using EncodeURLForQueryString to convert “&”, etc?

    3. What event is calling the Java class? Is it a button FieldChange? If so, did you try using %Response.RedirectURL in the FieldChange event itself? As an alternative to FieldChange, did you consider using an HTML Area with a Derived/Work record on the page in place of a button, and then update the Derived/Work field with HTML for a link or button on RowInit so that the URL is pre populated in RowInit? That way it uses standard HTML/browser behavior to launch the FileNet target.

Leave a Reply

%d bloggers like this: