PeopleSoft Missing Key

I’m back from my vacation! It was a wonderful trekking experience – People who came along with me were shocked at my stamina, which I think is at its worst! Back to blogging. This is something that I always wanted to write, and the attribution comes in the beginning – this story is a brain child of one of my friend kartick (He works for ORACLE Corporation - not me!). He doesn’t write Technical stuff, so don’t be disappointed after reaching his blog.

Most of you know that I enjoy working with the application directly from the back-end. I’ve used Meta-Data manipulation more than PeopleTools. The most interesting part was when I created a page using SQL INSERT statements. It was a wonderful sight. All this backend playing was totally alright when you are developing objects, but manipulating application data requires you to be extra cautious. The reason as we all know is that data integrity is maintained in PeopleSoft by the Application Server code. When we insert a parent record and a child record in a PeopleSoft page, it is the responsibility of the internal code to maintain data integrity. A few months back my friend was given the task of uploading some data into the PeopleSoft Test environment, with absolutely no Functional knowledge (Just like me!) he uploaded the data into the child without taking the parent into account. This I think could have been prevented had PeopleSoft provided the capability of Foreign Keys.

Foreign keys, this is what I intend to discuss in some length. PeopleSoft used almost all the delivered capabilities of the database world, why did they miss this? The reason could go something like this – Development training for a record creation is very simple in PeopleSoft, had they implemented Foreign keys then the training will require the consultant to clearly understand the parent-child relation at the very beginning instead of the normal page creation part of it, I don’t think this to be a valid reason for somebody to overlook Foreign keys. The other reason could be that PeopleSoft does not recommend users to update data directly from the backend. What has just happened is that PeopleSoft had to build their integrity code; I strongly feel that we could have used the database delivered integrity to achieve our goal - Efficiency.

The tough times keep coming! This is what I currently do for identifying the all the parents of a given record, I do “Find All Definition References” and then manually try identifying the parent. This could have been easily simplified had integrity been enforced at the database level – Makes life simpler for a technical consultant.

To conclude, Foreign keys must have been provided in the application. All delivered business processes having a clear link between the parent and child record at the database level could have proved valuable. I don’t like being pessimistic, but is there something that I’m missing? I’ll leave the question to be answered by the readers.

I’m currently learning NA Payroll from PeopleBooks (trying hard to be a Functional Consultant). My first impression is – The complexity of the PeopleSoft is not at its development environment level, it is more so at the Business process level. The Enterprise product packages all the requirements and provides a lot of flexibility to the customer, but the amount of flexibility is the problem (not really Customers want more flexibility!). Trying to build flexibility into the application has resulted in expecting parameters for each simple process to manipulate it differently. If I find more time to actually become a Functional Consultant, probably this blog will move into its next domain – Functional Needs of a Customer ;)