Sound Customizing Clemens de Vos, Epicenter
Introduction Epicenter Enhanced PeopleSoft Implementation Center Founded in 1997 Pure PeopleSoft specialism Both functional and technical expertise Epicenter: focus on HR and Campus Solutions, less on Financials New implementations, upgrade and maintenance More than 14 Application Upgrades / 18 Tools upgrades Partner of Oracle Sponsor of the DEUG Active with rethinking of best practices in development and customizations We do Quality Assurance, audits and Health checks QA and performance task force at Ministry of Defence Health checks at KPMG, TU Delft Global payroll audit at European Investment Bank 2
Agenda Introduction Epicenter and Speaker Who is the audience Quality Assurance in PeopleSoft projects Quality Requirements Example: product quality requirements Pause (5-10 minutes) Maintainability (ready for upgrade) Best practises PeopleCode Best practices Datamodel changes Portability Performance 3
Epicenter, Revenue 4
Epicenter, Headcount 5
Some Clients 6
Introduction Clemens de Vos 25 years IT, 16 years PeopleSoft consultant. Started career as a teacher University Higher Education ROC Secondary school (HAVO/VWO/Gymnasium) Later switch to IT Both functional and technical expertise Founder and shareholder of Epicenter Detailed knowledge HCM, global overview of CS Several assignments in QA, audits and reviews Native Dutch speaker Hobby s: chess, bridge, cycling and running 7
Who is the audience? Name Education Institution and/or Employer Job/Role Experience with PeopleSoft Reason to join this presentation / expectations 8
Quality Assurance Cycle Quality Requirements are criteria for Quality Analysis will be enforced by refines and adjust is input for Quality Measures Quality Measurement drive are proven by Project Execution results in Project Products
Quality Requirements Process dimension Project in time and within budget Efficient maintenance organization etc. Product dimension Static Maintainability Portability etc. Dynamic Performance Availability etc. Client dimension Fitness for use (usability for administrative organization) Management information 10
Quality Requirements, example product quality 1 Upgrade of PS should be easy Less customizations Re-use of delivered functionality Comply to PS application architecture Minimize changes to vanilla PS objects All customizations are easy to identify Customizations: Documented and authorized Flexibility Parameters in stead of coding Easy adding new functionality to users Re-usability of object and components Maintainability Ease of Impact analyses Completeness and actuality of documentation Impact of change should be local Built in tracing Version control 11
Quality Requirements, example product quality 2 Testability Documented and reproducible test cases Representative test environment Portability Database independency Independency of network and machines Connectivity Loose coupling Common standardized interface architecture Detecting changes Data or File transport Error handling 12
Quality measures QA should be SMART (Specific, Measurable, Achievable, Relevant, Time-Bound) Chapter in project plan Measures Adopt methodologies (PRINCE2, TMAP, OOP etc.) Establish and enforce Development guidelines Training and education of staff/project members Design review Code inspection Testing QA audits and System Health checks etc. 13
Maintainability, ease of upgrade Essence of Upgrade: reconciliation of new functionality of PeopleSoft with your customizations Extreme positions: Some limit PeopleSoft to PeopleTools: if you do not use the delivered peaces of the application and develop everything yourself, they claim that there cannot be any conflict during an upgrade to a new version. Some pronounce Customizations as forbidden: with no customizations the PeopleSoft delivered scripts for upgrade are simply to apply and in no time you are upgraded to the new version. These extreme positions are unrealistic and superficial 14
The Essence of application upgrade Most is easy merge: New in peoplesoft; not in old system Custom added in old system; not in new PS version Move back to vanilla where possible Needed: functional background knowledge Decide in analysis/workshop phase before actual upgrade Resolve conflicts (custom change; peoplesoft change) Xlat values (keep inactive flag or description) Page (take new; re-apply change) PeopleCode (take new; re-apply changes) 15
Development Guidelines Recognize easy all customizations Use prefix/suffix for all custom objects (._EPI) Isolate customizations Re-use everything possible Smart documentation is focused: Functional documentation describes setup and configuration choices and the design for use Concentrate technical documentation in Tools itself: Use Description field in objects (fields, records, pages etc.) for meaning and background of customization 16
Smart custom PeopleCode 1 Choose one style: object oriented PC Use always /* comment */ to provide functional background Isolate unexpected impact at other components Distinguish record and component level Record level: data integrity, trigger for interfaces (webservices or logging) Component level: user interface, workflow, calculated fields Isolate, avoid conflicts in upgrade comparison If custom fields present, attach peoplecode there Otherwise: place new peoplecode on virgin fields 17
Smart custom PeopleCode 2 No strings for object references: Wrong: If &recname = ADDRESSES then Ok: if &recname = record.addresses.name then Why? To be found in Where used PeopleCode compiler validates objectnames Possibility of renames (DataMover / App Designer) No hardcoded strings, Use message catalog for error messages strings table for filenames, paths etc. URL table for url and nodes Prefer use of row-init, save-edit, save-prechange, savepostchange pc and concentrate all pc Best chance to avoid comparison conflicts Easiest maintenance Easier for upgrade Better performance (one trip to server) 18
Smart custom PeopleCode 3 Declare all variables explicitly Develop Re-usable code where possible Function library (Funclib..) Application classes Avoid SQLExec statements, use SQLdefinition Centralized, re-usable code Database variations possible Write PC that can handle component interfaces for Conversion Incoming interfaces Mass changes If Not(%CompIntfcName = ) then Separate Global business rules from Country specific rules 19
Smart datamodel changes Use common relational database design principles (normalization etc.) Changes to Existing tables: Do not change primary key Re-use existing fields, if they exist (with same meaning) Make use of client subrecord for identification New (custom) tables: Re-use existing fields Make identification easy by client prefix/suffix 20
What is preferred when you miss a field? We assume that a process change, that make the field not needed anymore, is not sufficient A) Solve it outside the system (spreadsheet etc.) B) Add the field to an existing PS record, where it belongs according normal database design rules C) Create a new table, with a 1 : 1 relationship to the table where it belongs according normal database design rules 21
Add field or new table with 1 to 1 relation to PS table? What if: PS add field in new version? NEW TABLE (1 : 1) Custom conversion & deletion of table Adding business rules -/- +/+ Performance Maintainability Data-integrity -/- (extra (outer) join needed) -/- (More complex SQL in reports and batch) -/- (extra attention needed) ADD FIELD Easy (DataMover rename) No impact No impact No impact Storage -/- No impact # New custom objects Table (2?) Index (2?) None # Modified objects Page Table (2?), Page 22
Portability, Database independency Core characteristic of PeopleSoft Business reasons: Comply to PeopleSoft standards Shared Service Center, different DBMS Future IT changes Exchange of customizations between clients Theoretical? No! E&Y: DB2 > Oracle Stibbe: Oracle > SQL server SSC PeopleSoft ROC Noorderpoort, Alfa, Twente Often ignored 23
Portability, Database independency Use Capitals for Table and Field names SQL text for views SQR Query s SQL definitions (in Application Engine) SQLExec in PeopleCode etc. Avoid DBMS specific syntax: Sysdate, decode() Add_months(), next_day() PL/SQL to_date(), to_char() etc. Use ANSI SQL, in stead of propriety extensions Outer joins ( + ) 24
Portability, Database independency ORACLE specific: select id, decode(status,'a','accepted','d','denied','other') from contracts; DBMS independent: select ID, case (when STATUS ='A' then 'Accepted' when STATUS ='D' then 'Denied' else 'Other') end from CONTRACTS; 25
Portability, Database independency ORACLE: Select count(*) from ps_person a, ps_email_addresses b where A.EMPLID = b.emplid(+) ANSI SQL (DBMS independent SQL): SELECT COUNT(*) FROM PS_PERSON A LEFT OUTER JOIN PS_EMAIL_ADDRESSES B ON A.EMPLID = B.EMPLID 26
Portability, Database independency Use PeopleSoft delivered MetaSQL: Database independent constructs See: PeopleBooks PeopleCode Language Reference Meta SQL) Can be used in view text, SQL objects, queries, App engine, PeopleCode etc. Example 1: %Concat to concatenate fields Example 2: %Substring Example 3: %CurrentdateIn() =system date Example 4: %Coalesce(FIELD, FIELD) Example 5: %DateDiff(DATE1, DATE2) Example 6: %Upper(FIELD) 27
Quality aspect: Performance Many serious issues SANS Many complaints about speed PS Campus used by the biggest institutions Many students, much history, miljons of rows Too less attention during implementations Problems shifted forward to maintenance phase. Maintenance should drive Implementation 28
Quality aspect: Performance Start with Prevention (during implementation) Calculate/estimate size and growth of tables Define storage parameters for indexes and tables Often black hole between developer and DBA 29
Quality aspect: Performance Start with Prevention (during implementation) Database Statistics policy should be known Update statistics after bulk insert or update Program update statistics, where needed, in Application Engine SQR Be aware of temporary tables in batch programs Often NOT delivered by PeopleSoft Not found in 3Cengine 30
Quality aspect: Performance Start with Prevention (during implementation) Measuring is Knowing (well known Dutch expression) SQL trace (at app server or by user) Install Performance monitor and measure each week Activate and use query monitor Built timings in SQR Timings in Application engine (-TRACE 1024) output in process monitor Query on PSPRCSRQST table 31
Standards and Guidelines for customizing EPICENTER PEOPLESOFT DEVELOPMENT STANDARDS AND GUIDELINES Epicenter Date Last Changed: 16-02-2010 Version: 1.3 Document Name: Epicenter PeopleSoft Development Standards v1.3.doc Authors: Clemens de Vos, Jörg Sander
Questions? 33
34