Sound Customizing. Clemens de Vos, Epicenter

Transcription

1 Sound Customizing Clemens de Vos, Epicenter

2 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

3 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

4 Epicenter, Revenue 4

5 Epicenter, Headcount 5

6 Some Clients 6

7 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

8 Who is the audience? Name Education Institution and/or Employer Job/Role Experience with PeopleSoft Reason to join this presentation / expectations 8

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 Portability, Database independency ORACLE: Select count(*) from ps_person a, ps_ _addresses b where A.EMPLID = b.emplid(+) ANSI SQL (DBMS independent SQL): SELECT COUNT(*) FROM PS_PERSON A LEFT OUTER JOIN PS_ _ADDRESSES B ON A.EMPLID = B.EMPLID 26

27 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

28 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

29 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

30 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

31 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

32 Standards and Guidelines for customizing EPICENTER PEOPLESOFT DEVELOPMENT STANDARDS AND GUIDELINES Epicenter Date Last Changed: Version: 1.3 Document Name: Epicenter PeopleSoft Development Standards v1.3.doc Authors: Clemens de Vos, Jörg Sander

33 Questions? 33

34 34