Thursday, March 17, 2011

PeopleSoft Test Framework

PeopleTools 8.51 has introduced a new and exciting feature: PeopleSoft Test Framework (from now on PTF). This tool can be used to automate testing of PeopleSoft applications. Unlike other testing automation tools, PTF has the following advantages:

  • PTF is a testing automation tool designed to interact with PeopleSoft. It is quite easy to install and put it up to speed.
  • Tests are stored in PeopleSoft database as metadata. This allows developers to migrate tests between environments, pretty much like any other PeopleTools object.
  • Based on Usage Monitor, testers can determine which tests are impacted by a given application change: upgrade, bundle and/or customization.
PTF seems the perfect tool to automate a large degree of regression testing, thus reducing significantly the effort (and therefore cost) of testing after an application change. Particularly in upgrades, when test cycles are conducted over an over again, PTF may help to reduce the time and increase the quality needed for testing efforts.

There are still some shortfalls of PeopleSoft Test Framework. First of all, tests for PeopleSoft applications are still not delivered in the standard product, although some companies are already offering test bundles for certain modules (we at BNB are looking at offering a bundled service based on the test cases built on our installed customer base).

The second shortfall is the lack of stress testing capabilities. Still, there are plenty of tools on the market to perform this kind of testing.

All in all, it seems a very important step forward in PeopleSoft technology in order to reduce implementation and upgrade times and increase the ROI of those projects.


Tuesday, May 25, 2010

Cloning elements in Global Payroll

I've been lately involved in a couple of PeopleSoft Global Payroll implementations. One of the pain areas in dealing with Global Payroll rules definition is that there does not seem to be an easy way to clone or save an element with another name. Re-entering the element again is not always an option, specially if you are dealing with a formula, array or bracket with several lines.

Just a couple of weeks ago we found out a way in which we could clone elements. Here it is:

  • Create a Rule Package with the elements you want to clone in it.
  • Export the Rule Package.
  • Rename (both pin name and code) the elements.
  • Import and apply the Rule Package you previously exported.

We still think we could make it easier with a bit of customization, by automating export and import of the package rule, as it is on the same database.

Anyway, I hope this is useful. Have you found any other way to do this?

Tuesday, February 23, 2010

Setting Date Variables to Null in PeopleCode

If you try to assign a date variable a null value you will get an error saying that the left and right sides of the assignment are not compatible.

For instance, the following PeopleCode would error out:

Local date &myDate;

&myDate = null;

To perform this kind of assignment, you may use the Date function in the following way:


Local date &myDate;

&myDate = Date(0);

Thursday, February 18, 2010

ExcelToCI under HTTPS with SSL certificate errors

One of our customers was trying to use an ExcelToCI template to load data in PeopleSoft environment which could only be accessed through HTTPS. However, as the certificate in the web server was expired, ExcelToCI would error out whenever the user wanted to create a new template or submit the data to the database.

Obviously, this issue would have been solved by simply renewing the web server certificate, but the customer was not in a position to do this now and we had to seek an alternative solution.

Our solution was to modify the ExcelToCI macros to tell them to ignore SSL certificate errors. To do so, we had to do the following changes on the CreateCITemplate.sendSOAPRequest_GetCIShape() and StagingAndSubmission.sendSOAPRequest_SubmitToDB() functions:
  • Replace the following variable declaration:
Dim xHTTP As XMLHTTP

by

Dim xHTTP As New MSXML2.ServerXMLHTTP40
  • Replace the following variable initialization:
Set xHTTP = New XMLHTTP

by

Set xHTTP = New MSXML2.ServerXMLHTTP40

  • Add the following line before calling the Send method:
xHTTP.setOption 2, 13056 'Ignore all SSL errors


The SetOption call is actually telling the Send method to ignore any SSL certificate error.

Friday, October 31, 2008

How to avoid passwords expiring in PeopleSoft

One of the more often customer requirements regarding security is to implement password expiration. PeopleSoft provides this functionality using the Password Controls component under:

