Accessing DW Tables in FS89ERPT
Issues with the new Financials Reporting architecture

There will always be more PeopleSoft tables than DW tables (see Appendix A). Each
time a PS table is made available in DW, a request and approval process is required.
However, the request may be rejected since no approval guidelines or service level
agreements have been either established or communicated. This request and approval
process lowers the productivity of analysts who are often expected to create reports and
run ad hoc queries with very short turn-around time.

If a PeopleSoft table is not available in the DW environment, analysts must download the
needed data from tables in DW to their much less powerful desktop environment (such as
Microsoft Access or SQL Server), do the same with data from FS89EPRT, and then run
their real query from the desktop. The volume of data downloaded can be in tens, in
thousands, even in millions. This means all individual desktops used by the analysts will
have to be beefed up with the maximum capacity available on the market. In other
words, we will be forced to shift from a thin client reporting environment (as represented
by the current DW environment) to a thick client installation. Individual department will
have to invest/budget for these powerful desktops to meet their analysts’ needs, while the
much more powerful UNIX servers housing the new financial reporting environment
(FS89ERPT) will be underutilized.
An easy and proven approach (see Appendix B) would be to make the HRMS/CS DW tables
available in FS89ERPT. Analysts will then be able to use the powerful Unix DB servers to run
their complex queries that need data from both HRMS/CS and Financial. Doing so will facilitate
the creation of more sophisticated queries utilizing both financial data and DW data in
FS89ERPT. Such queries then become the basis of complex reports by taking advantage of
PSQuery, nvision, Crystal, and XML Publisher -- reporting tools that EFS wants the University
community to become familiar with.
Most importantly, it can be readily implemented in the future reporting architecture without
modifying the exiting components.
The steps to make DW tables available in FS89ERPT are simple, easy to maintain, and have
been often implemented by other PeopleSoft customers:
1) Create a public link in FS89ERPT to point to the DW environment.
2) For each DW table, create a record definition in PeopleSoft as a SQL view. Either IMS or
EAD developer can do this part very easily. We may have to tweak the DW table names to fit
the name length required by PeopleSoft.
PeopleSoft is a meta data driven system – for a SQL table or view to exist in PeopleSoft, a record
definition has to be created in a tool called Application Designer. The Application Designer then
uses the definition to create a corresponding DDL script to build the SQL table or view in the
database layer. The fields associated with a record definition are called record fields or rec fields.
Here’s an example of a PeopleSoft view definition built by the University:
Jennifer Lee (leexx255@umn.edu)
Thursday, April 03, 2008
Page 1
Accessing DW Tables in FS89ERPT
SQL Table or SQL
View name
Fields and their
attributes to be
referenced by
PeopleSoft
When a DW table is defined as a PeopleSoft view, all fields from the table will be included as
record fields similar to those in the above example:
3) The SQL editor within PeopleSoft Application Designer is used to create the SQL syntax
behind a SQL view. It is here where a DW table can be made available in PeopleSoft.
Here’s an example of a select statement used to define a view in SQL Editor:
Jennifer Lee (leexx255@umn.edu)
Thursday, April 03, 2008
Page 2
Accessing DW Tables in FS89ERPT
Select
emplid, name..,
deptid, deptid_descr,
...
From
ps_dwhr_job@ DBLINK_NAME
Unlike this example, it will be a plain select statement selecting all fields from a DW table. The
From clause will be something like ‘PS_DWHR_JOB@dblink_name’ and without any where clause.
4) After the views have been built in Application Designer for DW tables, add the new record
definitions (created for DW tables) to the PSQuery tree(s) so that they are immediately available
in PSQuery just like any other PeopleSoft records.
Records available in PSQuery are organized in Query Trees. Here’s a screen shot to show the
various Query Trees:
For PeopleSoft users who have no access to Application Designer to understand the various
record definitions, accessing the Query Trees allows them a chance to get more information
about the tables they can use in their queries. Below is an example of the record definitions
associated with GL:
Jennifer Lee (leexx255@umn.edu)
Thursday, April 03, 2008
Page 3
Accessing DW Tables in FS89ERPT
Each node is a
record definition in
a Query Tree
If necessary, a new Query Tree (something like ‘UM_QUERY_TREE_DW’) can be created to
group all DW tables for easy maintenance - each PeopleSoft view created for a corresponding
DW table will be a node on the tree.
Once the DW tables are added to a Query Tree, they are available in PSQuery just like any other
PeopleSoft tables or views:
The DW tables can also be utilized in Excel-like nVision reports with powerful drill down
capabilities or in XML Publisher reports with flexibility in output formatting.
5) When there is a change in a DW table (field added or eliminated), the change can be made by
IMS or EAD staff in Application Designer and have the view definition migrated to FS89EPRT –
same procedure as to maintain all PeopleSoft record definitions. There is no adjustment
necessary in the existing architecture for financial reporting.
Jennifer Lee (leexx255@umn.edu)
Thursday, April 03, 2008
Page 4
Accessing DW Tables in FS89ERPT
Appendix A – DW Tables Listing from IMS
Data Group
DWAD
DWFA
DWHN
DWHR
DWPY
DWSA
Table Name
PS_DWAD_COMMUN
PS_DWAD_COMMUN_HS
PS_DWAD_SRVC_IND
PS_DWAD_SRVC_IND_HS
PS_DWFA_COMMUN
PS_DWFA_FDN_FUNDS
PS_DWFA_FDN_SUMMARY
PS_DWFA_GL_INTERFACE
PS_DWFA_SRVC_IND
PS_DWFA_ST_ASSISTANCE
PS_DWEO_PERSON_PRIM_JOB
PS_DWEO_PERSON_PRIM_JOB_HS
PS_DWEO_PERSON_SEC_JOB
PS_DWEO_PERSON_SEC_JOB_HS
PS_DWHR_COMP_PROP
PS_DWHR_DEMO_ADDR
PS_DWHR_JOB
PS_DWHR_JOB_HIST
PS_DWHR_POSITION_DATA
DWPA_POSTING
PS_DWHR_CRS_SESSION
PS_DWHR_CRSE_SESS_DATES
PS_DWHR_EMP_REVIEW
PS_DWHR_SESSN_EQUIP
PS_DWHR_SESSN_EXPENSE
PS_DWHR_SESSN_INSTR_COST
PS_DWHR_TRAINEE
PS_DWPY_DIST
PS_DWPY_FRNG_DETAIL_XX
PS_DWPY_HSA_FD_XX
PS_DWPY_HSA_XX
PS_DWPY_MONTHLY_SUM_XX
PS_DWPY_PAY_FRNG_XX
PS_DWPY_VAC_SICK
PS_DWSA_SRVC_IND
PS_DWSA_SRVC_IND_HS
PS_DWSA_SRVC_IND_RT
PS_DWSA_SRVC_IND_STATIC
PS_DWSA_STIX_XXX3
PS_DWSA_STIX_XXX3_PR
PS_DWSA_STIX_XXX5
PS_DWSA_STIX_XXX5_INT
PS_DWSA_STIX_XXX9
PS_DWSA_STIX_XXX9_PR
Jennifer Lee (leexx255@umn.edu)
Data
Group
DWSF
DWSR
DWTA
DWTR
DWCP
DWIN
DWNC
DWPC
DWSL
DWSP
Table Name
PS_DWSF_MT_HS
PS_DWSF_SF_ACCTG_LN_XX
PS_DWSR_CLASS
PS_DWSR_CLASS2
PS_DWSR_COURSE
PS_DWSR_FACILITY
PS_DWTA_CRSE_TUITION
PS_DWTA_CRSE_TUITION_MT
PS_DWTA_CRSE_TUITION_PR
PS_DWTA_STDNT_CRSE
PS_DWTA_STDNT_CRSE_MT
PS_DWTA_STDNT_CRSE_PR
DWTR_STAFF_INFO
DWCP_BUDGET_CATEGORIES
DWCP_BUDGET_CODES
DWCP_DETAILS
DWCP_FUNDING
DWCP_HEADER
DWIN_EQUIP_TRAN_HIST
DWNC_CRSE_SECT
DWNC_INCOME_XX
DWPC_PROGRAM_DEPARTMENT
DWSL_ITEM_TYPE_CROSSWALK
DWSL_JV_TRAN
DWSL_LOAN_ATTRIBUTE
DWSL_LOAN_TRANSACTION
PS_DWSP_CUFS
PS_DWSP_FUNCTION
PS_DWSP_ROOM
Thursday, April 03, 2008
Page 5
Accessing DW Tables in FS89ERPT
Appendix B – The Use of DBLinks to Bring in External Tables Is Not New to PeopleSoft
Below is a discussion of this technique summarized by a well-respected PeopleSoft consulting
firm: (http://blog.greysparling.com/2005/07/tricking-peoplesoft-to-do-what-you.html)
Friday, July 22, 2005
Tricking PeopleSoft to do what you want - Part 1
This is a topic that deserves several posts, because there are several ways to trick the
PeopleSoft application to do what you want. The first posting is a discussion of Database Links.
Database links has allowed many a PeopleSoft customer to get around limitations in release
levels, product integration, and a wide variety of other things. Here is a sampling of things that
I've been involved with over the years (the earliest example coming from Financials 1.1 in 1993).
* One of the investment banking firms used database links to capture transactions in DBS
Millenium and use PeopleSoft for financial reporting and allocations.
* Many PeopleSoft customers used database links to allow them to take advantage of features
in PeopleTools 8.4x while keeping their application on PeopleTools 8.1x.
* Yet another PeopleSoft customer used database links to allow them to continue using a
depracated 3rd party product with PeopleSoft integration after they completed their upgrade.
Because PeopleTools uses record definitions as a layer between the physical table structures
and the application logic, PeopleSoft customers have a lot of flexibility as long as the database
link or view matches the dictionary of the database. A motto in the early days of PGS was "if you
can't do it, use a database link or a view (views will be discussed at length in a future posting).
Here is how customers used database links to accomplish the previously mentioned tasks.
Using another system's tables in the PeopleSoft application
This is the easiest and most straightforward of the three use cases to solve. You take a look at
the record definition in the PeopleSoft database (in this circumstance, it was the ledger table).
You use the record name and field names in the record definition and you create a database link
that has the same table name and fieldnames in it. You then look at the other system to
determine how to source it. Much of the logic is similar to creating a view. You hard-code what
you need, and you perform joins and unions to cause the fields to supply the appropriate values.
In the Millenium case, they had to do a union 12 times, because each row in the millenium ledger
table had an amount column for each period (whereas PeopleSoft has an additional accounting
period column and stores all amounts in the same column, but on different rows).
Jennifer Lee (leexx255@umn.edu)
Thursday, April 03, 2008
Page 6