Unfortunately, Peoplesoft still uses COBOL throughout the application. Even worse there can be online components that call COBOLs from the component processor on pages (looking at you Student Admin). There are several different ways that REMOTECALLs may be initiated but we will focus on one here that can cause problems with Component Interfaces.
Lets say you have a page with a level 1 grid mocked up like this.
This model works fine when the user is interacting with the component using a web browser. However, this structure can cause problems when you want to create a component interface based off that Component and want to mimic that same push button behavior in code.
So lets say you want to do the following:
There are two things that may happen here.
Why is this? Well as documented in PeopleBooks section titled Understanding PeopleCode Behavior and Limitations, when a Component Interface is called from an application engine all the database commits are actually controlled by the application engine. So in the structure of the component, the logic assumes that the dosavenow will actually trigger a commit. However, in the case of the AE calling the CI the commit did not occur when the button was pushed.
For components like this you have to do some customization to get it to work. In a situation like this I would add a simple piece of code in the push button fieldChange peoplecode. This code basically says “if this code is being triggered by a component interface then do NOT run the remotecall.” It looks like this.
If %CompIntfcName <> "" Then /* Run the remotecall stuff */ End-If;
Then in the application engine I would actually trigger the remotecall passing in the same information but pulling the appropriate values out of the CI properties and passing them as parameters to the CI.