PeopleTools > Security > Password Configuration > Password Controls

This component provides the alternative to enable or disable password expiration controls for all users. Now, what happens if we want a certain user's password to never expire?

There are plenty of situations where we might want this to happen, for instance:
  • The password for the user set in the Process Scheduler or Application Server configuration should not expire or otherwise the system may not work.
  • Same happens with if a user is set as a Guest in a Web Profile.
  • Also, you may want to disable password expiration for PTWEBSERVER, the user set by default to let the Web Server recover Web Profiles from PeopleSoft environment.
Unfortunately, PeopleSoft does not provide the ability of disabling password expiration for a given user. Good news are that it is quite easy to do by setting the last password change date to a future date using the following SQL sentence:

update PSOPRDEFN
set LASTPSWDCHANGE = '2050-01-01'
where OPRID in ('SOLICITANTE', 'PS', 'PTWEBSERVER')

Monday, August 6, 2007

Adding new fields... to an existing record or a new one?

At the very start of every PeopleSoft project we're confronted to the task of defining the Development Standards. One of the recurring discussion points is what to do when we need a new field in a record.

a) Create a sibling record (same primary key), adding the new field as an attribute to that record.

b) Add the new field in the original record.

At first, the a) option seems the cleanest one as it does not modify standard records and it sounds like it will easier to maintain through upgrades and fixes.

However, this option also has its limitations:
  • Querying the table now would involve joining two tables. This leads to additional complexity and performance issues (particularly if customizations have been made by adding sibling records to multiple records in a query).
  • When creating a query, you may need to filter on both the standard record and the sibling one. In that case, you won't be able to use an index on both filters, as the fields are placed in different tables.
  • Adding a sibling records means you need to use an additional scroll area in components showing both the original record and the standard one. In some situations, this may put in a situation where the 4 allowed scroll levels (0, and 1 to 3) are not enough.
Mainly due to performance reasons, my preferred option is b). In order to keep a clearer track for upgrades and fixes, what we normally do is to place new fields in a subrecord defined explicitly for customized fields. In such way, it is always easy to identify the customized fields in a record.

What is your experience on record customization? Which of the two options you prefer?

Tuesday, July 31, 2007

ExcelToCI limitations: when not to use it

Since it's introduction with PeopleTools 8.4x, ExcelToCI has generated excitement particularly among consultants running implementations. Finally there was a tool that allowed consultants with little or no technical knowledge to quickly load data into the system.

Now, as it normally happens in these situations, a good tool may become a bad choice if we are using it in a way it wasn't designed for. Personally, I've seen people trying to use ExcelToCI to run complex data loading resulting in unexpected delays due to the need to build ad-hoc tools for conversion.

What are the most significant ExcelToCI limitations? You may find others, but from my experience, these are quite important:
  • ExcelToCI does not allow to determine the order in which fields are loaded into the application. The order is determined by the tab order defined at the page level in Application Designer.
  • Loading large data volumes becomes unpractical for performance reasons. Excel could easily hang when manipulating spreadsheets with over 10,000 rows.
  • Excel becomes nearly blocked when executing the load. It's difficult to perform any other action on the same workstation, and particularly to load several files in parallel.
  • Can only run in Add or Update mode, but there is not hybrid option to first try to Add and then Update is the row was present.
At BNB, we built a tool called FileToCI (Ok, not much marketing brainstorming here!) that deals with most of these limitations:
  • Lets you choose in which order you want fields to be loaded.
  • Loads from CSV files or database tables, which are much easier to handle than Excel files.
  • Lets you load different files in parallel. Processing is done at the server level, without capturing your local resources.
  • Includes a Hybrid load option, which only adds the rows that were not present before the load and updates the remaining ones.
Again, I'm not saying ExcelToCI is useless. That would be far away from the truth. Reality still is that for setup data load and certain types of conversion, ExcelToCi remains a very intuitive and powerful tool.

What have been your experiences with ExcelToCI? Have you used it for massive data loading?