The new %SelectDummyTable MetaSQL

Does anyone know a PeopleSoft developer who didn't ever use a SQL statement like the following one?

select %CurrentDateOut
from PS_INSTALLATION;

Where PS_INSTALLATION could be any single-row table in the PeopleSoft data model.

If you look at the previous statement, the SELECT clause is not retrieving any field from the PS_INSTALLATION table, but just using it to comply with ANSI SQL. The same statement could be written in Microsoft SQL Server like this:

select %CurrentDateOut;

In Oracle Database, as:

select %CurrentDateOut
from dual;

In both cases, the sentences are a better performing option. Both solutions do not require accessing any physical table.

The problem with these solutions is that they are platform specific, and we want to avoid platform specific syntax. Believe me, when you perform a platform migration you suddenly have very present in your mind the ancestors of the programmers who used this type of syntax. So, up to now, we had to stick with the SELECT ... FROM PS_INSTALLATION solution.

Until now. PeopleTools 8.54 introduces a new MetaSQL name %SelectDummyTable, which automatically translates into a platform specific sentences. Our previous sample would be written as:

select %CurrentDateOut
from %SelectDummyTable

We now have a platform independent and well performing solution. What else can we ask for? ;-)

Note: I've checked the online PeopleBooks from Oracle and at this point there is no documentation on this Meta SQL. Still, I've conducted some tests and it seems to be working correctly.

PeopleTools 8.54 will be the last release to certify Crystal Reports

It was just a question of time. In July 2011, Oracle announced that newly acquired PeopleSoft applications would not include a Crystal Reports license. Some years before, in October 2007, Business Objects was acquired by SAP. You don't need to read Machiavelli's Il Principe to understand why the license was now not included.

In order to keep customer's investment on custom reports safe, Oracle kept updating Crystal Reports certifications for those customers who purchased PeopleSoft applications before that date. In parallel, BI Publisher was improved release after release, providing a viable replacement to Crystal Reports, and in many areas surpassing its features.

Now, as announced in My Oracle Support's document 1927865.1, PeopleTools 8.54 will be the last release for which Crystal Reports will be certified, and support for report issues will end together with the expiration of PeopleSoft 9.1 applications support.

PeopleTools 8.54 was just released a couple of months ago, so there is no need to panic, but PeopleSoft applications managers would do well if they start coming up with an strategy to convert their existing Crystal Reports into BI Publisher reports.

Using Global Temporary Tables in Application Engine

One of the new PeopleTools 8.54 features that went probably a bit unnoticed amidst the excitement on the new Fluid interface is the ability of Application Engine programs to take advantage of Global Temporary Tables (GTTs) when using an Oracle Database.

What are GTTs?

The Global Temporary Tables were introduced by Oracle already on the 8i version of its database product. These tables are session specific, meaning that the data inserted in them only lasts until the session is closed (in Oracle Database there is the possibility of using them only until the next commit, but that option is not used by PeopleSoft). The data inserted in the table by each session is not seen by other sessions. In other words, it is a very similar behavior to Application Engine Temporary Tables. The benefit of using a database supported solution rather the traditional temporary tables is better performance, since GTTs are optimized for temporary data.

How is it implemented in PeopleTools?

The implementation in PeopleTools is quite simple. When selecting Temporary Table as the record type, a new option is enabled: "Global Temporary Table (GTT)".

The build SQL generated by PeopleTools is slightly different to traditional tables:

CREATE GLOBAL TEMPORARY TABLE PS_BN_JOB_WRK (PROCESS_INSTANCE

 DECIMAL(10) NOT NULL,

   EMPLID VARCHAR2(11) NOT NULL,

   EMPL_RCD SMALLINT NOT NULL,

   EFFDT DATE,

   EFFSEQ SMALLINT NOT NULL,

   EMPL_STATUS VARCHAR2(1) NOT NULL) ON COMMIT PRESERVE ROWS

 TABLESPACE BNAPP

/

Note: The SQL Build process still creates as many instances of the table as it did with traditional temporary tables. This sounds like a bug to me, as my guess is that the whole idea of using GTTs is to be able to share a table without actually sharing the data, but I may be wrong. In any case, it does not do any harm. Any insight on this? 

Constraints

Due to specific characteristics of GTTs, there are some limitations regarding when they can be used:

