Problems with Component Interface and COBOL remotecalls

Unfortunately, PeopleSoft still uses COBOL throughout areas of the application. Even worse, there can be online components that call COBOLs from the component processor on pages (looking at you Campus Solutions). There are several different ways that REMOTECALLs may be initiated but we will focus on one here that can cause problems with Component Interfaces.

Here is a Campus Solutions example.

The code behind the button looks like this:

• The user enters some values.
• The user then presses the “Cancel Class” button
• On FieldChange of the push button, a DoSaveNow is called to commit the data to the database
• Then after the save processing completes, the RemoteCall is fired with parameters pointing to the new database rows that were just committed. It is important that the database commit occurs or the COBOL would not be able to see the dirty data in the component memory. The COBOL is running in a different context that the buffer and the only shared pieces of information are the parameters passed in.
• The COBOL runs and picks up those values and calculates a result and the result is display on the page.

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:

• You have an application engine processing some batch results from a file.
• The application engine calls a component interface based on the logic described above.
• Then the Application Engine “presses the button” by changing the value of the field tied to the push button in the CI.

There are two things that may happen here.

1. You may get some kind of error
2. You may get an unexpected or no result

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. Additionally, functions like “doSaveNow” are not processed in CI. So you cannot actually press this button in a CI context even if you were not in application engine. Let’s say you had a Web Service (Service Operation) handler PeopleCode that was calling a CI. You could not actually push the button.

In this example, you would not be able to push the button. You would need to have the CI save. Then your custom code would perform the same RemoteCall.

For components that might have some sort of similar behavior that is triggering behind the scenes, you have do some customization to get it to work. In a situation like this I would add a simple piece of code in the code. 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.