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).

1. One of the investment banking firms used database links to capture transactions in DBS Millenium and use PeopleSoft for financial reporting and allocations.
2. 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.
3. 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).

Leveraging PeopleTools 8.4x features in a PeopleTools 8.1x environment

This one is a little more labor intensive, because you are essentially taking the tables in a PeopleTools 8.1x application and mapping them to a PeopleTools 8.4x system. Customers who do this are usually looking for reporting features added in 8.4x, such as run to window, improved process scheduler and report manager, and query enhancements.

If you are focusing on reporting, you do not have to worry about getting anything more than the record definitions mapped so that the reporting tools know how to select data out when doing reports. Again the process of doing the mapping is almost the same as in the previous section (but there are many more tables that you have to look at).

If you are doing this near the time you are doing an upgrade, the data conversion scripts can give you a cue as to how to do this mapping.

Continuing to run an old tools release after doing an application upgrade

You may need to do this if you are in the following situation:

1. PeopleTools has depracated a piece of technology that you want to continue to use (such as message agent).
2. You are not ready to upgrade a 3rd party product that is depracated in a new tools release (such as using Crystal Info instead of Crystal Enterprise... this is the one I was involved with most recently).

Again the process is essentially the same as the second example. You create the database links into the 8.1x environment, mapping from the 8.4x environment that is capturing the data.

Again, If you are doing this near the time you are doing an upgrade, the data conversion scripts can give you a cue as to how to do this mapping.

Labels: Database