PeopleTools Wish List
From TekiWiki
This whole wiki has now moved to http://www.springboardsolutions.com/wiki
Go to this page PeopleTools Wish List
(→Cost of Ownership Improvements) |
(→Improve Cost of Ownership) |
||
| Line 16: | Line 16: | ||
Decreasing the cost of keeping current means decreasing the impact of customisations. There is a body of development standards and techniques created by partners and customers to try to make customisations easy to spot and separate from the PeopleSoft vanilla code. Many of my ideas here are to embed these good practices into PeopleTools and almost make them mandatory. | Decreasing the cost of keeping current means decreasing the impact of customisations. There is a body of development standards and techniques created by partners and customers to try to make customisations easy to spot and separate from the PeopleSoft vanilla code. Many of my ideas here are to embed these good practices into PeopleTools and almost make them mandatory. | ||
| - | 1: Naming conventions | + | ===1: Naming conventions=== |
Virtually every site I have been to utilises a naming convention of prefixes or suffixes to denote custom code. Often this is a 1-3 letter code (usually derived from the company name) followed by an underscore. Each customer has picked a different prefix and a mildly different way to get around the "awkward cases" where a prefix would cause an issue with functionality. | Virtually every site I have been to utilises a naming convention of prefixes or suffixes to denote custom code. Often this is a 1-3 letter code (usually derived from the company name) followed by an underscore. Each customer has picked a different prefix and a mildly different way to get around the "awkward cases" where a prefix would cause an issue with functionality. | ||
If Oracle named a recommended range of prefixes that they do not use in the PeopleSoft apps and never will this would be a good starting point. This fact could be then used to advantage with compares, audits etc. | If Oracle named a recommended range of prefixes that they do not use in the PeopleSoft apps and never will this would be a good starting point. This fact could be then used to advantage with compares, audits etc. | ||
| - | 2: Holding a Copy of Vanilla within the Database | + | ===2: Holding a Copy of Vanilla within the Database=== |
Vanilla PeopleSoft code held separately from any customisations. The vanilla code would remain untouched and custom code would be held separately, so an upgrade could confidently switch the old vanilla code with the new code, leaving the customisations in place. If all three (old vanilla, new vanilla and customisations) exist in the database at once, compares could be much faster and so less costly than at present. | Vanilla PeopleSoft code held separately from any customisations. The vanilla code would remain untouched and custom code would be held separately, so an upgrade could confidently switch the old vanilla code with the new code, leaving the customisations in place. If all three (old vanilla, new vanilla and customisations) exist in the database at once, compares could be much faster and so less costly than at present. | ||
| Line 31: | Line 31: | ||
This scheme could require a lot of changes to the PeopleTools code, so another option would be to hold the versions in copy tables of vanilla, and for Application Designer (and the PIA where applicable) maintains the copying to the resultant PeopleTools tables. | This scheme could require a lot of changes to the PeopleTools code, so another option would be to hold the versions in copy tables of vanilla, and for Application Designer (and the PIA where applicable) maintains the copying to the resultant PeopleTools tables. | ||
| - | 3: Reducing Clashes Between Vanilla and Custom Code | + | ===3: Reducing Clashes Between Vanilla and Custom Code=== |
==Other PeopleSoft Enhancements== | ==Other PeopleSoft Enhancements== | ||
