Sunday, February 10, 2008

What is an IScript?

It has been a few years since I attended my first PeopleSoft|Connect conference. As a new PeopleSoft developer, I was eager to learn all I could about PeopleSoft's Integration Broker, PeopleTools, and PeopleSoft's web UI. I spent hours pestering the experts (ask Robert Taylor, a prior Integration Broker product manager, and Tushar Chury, a former component interface developer). During one of the sessions I attended, someone from the audience asked a question about integration and the presenter replied, "I would probably create an IScript to do that." I don't remember the question. The only thing that stuck with me was the term "IScript." I had so many other questions for the experts that I didn't ask what an IScript was. Nevertheless, I left the event with a big question: "What is an IScript?" Since I had already taken the PeopleTools and PeopleCode classes and had not heard mention of IScripts, I decided they must be some legacy PeopleSoft technology that I didn't need to learn. To satisfy my curiosity, I looked up IScripts in PeopleBooks and received a... well... thorough definition... just like reading a good dictionary (see Enterprise PeopleTools 8.49 PeopleBook: PeopleCode API Reference > Internet Script Classes (iScript)). Yes, after reading the definition in PeopleBooks, I knew what an IScript was, but I just couldn't figure out why I would want to use one. Now, several years later, I find that I can't work without IScripts. Ajax, pagelets, WML, and SVG provide excellent use cases for IScripts. Each of these "technologies" requires marked up text without the overhead of the PIA rendered component HTML.

I like to think of IScripts as the PeopleTools developer's Swiss Army Knife. Besides a "cutting implement" a Swiss Army Knife might have a leather punch, a screw driver, a can opener, etc. Yes, you can do just about anything with a Swiss Army knife, but it might take you a long time to get the job done. Then, when you are done, the job might not be as satisfactory as it would have been if you had used the right tool. Have you ever opened a can with a Swiss Army Knife can opener? I'll bet you worked up an appetite. Likewise an IScript is the right tool for some jobs, but choose wisely. You can probably replicate the postback behavior of a component with an IScript, but it is a lot of unnecessary work. Likewise, you may have to consider multi-lingual translations, etc.

I compare IScripts to JSP or ASP. Basically an IScript is PeopleCode that has access to the Request and Response objects. Just like JSP and ASP, you, the developer, writes code to read parameters from the request and write information, data, etc to the response. Unfortunately, just like ASP, the response object's write methods only render text. Since the response object does not contain any binary write methods, you will have to ignore the dynamic image generation possibilities (I was hoping to use IScripts to render images stored in a user table, but I haven't figured out how to make that work since the write method only accepts plain text).

How do you create an IScript? For more information, you can look it up in PeopleBooks, but just to vaguely satisfy your curiosity, IScripts follow the same design pattern as FUNCLIBS. An IScript is a PeopleCode function stored in a record definition. The record definition name must start with WEBLIB_. The function can be in any field event of the record definition. By convention, we generally use the field ISCRIPT1 and the event FieldFormula. The function name, however, must start with IScript_ and cannot take any parameters or return a value.

How do you call an IScript? IScripts can be called a number of ways. How you call it depends on the purpose of the IScript. If your IScript is a pagelet, then you will create a CREF for your IScript in the portal registry under Portal Objects > Pagelets. If your IScript is called from JavaScript (Ajax, etc), then you call your IScript using a URL like http://server:port/psc/site_name/portal_name/node_name/s/WEBLIB_name.FIELDNAME.FieldFormula.IScript_name. To make it easier, you can generate an IScript URL using the PeopleCode built-in function GenerateScriptContentURL.

Now that you know what an IScript is, you might be interested in looking at some examples. Chris Heller posted a couple of IScripts that can be used as Bookmarklets. These Bookmarklets allow us, the developer, to exend our existing tool set by writing tools that we can use where we work: in the web browser. On Wednesday, April 4th, 2006, Chris posted a bookmarklet/IScript that will drill into a portal registry content reference from a PeopleSoft page. In his 2006 Open World and 2007 Alliance presentations, Chris showed us how to use IScripts and bookmarklets to turn on tracing and display security information. ERP Associates also has some good PeopleSoft Bookmarklet examples.

211 comments:

«Oldest   ‹Older   201 – 211 of 211
Jim Marion said...

@Vivek, per the error message displayed, some pages can't be framed. The author has code to protect the contents. With that in mind, I assume you are asking how to open this content without the PeopleSoft frameset? If so, did you try passing the True value for the New Window parameter? I suspect that will still show the frame, but you can define a CREF for the iScript and check the box for no template. Another alternative is to add a "break frames" JavaScript to your iScript.

Unknown said...

Hi Jim,
Can we display a peoplesoft pop-up page after user click on the sign in button. I mean the pop up page in the same delivered blue color page where user enters the login credentials. Is this possible?

Thanks,
Raj

Jim Marion said...

@Raj, yes, but the complexity depends on what your requirements. If you require an authenticated session, then you will have to convert the signon page to use Ajax to authenticate rather than a direct submit. If authentication isn't important, then you can just modify the onsubmit JavaScript attached to the signon HTML template in your web server's psftdocs folder.

Anonymous said...

Hi Jim,

I'm trying to invoke a iScript url using Node JS (https-get). The iScript itself when tested through browser, returns a JSON, so I know that it is working ok. However when I do a https-get from Node JS, it is returning an error - Failed processing Browscap file. as it could be missing. Please contact your system adminstrator. I see another person had this error above. But I'm not sure what technology he/she was using.

I'd really like to avoid creating a IB service, only to be called again from my Node JS REST API logic which in turn is called from the API client. It feels redundant.

