XML Publisher Development Guide

California State University

CMS Baseline


Last Revised: 01/20/12
FINAL
XML Publisher Development Guide FINAL
Last Revised: 01/20/12

REVISION CONTROL
Document Title: XML Publisher Development Guide
Author: CMS Central
File Reference: XML Publisher Development Guide_20120120.docx
Date By Action Pages
11/10/11 S Mehta, L DeCato Release of New Document All

Review/Approval History
Date By Action Pages
11/15/11 Review Team Review and Input All
01/20/12 PMO QA Standards Review All
01/20/12 Application Manager Approved for Release All

XML Publisher Development Guide FINAL
Last Revised: 01/20/12

Table of Contents Page Page
Security Considerations for XML Publisher Reports .................................................................................................. 4
1.0 XML Publisher Page Access ............................................................................................................................ 4
2.0 Creating Reports ............................................................................................................................................... 5
3.0 Running Reports ............................................................................................................................................... 7
4.0 Viewing Report Output ...................................................................................................................................... 8
4.1 Security for Bursting .............................................................................................................................. 10
5.0 CFS Application Security Change Control ...................................................................................................... 11
Migrating XML Publisher Reports ............................................................................................................................. 11
1.0 Creating XML Publisher Project ...................................................................................................................... 11
Appendix A: Campus Codes and Abbreviations ...................................................................................................... 14





Security Considerations for XML Publisher Reports
There are three aspects of security pertaining to XML Publisher reports as below:
Creating reports
Running reports
Viewing report output

1.0 XML Publisher Page Access
There are two types of XML Publisher access that will be required in order to perform XML Publisher tasks.
1. Developer Access Ability to develop/maintain XML Reports
Since PeopleSoft has hardcoded PeopleCode for the using XML development, it is mandatory that a
developer requires the role: XMLP Report Developer. A remedy ticket will need to be created for this request
assigned to CFS Security Group. XML Developer access will be limited to 2 expert XML Developers per
campus.
2. User Access Ability to run/view XML Reports
An XML Publisher user will need the following pages in order to run/view XML Reports.
Query Report Viewer Page
Query Report Scheduler
XMLP Report Search
The pages above will be added to the following CFS roles.
CFSCSU_PT_Query_Manager
CFSCSU_PT_Query_Viewer
XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 5 of 14

2.0 Creating Reports
1. To create XML Publisher report definitions, you will need to have access to the XML publisher menu items.
2. Once you are granted menu access to XMLP pages you need to belong to the appropriate report categories
to access and edit specific reports.
Navigation > Reporting Tools > XML publisher ->Report Definition ->Definition tab
For this report the report category is ALLUSER.

It is proposed that the report category ALLUSER be defined as below:
XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 6 of 14

Navigation > Reporting Tools > XML publisher ->Setup Report Category

If the Read only check box is checked as shown for the roles CFSCSU_PT_Query_Manager and
CFSCSU_PT_Query_Viewer in the screen shot above, report definitions that are tied to this category can be
viewed but will not be editable by the specified roles members.
Members that belong to the role XMLP Report Developer will be able to view/edit all reports that are tied to this
report category allowing for campuses to share their design.
Note that we have to use the delivered Role XMLP Report Developer and the underlying permission list
PTPT2600 as this is hard coded in the system.
In addition, if a campus did not want to share their design they can always do so by creating their own report
category as shown below.
In this example a new report category called POMUSER is created so that only users belonging to a Pomona
specific role (for example CFSPO_PT_SchedularNotify_01) have access to any report tied to this report category.

XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 7 of 14


This allows campuses to have complete flexibility for sharing XML publisher reports without compromising on
security.
3. Query security determines which records you can access and use to create Queries when you use
PeopleSoft Query Manager.
4. This query security in turn controls which query you have access to when creating Query based XMLP
reports.
5. Query row level security is extended to query based XMLP reports as well.
This means that queries with Business Units/Setid must have the appropriate security view _CLSVW as prompt
tables. Failure to do so will mean that campuses can see each other campuses data. Note that this is not true for
Level 1 tables as these have a query security record populated in the record properties.
3.0 Running Reports
1. When running query based XMLP reports the list of available reports is based on access groups you inherit
through your permission lists. More importantly you can see and run XMLP reports that are based in record
definitions you have access to.
2. When running non query based XMLP reports standard PeopleSoft process security applies.

XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 8 of 14

4.0 Viewing Report Output
1. When viewing the output of an XMLP report that was run through the Query Report Scheduler or the
Process Scheduler security is controlled by the settings defined on the Report Definition Security page
as shown below.

In this example only the users who have the security role CFSCSU_PT_Process_Manager can view the output of
the report.
The Allow Viewer ID assignment at report runtime checkbox determines if the report requestor can add users or
roles to the report distribution list during run time.
If Allow Viewer Id assignment at report runtime checkbox is checked, requestor can add a new user/role as
shown.
XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 9 of 14


If Allow Viewer Id assignment at report runtime checkbox is NOT checked, requestor cannot add a new user/role
as shown.

XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 10 of 14


4.1 Security for Bursting
When setting up a report to use Bursting option the developer can specify how the report output files should be
secured. That is, who can access the reports when they are posted to the Report Manager.
Access to each report is automatically based on the Burst By field. For example if the report is burst by EMPLID
only those users with access to that specific EMPLID are available to view the output file.
XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 11 of 14

5.0 CFS Application Security Change Control
All changes to CFS security will be migrated to CFS production via the standard COMR migration process. This
process is documented in the CFS Release Management document. The following are the recommended steps to
migrate security objects in to production.
Develop and test your security in the campus development and testing instances.
Package the XML objects, projects.
Complete a COMR Migration Request Form.
Open a Help Desk ticket using a CTI of CMS>CFS>Security Modification Request
Attach the security project/scripts and COMR migration form(s) to the Help Desk ticket.
The request will be reviewed by the CFS Central Security Review team and if approved implemented by
Technical Services based on the standard COMR process. If there is an urgent need to have a change
implemented the CMS Central management and security team can approve changes for immediate
implementation. All urgent changes must then be reviewed by the CFS Central Security team and if not approved
remediation will take place.
Migrating XML Publisher Reports
It is recommended that the XML Publisher reports be created in a development environment and migrated to
FCFSPRD using the existing migration procedures that we have in place,
Any tweaking, if necessary, can be done in FCFSPRD by campus developers who have edit access to the report.
1.0 Creating XML Publisher Project
The screenshots below describe what objects are required to be included in the project.

XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 12 of 14

1. For Query based XML Publisher Reports, first insert the query in the project
Note: If the record is new it is necessary to have query access for that record.

2. Insert XMLP Data Src Defn.
3. Insert the XMLP Report Defn.
4. Highlight the XMLP File Defn and the XMLP Template Defn so that these are also included in the project.

XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 13 of 14

The final project should be similar to the one below

5. Save the project.
6. Click on Tools Copy Project To File and Save the file.
XML Publisher Development Guide FINAL
Last Revised: 01/20/12 Page 14 of 14

Appendix A: Campus Codes and Abbreviations
The following is a list of naming standards that are used to identify campus abbreviations in CFS.
Please Note: 3-digit abbreviations cannot be used for business units or security.
The preferred standard is two-digit, even for development, but three digits may be used when a conflict exists with
delivered Oracle functionality for example, the use of PO for Purchasing and Pomona.
Campus Name Code
Abbreviation (2-char)
Used for Business Unit
and Security Definitions
Abbreviation (3-char)
Allowed ONLY for
development objects.
Bakersfield 35 BK BAK
Calexico 66
Chancellors Office 01 CO COO
Channel Islands 73 CI
Chico 20 CH CHI
CollegeNET PSSA-R25 Interface R25
Dominguez Hills 55 DH
East Bay (now Hayward) 05 EB
Fresno 25 FR
Fullerton 50 FL FUL
Hayward (formerly East Bay) HW HAY
(3
rd
Party Objects: HAD,
HCY, HSR, HFA, HTC,
HSF, and HAA
1
)
Humboldt 30 HM HUM
IDC (Cashnet: Vendor Abbreviation) IDC
Long Beach 40 LB
Los Angeles 45 LA
Maritime Academy 07 MA
Monterey Bay 06 MB
Moss Landing 94
Northridge 70 NR
Pomona 10 PO
Sacramento 60 SA SAC
San Bernardino 63 SB
San Diego 65 SD SND




1
Additional campus prefixes for East Bay (formerly Hayward) are only approved for 3
rd
party objects (e.g., sqr, Crystal, nVision)