• If the Application Engine is run in online mode, then the GTTs cannot be shared between different programs on the same run.
• You cannot use Restart Enabled with GTTs as the data is deleted when the session ends. In its current version, PeopleBooks state otherwise, but I think it is a typo.
• %UpdateStats are not supported. Before Oracle Database 12c, if the statistics would be shared among all the sessions. Oracle Database 12c also supports session specific statistics, which would be the desired behavior in PeopleSoft (from a higher level point of view, programmers are expecting the temporary table to be dedicated to the instance). I guess the %UpdateStats is not supported because Oracle Database 11g is still supported by PeopleTools 8.54 and in that case running statistics would generate unexpected results. Still, the DBA can run statistics outside of the Application Engine program.

Note: As learnt from Oracle OpenWorld 2014, Oracle is evaluating supporting of Oracle Database 12c session specific statistics for GTT’s in a future releases of PeopleTools.

Conclusion

If you are moving to PeopleTools 8.54 and you want to improve the performance of a given Application Engine program, the GTTs may bring good value to your implementation. Please remember that you need to be using an Oracle Database.

Upgrading PeopleTools with Zero Downtime (3/3)

In the past post, we covered the approach we followed to have both PeopleTools versions running at once. In this post we will cover the issues we faced and how we got around.

Missing Tables

Our approach for identifying tables was not perfect. By examining the traces and logs, we missed some tables that were directly impacted by Application Designer (we did not enable tracing while copying the PeopleTools projects as it would have taken too much time to complete, so we did not have those tables in our lists). Fortunately enough, we only had to adjust the list of tables a couple of times and we were up and running.

Sequences

For performance reasons, the customer had created Oracle Sequences instead of using the PeopleTools auto-numbering approach. In order to have the sequences in sync between both databases we followed the same approach we applied to the tables, deleting one of the sequences and creating a synonym pointing to the sequence in the other instance.

Performance

Most of the performance in running SQL statements is impacted by how the database builds the execution plans. The execution plans are generated taking into account the database statistics. When using DB Links, the database on which the SQL sentence is executed does not have statistics information of the linked tables, so the execution plan may not be optimal. This is particularly true for mixed queries involving local and linked tables.

During our testing, we identified a few performance issues which required to make the table physically present in both environments. This was not always possible, but for tables that are quite unlikely to change (for instance Business Unit options), it was definitely an option.

Data Types

Some of the data types used by PeopleTools changed from one release to the other. In our case, both timestamps and memo fields (LONG to CLOBS) had changed types. If the table is linked, only one of the data types could be used. In this sense, we were fortunate, as the data types used by the target PeopleTools release worked correctly in the previous release, so we could use the new ones.

Commit

In earlier releases of the Oracle Database, each insert/update/delete operation done against a DB Link table would commit immediately (and implicitly). This would pose a serious integrity issue. Luckily, both the source and the target database releases supported global transactions (which means that the data is committed when the system explicitly calls the commit command).

Conclusions

In the end, our attempt was successful. However, as you can see from the issues we faced, it cannot be concluded that it will work for all types of PeopleTools upgrades nor for certain customer requirements. Still, I thought it was a creative approach and that's why I decided to share it in this blog.

Upgrading PeopleTools with Zero Downtime (2/3)

Continuing with my previous blog entry, the requirement from our customer was to be able to move users back and forth between the old and new PeopleTools releases until the latter was stabilised.

This naturally required both PeopleTools versions to coexist. Now, as you know, you cannot just install the new PeopleTools release binaries and point them to the new release. Each PeopleTools release can only connect to a database for which the PSSTATUS.TOOLSREL field contains the corresponding version value. But this is not the only problem, also part of the data model and values on the tables changes from one PeopleTools version to the other.

Therefore, we needed a database for each PeopleTools release, with its full stack of Application Server, Web Server, Process Scheduler, etc. The idea was to give users either the new or the old URL to access the environment, being able to rapidly switch from one instance to the other. Now, in order to maintain the data in sync between both instances, we needed to implement some kind of data replication between them, which should only cover the tables not impacted by the PeopleTools upgrade process.

There are a couple of ways in which the PeopleTools tables could be identified. For instance, the PPLTLS84CUR project may probably contain all of them. Another source could be the mvprdexp.dms script. Instead of using those methods, we decided to search for the impacted tables using a regular expression search tool by looking at the logs and traces of the PeopleTools upgrade done again a copy of the Demo environment. Although it required more work, and a few test iterations until we got it right, it allowed us to keep the number of non-replicated tables to a minimum.

When we finally got a list of tables, we let the key user know which functionalities would not be shared by both environments. As it turned out, Process Monitor, Query or Report Manager would need to be used separately. Fortunately enough, those functionalities did not pose a big issue from an user perspective, so we could move forward.