Is there any other way?

Jim Marion said...

@DS, there is no other supported option. Unfortunately, creating an IB REST service is the recommended approach. The problem is the PeopleSoft webserver today uses browscap to determine device capabilities (mobile, desktop, etc) and it expects to find your browser. If it doesn't, then you must be using an unsupported browser. iScripts are for UI only, and expect a real web browser. Integration Broker, on the other hand does not.

Here are a couple of other options:

1. Change the user agent string to match a common browser string. No guarantees this will work, but it is an option.

2. Define a standard IB integration, not REST, and make your HTTP request to the HttpListiningConnector. Often this is easier to configure.

Anonymous said...

Thanks Jim, actually I did try setting the user agent in the header and it did seem to like it and let me pass through and download the JSON that the iScript was serving - so it does seem like an option for cases where IB usage is not the preferred method.

Piyush said...

Hello Jim,
First of all I would like to thank you for creating a blog where we can get perfect answers for your queries.
We have a batch process build for auto approval of performance document of the employee. This batch process uses CI on the e-performance Approval component.
In the this Component on Component Post Build event, an application package peoplecode EOAW_Monitor.Monitor.awStatusMonitor is being called.

This code is using %Request and %Response. But, these system parameters are returning NULL while processing. I am not getting why system parameters are being returned NULL during processing. Could you please let me know the possibility for the same.

Thanks
Piyush J

Jim Marion said...

@Piyush, %Request and %Response only apply to online PeopleCode and are not available in batch processes. It is quite common to use them in a component. I believe you have two options:

1. Don't use a CI, but rather use AWE directly. Typically an AWE approval component is used to share approval information and interface with AWE. Since you are using a batch process, you don't need the review component, just AWE.

2. Modify the component by wrapping the Approval Status Monitor initialization method in an if block to test the %CompIntfcName similar to this: http://peoplesoft.wikidot.com/forum/t-879793/bypass-peoplecode-if-called-from-a-component-interface.

psspider said...

Hi Jim,

Is it possible to mimic the delivered peoplesoft sign in(PSOPRDEFN.OPRID and password) from the third party application using iscript? Please let me know if this is possible and it would be helpful if you can guide me through the process.

Thanks, Kapil

Unknown said...

Hi Jim,

I am executing the below code from IScript FieldFormula in order to run delivered cobol program using Remotecall before connecting to 3rd party payment center and it is giving "Caught exception: Think-time PeopleCode event (RemoteCall), but a SQL update has occurred in the commit interval. (2,148)" message and unable to proceed. I've tried commitwork and sqlexec("commit") but it didn't help. Please suggest to resolve the issue.

import SCC_EQUATION_ENGINE:Equation;
import SCC_EQUATION_ENGINE:Equation_Exception;
import SCC_EQUATION_ENGINE:Equation_Space;

Function IScript_Function()
&rsSCT = CreateRowset(Record.STDNT_CAR_TERM); /* create Rowset */
&numRead = &rsSCT.Fill("WHERE EMPLID = :1 AND STRM = :2", "10XXXXX", "2200"); /* Fill rowset */

For &sctIndex = 1 To &numRead;

&sEquation_Name = "SFSETVAL";

&sEquationSpaceName = &sEquation_Name | "_REMOTECALL";

&esTuiCalcSpace = create SCC_EQUATION_ENGINE:Equation_Space();
&esTuiCalcSpace.sName = &sEquationSpaceName;
&esTuiCalcSpace.ClearGlobals();
&Rc_Oprid = %OperatorId;
&esTuiCalcSpace.SetGlobal("A_SELECT", "String", "N");
&esTuiCalcSpace.SetGlobal("CALC_CAREER", "String", " ");
&esTuiCalcSpace.SetGlobal("VALUE_FOUND", "String", "N");
&esTuiCalcSpace.SetGlobal("INSTITUTION", "String", &BUSINESS_UNIT);
&esTuiCalcSpace.SetGlobal("ACAD_CAREER", "String", "GRAD");
&esTuiCalcSpace.SetGlobal("STRM", "String", &STRM);
&esTuiCalcSpace.SetGlobal("BILLING_CAREER", "String", "GRAD");
&esTuiCalcSpace.SetGlobal("EMPLID", "String", &EMPLID);
&esTuiCalcSpace.SetGlobal("BUSINESS_UNIT", "String", &BUSINESS_UNIT);

&eqTuiCalcEquation = create SCC_EQUATION_ENGINE:Equation();
&eqTuiCalcEquation.sName = &sEquation_Name;
&eqTuiCalcEquation.sSpaceNameIn = &sEquationSpaceName;
&eqTuiCalcEquation.sSpaceNameOut = &sEquationSpaceName;
&eqTuiCalcEquation.bLogInfoMsgs = True;

REM CommitWork();
SQLExec("COMMIT");

&eqTuiCalcEquation.Execute();

If &eqTuiCalcEquation.iMessageNumber <> 0 Then
MessageBox(%MsgStyle_OK, "Equation Run Status", 8954, 3042, "Equation Run Failed");
MessageBox(%MsgStyle_OK, "Equation Failure", &eqTuiCalcEquation.iMessageSet, &eqTuiCalcEquation.iMessageNumber, "Equation Run Failed");
End-If;

CommitWork();

End-For;
End-Function;



Thanks,
Siv

Jim Marion said...

@Siv, I don't see where you are writing anything back to the client. It looks like you are just invoking the Cobol. Could you move your code to an App Engine and use the ProcessRequest API to schedule the App Engine to run immediately? App Engines don't have commit/think time issues.

«Oldest ‹Older   201 – 211 of 211   Newer› Newest»