(This is the conclusion of Stephen Phillip’s two-part discussion on PeopleSoft component interfaces.)
Understanding the Component Interface API
Remember that all of the coding relates back to what the user would do online. The user should mentally make the connection with each line of code.
- GetCompIntfc() = the user clicking on the component in the portal menu
- Updating field properties = enter fields in the search or add of the component
- Get() = clicking “Find” in the search page
- Create() = clicking “Add” in the add page
- Save() = clicking the save button
A good practice is to write each line of code and then perform that action in the browser. This way, the code and the user interaction match.
Limitations
Component Interface technology is not a silver bullet. Some components will not work with a component interface. Personally, I’ve found a work around for every situation that I have run into, but not all of the situations have been ideal.
First, clicking buttons is a simple issue not necessarily supported by component interfaces. The work around is simple and effective. Button logic is coded on the Field Change event, so by changing the value of the field associated with the button, the CI can simulate a button click or at least get the necessary logic to run.
A bigger issue is a transfer. Component Interfaces can only work with a single component. It will ignore any Transfer() calls triggered by a CI. The workaround is to possibly use multiple component interfaces. For example, when hiring a person the user enters personal data and then PeopleSoft seamlessly transfers the user to the job data component for the employment details. When using a component interface, the program must use two different component interfaces one after the other.
The hardest issue to overcome can be the modal windows or secondary pages. Usually, the page runs some code when it returns from the secondary page. In the context of a CI, the code will run as if the user clicked cancel on the secondary page. So, there’s no way to run that code. As a work around, the developer may have to replicate that code with a function on the CI.
Another hard issue is for components with page activate PeopleCode. A CI doesn’t have any ability to specify which page is focused, so page activate code never runs. Sometimes, a component may rely on that code, which breaks a CI solution. A workaround again is to copy that code into a function on the CI where it can be triggered through the automating code.
Troubleshooting
Every Component Interface solution should contain some form of log. Because a CI triggers all of the existing business logic and validation, the CI solution shouldn’t replicate all of validation just to avoid errors. The CI solution needs a way to capture what’s happening and pass it off to the user to analyze and fix any issues.
The best way to troubleshoot a CI is to manually make the changes to the component that the code was trying to make. Most of the time a troubleshooter will see the problem with that one step. The log file can save time for simple common errors. For example, if bad data creeps in and the CI code tries to set an invalid value, a log file can quickly show the bad value and which field is the problem without the user having to replicate it manually.
At Gideon Taylor, we have a standard logging solution that allows the code to easily print the new value, old value, and any messages that happen when changing the value for each field. When an update fails, a user can check this log and see exactly what the code was trying to do and what error messages were encountered as it went through. Being able to see which messages happen on changing fields versus which ones happen during the save makes it even easier to troubleshoot.