The next step was to decide which replication method we would use. Both databases were Oracle, although on different versions (no version was supported by both PeopleTools releases) (*). For many of the tables, we needed a bidirectional replication, as users were expected to enter transactions in any of the two environments.

There are many products and solutions that provide data replication with Oracle databases. We finally opted for a very simple one, which is not strictly replication: Oracle DB Link. We kept the application tables in the old PeopleTools instance, and then replaced the same tables in the new PeopleTools instance by synonyms pointing to the other instance using the DB Link. Once the new PeopleTools release was stabilised, we would move the physical tables to the target instance and create the DB Link on the other side.

Once we implemented this approach, we started testing. During testing, we faced some challenges, but we will cover them in the next and final post.

(*) This was unlucky. If we were using the same database version, we could have used a different schema for each PeopleTools release, and instead of creating a DB Link, we could have just used synonyms and avoid some of the issues brought by DB Links.

Upgrading PeopleTools with Zero Downtime (1/3)

A few months ago, BNB concluded a PeopleTools upgrade with a quite curious approach. Our customer, a leading Spanish financial institution, had PeopleSoft CRM 8.4 installation running under PeopleTools 8.42. Their CRM application was being used to provide support to their 24x7 call centres, and the only reason they had to perform the PeopleTools upgrade was to be able to update their database and WebLogic releases, as the existing ones were already out of support.

Now, the organisation was going under a major structural change, so the customer wanted to perform the PeopleTools upgrade with a minimal disruption of their activities, as it was difficult at that time to obtain the needed sponsorship from higher managerial levels. In other words, they wanted to perform the upgrade as silently as possible. This translated in two particular requirements:

• Ability to perform the PeopleTools change with zero downtime, in order to avoid any impact on the users.

• Ability to gradually move users from the old PeopleTools release to the new one, practically limiting the impact of any product issue related to the upgrade. In case anything failed, they wanted to be able to move the users back to the old release.

Having performed quite a few PeopleTools upgrades in the past, I knew that following the standard procedures would not help us in providing a satisfactory answer to the client. So, after some discussions, the customer agreed on trying a non-standard way of upgrade PeopleTools. We agreed to do a prototype, test and if everything went well, then move to Production. If it did not work out, we would need to do it in the standard way. As it finally turned out, the suggested approach worked out.

I cannot say it would work for any other combination of PeopleTools and application versions, nor different customer usage of the application. Anyhow, I thought it may be useful to share it with you, in case any of you can enrich the approach with your feedback. In the next post I will describe the approach and in the third and final one I will describe the issues we faced during the implementation. So... keep tuned ;).

OOW14 Update: Oracle OpenWorld 2014 comes to an end

Today was the last day of Oracle OpenWorld 2014 at San Francisco. Even though it started a bit later due to yesterday's Appreciation Event which hosted Aerosmith, Spacehog and Macklemore & Ryan Lewis (which I did not attend, but that's a different story), the day was packed with good sessions. I have particularly appreciated the PeopleTools Meet the Experts session, which allowed me to network with Oracle PeopleTools experts and share points of view with other partners and customers.

From a PeopleSoft perspective, the event has produced some news, but actually nothing unexpected or that was not rumoured on the internet in the latest weeks. Here is a summary of the news that I found more interesting (*):

• Fluid interface was the hottest topic from a PeopleSoft standpoint. As previously seen on this blog, Oracle announced the availability of the first applications in the coming days.
• Fluid is initially intended for casual and executive users, but there is a plan to extend it to the power users. Under my point of view, not only the interface would need to improve a bit in order to achieve that, but also the development should be somehow simplified, as currently designing Fluid pages requires more effort than traditional PIA pages.
• These are features in the roadmap for the Fluid interface: wizards for tile creation, related contents, activity guides and master/detail page template.
• Oracle has no plans to deliver PeopleSoft 9.3. Still, this does not mean that they will stop investing on PeopleSoft (read more).
• I was nicely surprised by the interest shown by attendants for the PeopleSoft Test Framework sessions. This tool has been around for a while, but the customer adoption has been slow. The new Continuous Delivery Model may bring some interest to this tool, as testing should become more iterative.
• On the architecture side, the ability to use the new in-memory features of Oracle DB 12c under PeopleTools 8.54 brings unprecedented performance to PeopleSoft environments. Still, you would need to dedicate a minimum of 100 Gb of memory to the in-memory part of the database SGA, but if you have the money, it seems worth going for it.

This has been a very interesting and intense week. Now, a few days to rest and return home, and then back to work with some new perspectives and ideas.

(*) Keep in mind Oracle's Safe Harbor statement, which practically says that what was presented during the sessions does not express a commitment from Oracle.