[searchandfilter taxonomies="search"]

Your security options are set improperly. Please contact your security administrator.

Hit this error message earlier and noticed that no search engines had the answer so I wanted to share.

When running App Engine from a command prompt or from within App Designer, you get a dialog popping up with

Your security options are set improperly. Please contact your security administrator.

The same error does not popup when you login to App Designer or Query or other 2 tier tool though.

The answer is that somehow you ended up with the PS_SERVER_CFG variable set in your current environment and psae.exe is getting confused as to whether it should be running under the process scheduler or not. Tools like Application Designer don’t get confused because they never run under the process scheduler.

Labels: 2010, PeopleTools, Support

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Tuxedo Listening on Multiple IP addresses

When you create a domain for a PeopleSoft application server, the default configuration for the Tuxedo listener is a variable called %PS_MACH% (which expands to the hostname of the machine). When the domain is booted, the hostname is resolved into an IP address and that is what the Tuxedo listener will bind to.

This is generally what you want for the most common scenarios, but there are cases where you want to change it.

Binding to localhost

I used to do lots of PeopleTools demos in the PeopleSoft corporate visit center when customers came to see what new things we were working on. That meant getting up from my office over in building F and walking across the campus over to the corporate visit center in building A. As a general rule, I always kept my laptop running when walking between the different buildings on the PeopleSoft campus ⁽¹⁾, partly because it would take so long to boot up an entire PeopleSoft demo environment.

Since I would end up changing IP addresses when I switched buildings, I would always set the Tuxedo listeners to listen on localhost. If I had left them on %PS_MACH%, the Tuxedo listener would still be bound to the IP address I had in my office in building F, not the new IP address I would receive when connecting in building A.

Multiple IP addresses

Binding to localhost worked for my scenario, but binding to localhost means that you can only connect webservers running on the same machine as the application server.

An alternate strategy is to use the special IP address 0.0.0.0 in your Tuxedo configuration. That tells Tuxedo to bind to all IP addresses on the machine. That is handy not just for our scenario of changing IP addresses, but also for situations where you have multiple IP addresses on your server. That could be from multiple NICs (network interface cards), virtual IP addresses or some other exotic configuration.

Once you do that, then your PeopleSoft appservers will survive what IP address reconfiguration that gets thrown at them without needing to restart your appserver domains.

1) I became semi well known around PeopleSoft headquarters as the only dork that kept working while walking around, but not as well known as the one PeopleTools developer that used to walk around wearing a black cape. I’m still not sure if that was supposed to be a magician’s cape or Count Dracula.

And no, I never dropped a laptop or tripped 🙂

Labels: 2010, psadmin, Sysadmin, Tuxedo

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Query Tip of the day: Creating a Query from a PeopleSoft Component Name

One of the biggest challenges of end-users is to figure out where the data they want to query against resides. This is yet another tip from our “Advanced Query Tips and Techniques” webinar. By combining the PeopleCode Query Classes with knowledge of the PeopleTools tables underlying the component definition, you can provide a page that allows queries to be easily created.

Getting the Records to put in the Query

Probably the most important part of this is to figure out what records are in a component (and then subsequently weeding out the extraneous records from the list). This information is stored in the PSPNLFIELD and PSPNLGROUP records (the PSPNLGROUP record tells you the list of pages you need to look at, and the PSPNLFIELD record tells you what records and fields are on those pages.

Here is sample peoplecode that will log the list of records from a component.

Now, let’s get to the good stuff

Instead of extending our code to get the records to include in the query, we will start with some code to create a simple query definition, and then extend it accordingly. Here is the code to create a “Hello World” query against the GL_ACCOUNT_TBL record.

Add multiple fields to Query

The next step is to extend our code to add multiple fields to the query definition. For the purposes of this step, we are hard-coding the record alias to be “A”, and passing in the field name for both the query fielname and query field heading.

Here are the modifications to accomplish this.

Determine what fields to add the query

The next step is to add the logic to determine which fields we should add to the query from the current record. As the goal is to identify the records for a starting point, we are taking the approach of adding the key fields of the current record to the query.

This information is stored in the PSRECFIELD table, in the USEEDIT field. This field is a bitmap integer where each base-2 position is a switch for a different attribute.

Here are the modifications to accomplish this.

Dynamically add records to Query

Now that we’ve got a single record and its key fields being added to our query, the next step is to add more than one record by selecting against the PSPNLFIELD and PSPNLGROUP records.

In addition to putting in the appropriate selection and looping logic, it is important to keep track of the alias by which the record will be referred (this ensures that logic for adding the selected fields puts the fields in the proper place). To accomplish this, we are using the Char peopletools function and adding 64 to the index value (65 is the ascii value of “A”).

Here are the modifications to accomplish this.

Expanding to handle more records

Because most components contain a lot of records and fields that do not match the key structure of the component, we limited our logic in the prior step to only bring in the GL_ACCOUNT_TBL. At this point, we will expand it to determine what keys are required from the search record, and then only include records that match at least one field from the search record.

To accomplish this, we will be looking at the PSPNLGRPDEFN record, in the SEARCHRECNAME field. The code creates an array of fields, and then a separate function will compare this array to an array that contains the list of fields of the current record to be added to the query.

Here are the modifications to accomplish this.

Expand to support more complex components

The last step is to address some complexities that come from more complex component definitions. These issues include the following:

Components with search records that don’t have any keys (e.g. INSTALLATION table)
Related Displays

The related display information is also stored in the FIELDUSE field on the PSPNLFIELD record, but in a different position in the bitmap. For the search records that don’t have any keys, we took the shortcut of taking the first record in the component and using its keys to drive what gets included in the query.

Here are the modifications to accomplish this.

Last Step – Create a Page

The last step is to create a page to allow users to create the queries by picking a component name.

You can go to the project home page to pull down the whole project for your own use. When doing this, you will want to open up the component definition in application designer and use the wizard to add it to the portal registry and add it to one of your permission lists for testing.

Potential Enhancements

The code discussed here does have a number of places where it should be enhanced as part of deploying it widely. Those can be viewed here.

Labels: PeopleCode, Query

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Query Tip: Updating the Effective Dates of In-Tree Criteria

One limitation of PeopleSoft Query is that when you use “In Tree” criteria, the effective date of the tree is forever stored in that criteria. When reading through the release value proposition of PeopleTools 8.5, I was thinking that feature to dynamicall prompt tree-nodes at run-time was going to also address this limitation. Alas, that was not the case.

Fortunately, through a little bit of PeopleCode, this can be rectified relatively easily.

Cool. Show me the stuff

I decided to implement this using application engine, since most organizations would want to update the effective dates of the queries periodically (most likely on a nightly basis). To simplify the content of this project, I wrote it to process any queries that have GS in the first two characters. You can look at the contents here.

Step 1

The first step is to create the app engine program and put in some PeopleCode to prove you can open up a query with it. Here is that code.

Step 2 – Find the Criterion

The next step is to walk the query object to find its criterion. Here are the modifications to step 1 to log the fieldname of the first piece of criterion.

Step 3 – Loop through all criterion

Now that we know how to access the criteria in a query, we will want to loop through it to do our work.

Here are the modifications to loop through all the criteria and log the field names.

Step 4 – Evaluate Criterion

Now that we can see all the criteria, we need to process only the in-tree criteria (since that’s all we care about for updating the effective date).

Here are the changes to process the criterion and determine whether it’s in-tree criteria. Note that this code has been put into a new function to simplify readability.

Step 5 – Get the Criteria String

On of the things that isn’t documented well, is exactly where the criteria is stored. I spent a little time walking through the debugger in the application designer to determine that it’s in the expr2constant1 property as a comma separated value string.

Here are the modifications to log that value.

Step 6 – Decompose the criteria string

The next step is to take the contents of the exprconstant1 attribute and break it apart into its component parts. This is done using the split function to create an array of values.

Here are the modifications to accomplish this.

Step 7 – Find the new tree effective date

Now that we’ve decomposed the criteria string and know what tree we’re using, we have the ability to determine the current effective dated version. This is done by selecting against the PSTREEDEFN table using the keys of the tree.

Here are the modifications to find the most recent effective date and apply it to the appropriate place in the criteria string and log it.

Step 8 – Save the updated query

Now that we’ve determined how to update the effective date in the criteria, it’s time to save that change back into the system.

Here are the modifications to accomplish this.

Final Step – Loop through the queries

So far, we’ve only been processing a single, sample query. Now it’s time to expand this code to look at all queries that start with our prefix of GS.

Here are the modifications to accomplish this. And, without further ado, the culmination of our work without showing the diffs.

Limitations / Opportunity for Enhancements

There are several areas where this code should be enhanced as part of putting it into place in your environment. You can find a list of them here.

Labels: query code tree effdt

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Increasing System Availability with PeopleSoft

System Availability. This is a very important topic, that has received a lot of attention, especially in the area of handling system failover, redundancy, and disaster recovery. This is obviously and important topic, but for most organizations, represents the smallest fraction of system outages with their PeopleSoft applications. It is the planned outages where an organization needs to kick people off the system to perform system administration functions that represents the majority of downtime for most PeopleSoft environments, and the one area that we will discuss in more detail in this blog entry.

System Maintenance and Downtime

In a PeopleSoft environment, there are 3 main drivers that drive planned outages:

Minimizing online access during normal batch windows.
Performing system administration functions, such as backups
Applying PeopleSoft maintenance or performing a PeopleSoft upgrade

The real goal of the outage is to ensure that end-users are not accessing parts of the system that are being affected by the processing, maintenance, or upgrade.

It’s just the way it’s done…

Because your PeopleSoft application is architected and managed as a single entity, most organizations need to block access to the whole PeopleSoft application regardless of what pieces they are administering. Quite often this is accomplished by having a web server that services the general population, and a different one that services the people performing the administration. When the system is unavailable to the general population, that web server is simply brought down.

So, how do I reduce Downtime?

Well, you’re never going to be able to eliminate the need to have an outage. You’re probably also not going even have a dramatic impact on the amount of time you need to restrict access for your batch windows, backups, or upgrades without spending a lot of money on hardware or additional resources.

But don’t despair. The way to look at this problem is not at the overall system level, but by breaking it up into the different areas that you wish to manage separately. For example, instead of bringing the whole system down because you are performing maintenance on Purchasing (see the following notification), just block access to the Purchasing entities, while allowing access to other functions, such as expense entry, to occur.

The following page is an example of how an administrator might bring parts of a PeopleSoft application down while leaving the rest up.

There are 3 steps to the process:

Identify and group together the parts of the system you want to manage together
Provide a user interface where administrators can block or grant access to those parts of the system
Provide a means where those pages look to the rules to either block or grant access

Implementation Options

Because we recently released our ERP Firewall for PeopleSoft, we quickly recognized that all 3 of these steps are already part of the feature set provided by the product. This means that after a 1-hour installation, our customers can start managing system access in this manner. Instead of describing that here, I’ll simply provide you the link to watch the demonstration for yourself.

If you’re not in the market to purchase an application that automatically accomplishes this and are willing to do a bit of coding yourself, there are other options available to you as well. Probably the best option is to implement generic firewall product on your web server. There are several out there, including open source application firewalls (like ModSecurity.) Because the component name is part of the URL, you can have the firewall see if the page falls under the list to be blocked and whether the user is an administrator and allow or deny the request based on that.

Notification

Finally, because users need to be able to plan around these outages (especially when the whole system is brought down for any type of maintenance), it’s also important to be able to notify users ahead of time. Although email is the most common method used today, email just doesn’t cut it most of the time (especially with all the spam people are receiving nowadays). We’re seeing a lot of folks using social networking tools, such as blogging and twitter to do this. Here are a couple of items that we recently found:

Here’s a blog post notifying users of a planned PeopleSoft Financials outage.
Here’s a tweet that notifies users of an outage due to year end processing.

Both of these techniques allow people to set up an RSS feed to tell them when there’s something new to look at (which may work well if your users are RSS feed savvy). Two other techniques are to update the portal home page and/or the PeopleSoft signon page to display a message.

One technique we’ve added as a feature to our ERP Firewall is to display a notification inside the PeopleSoft application upon access to PeopleSoft. This provides the information in the context that a user would use it, and also makes it harder for users to ignore it because they have to look at it before they can move to the next step. Again, when you have a product that knows how use rules to manage the display of PeopleSoft pages, this feature became very easy for us to add.

Labels: Firewall, Products, Security

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Using PeopleSoft Performance Monitor

I had a question the other day about getting going with PeopleSoft Performance Monitor so I thought I’d post a quick roundup/summary of the various material out there.

For those that don’t know, Performance Monitor is included with PeopleTools since PeopleTools 8.44. There’s a little bit to learn on setting it up / understanding it, but it’s a great tool and well worth learning.

Documentation.

You’ll certainly want to have the Performance Monitor PeopleBook handy while going through setting up Performance Monitor.

Presentations.

Back in April Oracle had an Oracle Advisor webcast on the setup and configuration of Performance Monitor. Here is the recording of that (Customer Connection/Metalink/My Oracle Support login required).

Lorne Kaufman of System Efficiency gave a great session at Collaborate this year about setting up Performance Monitor. Unfortunately, I can’t seem to find a link to the actual presentation anywhere. We’ll have to hassle Lorne about that.

David Kurtz of Go-Faster Consultancy has a nice selection of Performance Monitor presentations on his website. He also has a few different blog entries with tips and techniques on Performance Monitor. Those include some performance tuning tips for Performance Monitor itself which he figured out by having Performance Monitor monitor itself 🙂 He also mentions some issues that they had in a large scale environment where Performance Monitor was handling 20-30 million rows of history data each week! Good stuff.

Performance Monitor enhancements.

Brent Martin of ERP Associates has a writeup on their blog about how to get Performance Monitor to send emails when certain conditions are triggered.

Performance Monitor incidents

Here are some quick searches for Performance Monitor incidents by PeopleTools release.

8.49
8.48
8.47
8.46

Labels: 2009, Performance, Sysadmin

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Security Issues With PeopleSoft Production Refreshes

I helped some folks the other day with an issue that had the potential to be very serious for them; exposure of production data without someone needing to login to the production system. Not good.

The Problem

For testing purposes they have copies of their production PeopleSoft databases; one for Financials and one for HCM. These copies are refreshed regularly and there are scripts run against them to handle some cleaning/sanitizing of the production data, so that the database can be used for testing.

They have some people that they allow to login to these test environments with any account so that they can confirm the results of basic processes. The accounts don’t have default passwords, so this access was limited to the people that they authorized to do testing, but testers with access to these cloned environments could login as anyone.

One of the testers (we’ll call him Fred) was logged in to the Financials test environment as some other user (we’ll call her Sally) to test some process that would normally be initiated by Sally in the production system.

While doing this testing, Fred wanted to enter his timesheet data so he clicked on a link to go to the production HCM system for time entry. Much to his surprise, he was logged in to HCM as Sally! So Fred goes back to the test Financials environment, logs in as a different user, clicks the link into production HCM and sure enough he is logged in as that user in production HCM. To Fred’s credit, Fred alerted the PeopleSoft support team there instead of snooping around in HCM.

How did that happen?

The problem comes from the fact that the production environments were configured to trust each other for PeopleSoft Single Signon, but the node names and node passwords were not changed as part of the environment cloning logic.

So when Fred signed on to the cloned Financials environment, the PS_TOKEN cookies generated are identical to what the production environment would generate (the details of PS_TOKEN cookie are documented in PeopleBooks, but the node name and node password are the important pieces here).

How could this be prevented?

There are several different ways of preventing this from happening. Let’s take the pragmatic ones first.

1) Change the node password as part of the refresh script.

This is the easiest, most expedient thing to do. It is the absolute minimum way to solve this problem.

Although this solves the security problem, it introduces a headache for security auditors because the app server logs in the production environment will be full of warnings about failed logins from bad node passwords. That means that testers accessing production while logged in to the test environment will be indistinguishable from someone trying to break in by generating their own PS_TOKEN cookies.

It’s not nice to annoy your security auditors by purposely creating log entries that look like break-in attempts, but are actually OK 🙂

2) Change the node name.

Changing the node name when you clone environments will also solve the problem (because then the production environments will no longer trust the cloned nodes since they don’t recognize the new names). This also solves the log problem mentioned in the previous item.

Changing the node name can have an impact on Integration Broker testing, but that just means that your integration test scripts need to be aware of this. Not a huge drawback in my opinion.

3) Use distinct passwords for each account in the test environment.

This is easy enough to do, it’s mainly a question of distributing the passwords to the testers so that they can get in and do their jobs. Depending on your organization, this may or may not be easy.

4) Don’t provide passwords to the testers, but allow them to reset them on demand.

Similar to the previous item, but gets around the distribution issue by making it an after the fact auditing issue. If Fred requests the CEO’s password in the test system, it’s very easy to audit for that and force Fred to explain why he felt that was necessary.

Computer security is typically focused on preventing people from doing things, but in some cases this model of auditing and disciplining after the fact may be OK.

This model reminds me of when we took our dog to a dog trainer a long time ago that recommended leaving a steak or something else on the kitchen counter for the dog to find. This was in conjunction with hiding around the corner so that at the moment the dog put his paws up to grab the steak, you would jump out and impress upon the dog that it wouldn’t be wise to do that again. A real-time security audit if you will 🙂

What are some of the less pragmatic options?

5) Have a new version of PeopleTools that can detect when a database is copied, and automatically scrub key information like node passwords, GUID, etc.

The implementation of this would be platform specific, but do-able. It would complicate things like having a hot database backup server though. I’m sure those sorts of issues could be addressed though.

6) Embed additional information beyond just node name and node password (like database name) in the PS_TOKEN cookie.

One issue that I can think of with this is that older PeopleTools versions would not be able to interoperate with this, but it could be a flag on the node definition as to whether interoperability with earlier versions of PeopleTools is required. If interoperability was required, then the existing PS_TOKEN format would be used, otherwise the newer format would be used.

Why didn’t they know about this?

PeopleSoft Single Signon is documented in PeopleBooks, but there aren’t any great writeups out there on the implications of it when cloning a PeopleSoft environment.

There are lots of writeups out there on “How to Clone a PeopleSoft Environment”, and some discuss the importance of getting the node configuration correct, but they typically come at from the perspective of just making sure the environment works; not the security implications of it.

PeopleSoft Single Signon is well documented in PeopleBooks, but it just doesn’t seem to jump out at people when thinking about cloning. I will give a shout-out here to Brent Martin of ERP Associates. Brent’s writeup on cloning a PeopleSoft database is the only one out there that I could find that mentions this issue at all.

Labels: 2009, Audit, Security, Sysadmin

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Functional Testing of PeopleSoft Applications

In our previous blog post we introduced a Continuous Integration server called Hudson to run automated tests against a PeopleSoft system for us. We didn’t really get into any test content itself though; we just ran some dummy Application Engine code to show how Hudson can work with PeopleSoft.

Now that the framework piece is in place though, we can begin creating tests. For this blog post we’re going to focus on testing functional aspects of PeopleSoft, not performance testing.

Functional Testing Webinar

Before getting into the details, I wanted to point out that we have an upcoming webinar on this exact topic on May 20th, so if you’re interested be sure to register for that.

Functional Testing Options

There’s a variety of different ways for doing functional testing. Dave Bain from Oracle recently announced the availability of a PeopleSoft specific unit testing tool called PS/Unit. We’ll look at PS/Unit in an upcoming post, but if you’re not familiar with unit testing you can think of it as testing the lowest level “units” of your code.

Another approach is doing browser-based testing. Browser based testing means having automated tests that drive an actual web browser instance and simulate an actual user’s behavior. The primary benefit of browser based testing is that you can be reasonably sure that you are testing PeopleSoft as your users will be seeing and working with it.

In fact, browser based testing can be thought of as automating the way that most people test their PeopleSoft implementations today; which, sadly enough, is by having some of their functional users run through a series of manual tests in their browsers. Expensive, error-prone, incomplete are some of the adjectives that spring to mind when describing manual testing. Not to mention just the hassle of trying to get the functional users to participate in testing. They may be willing to participate once or twice, but if you need to incorporate any additional testing beyond your original project plan, it is a major hassle.

Browser based testing

Back in the old client/server days, PeopleSoft used to bundle SQA Robot (later purchased by Rational/IBM) because it understood something about the Windows controls used PeopleTools for creating the UI. These days the PeopleSoft UI is HTML/Javascript and there are lots of freely available tools that we can use for testing.

One tool that we like for functional testing via the browser is called Selenium. Selenium can run tests across multiple different browsers, and there is a plugin for running Selenium tests via Hudson so we can automate the execution and management of our automated tests.

Getting Started with Selenium

Before we get into running our Selenium tests in Hudson, we need to create some tests. The easiest way to do this is with the Selenium IDE, which is a Firefox plugin and can record, edit and debug tests. The tests themselves can be executed in other browsers, so we’re only dependent on Firefox for our initial test development.

So if you’re not already in Firefox right now, switch over to Firefox and launch the Selenium IDE plugin installer. Here is the current link, which is for version 1.0 beta 2, but you can check their download page as well to see if there are updated versions available.

Your First Test

After installing Selenium IDE, you can launch it from the Tools -> Selenium IDE menu in Firefo

When Selenium IDE launches it automatically starts in recording mode, so you can switch back to your main Firefox window and begin working. For this first example, I

Entered the URL for the PeopleSoft signon page
Typed in the password (the user ID was already defaulted for me)
Clicked “Sign In”
Waited for the portal home page to load
Clicked the “Logout” link

Then I switched back to the Selenium IDE window and stopped recording by clicking the Red button in the recording toolbar (unfortunately there are not keyboard equivalents for the Selenium recording toolbar). Let’s see what Selenium captured for us.

The first thing to notice is that Selenium has captured http://www.gsdemo.com as the base URL. All URL commands will be relative to this (there are some extra things to know if you plan to write tests that go across more than one base URL).

The first actual command that Selenium has captured is the open command. All Selenium commands take the form of Command, Target, Value. Here the target is the URL /psp/ps/?cmd=login, which gets combined with the base URL. This opens the login page.

Next is the type command, where we entered the password. In this case Selenium realized that the pwd DOM ID for the password field was the simplest choice that would work. You’ll notice that the Target editbox has become a dropdown box which shows some alternate methods of referencing the password field.

The next command is the clickAndWait command. Selenium recognized the Sign In button via it’s DOM ID of Submit and used that.

The last command is also the clickAndWait command, but when we logged out, there was no unique DOM ID that was associated with the Logout link, so Selenium recognized the click by noting that the link text was Logout (eagle-eyed readers will note that the logout text in this environment has actually been customized from an earlier blog entry.

At this point

we can repeatedly click the play button in the Selenium recording toolbar and watch the browser login and logout. There are actually two play buttons, one is for the current test case and one is for playing back an entire test suite (which is many test cases grouped together). In this instance it doesn’t matter, but once you actually create test suites, then you’ll want keep them straight in your head.

If you have any problems at this point playing back the test, you can try adjusting slider control in the Selenium IDE toolbar towards the “Slow” end. This causes Selenium IDE to wait a bit longer for commands to show some results.

Modifying the Test

Each of the commands that Selenium captured for us is modifiable, including being able to delete it. So to make our test a bit more exciting, we highlight the last command (the clickAndWait command that logged out) and delete it, since we don’t want to logout just yet.

Then play the script again. This time when the script finishes you will be left on the portal home page (since we’re not logging out). Pressing the Record button will start recording again at the end of the script.

This time we will navigate via the portal menu navigation to PeopleTools -> Security -> User Profiles -> User Profiles. Once the User Profiles component search page is up, we type in PTDMO and then press the Search button.

Before playing back this script, I made one manual edit. I changed the very top command from navigating to cmd=login to cmd=logout. PeopleTools will send back the signon page in both cases, but by starting with the logout command you clear server resources from the previous script run. Your system administrators will thank you for this small act of kindness 🙂

When playing back the script, I have a small problem; the script does not playback successfully. It tells me that it can’t find a frame named “NAV”.

The source of the problem is that Selenium does not quite understand the way that PeopleTools is doing it’s navigation. When we click on the first navigation link from the Portal home page Selenium records the following two commands.

Command: clickAndWait, Target: link=(the name of the link)
Command: waitForPopup, Target: _parent, Value: 30000

After we leave the portal home page though, we are getting into PeopleTools generated HTML frames. The next command that Selenium IDE records is Command: selectFrame, Target: name=NAV. The NAV is the name that PeopleTools gives to the menu frame once we leave the portal home page. What we want at this point is for Selenium to wait for the NAV frame to load before we select it, but the commands that Selenium is generating are only waiting for our top level page to load.

Rather than run the entire test at a slower rate so that we’re sure that the navigation frame is loaded, we’ll insert an extra command before the selectFrame command that will tell Selenium to wait for that frame to load. To do that we

Right click on the selectFrame
Select “Insert New Command” from the popup menu
Type waitForFrameToLoad in the Command edit box
Type TargetContent in the Target edit box
Type 30000 in the Value edit box

One cool thing about Selenium IDE is that as you enter commands, you get type-ahead support for what commands are available. Once you select a command, then you get the help text for it automatically displayed at the bottom of the IDE window. Very nice! Here’s a full list of all of the different commands that Selenium supports.

The other nice thing about the IDE is that we can copy and paste our waitForFrameToLoad command instead of typing it in everywhere. There are a few more places in our navigation script where the selectFrame command is used, so we’ll paste it before each one. That allows us to run our script at full speed, but have it wait for the navigation to finish loading if the webserver is slow for some reason. Note that after we finish navigating we are then waiting for the frame called “TargetContent”, so we use that name instead.

Skipping Navigation

In some cases you may want to include the navigation portion in your tests, but in many cases you’ll want to just test a certain functional area. A good trick for doing this is just have Selenium go straight to the page that you want instead of navigating to it.

The open command in Selenium can be used in the middle of your test scripts, not just at the beginning, so we can replace all of the navigation commands with the open command and the value “/psc/ps/EMPLOYEE/PT_LOCAL/c/MAINTAIN_SECURITY.USERMAINT.GBL”. Note that we used the psc servlet instead of the default psp. That will completely bypass the portal and just load the underlying component itself.

Making Assertions

Part of testing is making assertions about the behavior that is seen. Selenium supports making assertions about things as simple as text being on the page to whether specific cookies are present (a good way of checking that you are logged in is asserting that you have a PS_TOKEN cookie) and even as detailed as making assertions about the HTML source code that has been generated for a page.

There are somewhere in the neighborhood of around 100 different things that Selenium can make assertions about, so you should be able to come up with something that helps you validate the desired functional behavior that you are testing. For the example that we have been going through I added a the assertTextPresent command with the Target set to “Confirm Password” since that is the label for one of the fields on the User Profile page. This assertion will return true if “Confirm Password” is present anywhere on the entire page.

We can make some tighter assertions by narrowing the focus from the entire page to specific elements. The above assertion could also be implemented as the assertText, which takes an element locator in addition to the text that is being checked. We saw the use of element locators when working with the login form above; an element locator is just some way of identifying a single element on the page.

PeopleTools will typically generate unique IDs for each form field on page. These are normally the underlying record name and field name for the underlying value in the database (with row numbers if working with multiple rows). In the case of checking a label, PeopleTools will generate a “label” element, with the “for” attribute referencing which form field the label is for.

In this case, we end up with our element locator as //label[@for='PSUSRPRFL_WRK_OPERPSWDCONF'] because we want the label for the OPERPSWD_CONF field from the PSUSRPRFL_WRK record.

In the above screenshot we can see that our assertTextPresent assertion passed, but our assertText assertion failed. Selenium IDE provides the reason for the failure in the log though. The assertText assertion is making an exact check of the element’s text, while the assertTextPresent assertion merely checks that the text exists at all across the entire page. Since PeopleTools is generating a colon at the end of the label, we would need to incorporate that in our assertion.

Saving Our Tests

Up to this point we haven’t saved our test logic at all. In the Selenium IDE window, select File -> Save Test Case (or press Ctrl-S for a keyboard equivalent). You’ll be prompted for a file name. I selected TestUserProfile.html. By default Selenium stores it’s list of commands in a special HTML format, which is why we used that extension.

You can also have Selenium export a test case to various other programming languages (Java, C#, Perl, PHP, Python, and Ruby are all supported currently). The benefit to using a programming language for controlling Selenium is that you can then do things like have conditional logic, common subroutines, etc. The drawback is that you lose the ability to use Selenium IDE to work with them at that point. We’ll stick with the plain HTML format for now while we’re still getting familiar with Selenium, but future blog posts will get into using the programming language integration.

In the above screenshot you’ll notice that I expanded out one section of the Selenium IDE window. That shows us the current test case being worked (TestUserProfile). If we click File -> New Test Case, we’ll get an “Untitled” entry added in the list of test cases and an empty list of commands. We would then build up our test case just like we did above and save it.

Once you have a few test cases, then you can select File -> Save Test Suite to group the test cases together. You can copy and paste commands between different test cases, so if you find one test case is starting to cover too much functionality, you can break it into multiple test cases this way. Selenium lets you run either single test cases or run an entire test suite together, so you can break things in manageable chunks without losing the ability to group things appropriately.

I did notice a bug in the test case re-ordering within the Selenium IDE window though, so after you save your test suite, you’ll probably want to open to the open the test file and re-order the tests listed there so they match the order that you want to run things in.

Wrapping Up

Now that we can start coming up with some meaningful tests, the next steps from here are to incorporate the execution of our tests into our Hudson environment so that they can be run automatically for us.

We’ll also want to start integrating all of this with version control. We not only want to start keeping track of the different versions of our tests, but we also want to tie the execution of our tests to changes that are happening with the underlying PeopleSoft objects.

That way if a working test starts throwing assertion errors at some point, we’ll be able to see exactly what changes were implemented in PeopleSoft that caused the problem, along with who did it and the underlying reason that the changes were implemented. And if necessary, revert those changes to put things back the way they should be.

Labels: 2009, Browser, Sysadmin, Testing, VersionControl

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Issues with Dynamic Roles in PeopleSoft

We wrote awhile back about a customization that can be done to limit a user’s roles dynamically at a signon time, but wanted to point out an issue with it that came up recently during some customer discussions on our ERP Firewall for PeopleSoft product.

The essence of the customization revolved around creating extra tables for storing the “real” list of roles for a user separately so that the PeopleTools tables that stores the roles for a user can be modified at signon time. The way that PeopleTools is delivered there is one table that is both the “master” list of roles for a user and the “current” list of roles for the user’s session.

A little bird told me that this may get addressed in future PeopleTools versions (let’s hope for PeopleTools 8.50!), but for now the modification that we outlined in the previous blog entry is the only way to accomplish this.

So what’s the problem?

Now consider the scenario where your CFO logs in from a public kiosk at a conference somewhere to enter her expense report. You have implemented the customization to limit her roles to just those that would allow her to enter expenses and not be able to do things like pull up your P&L reports when she logs in this way.

What happens when some other process runs (batch, workflow, etc.) and checks to see who is in the high level finance roles? It won’t find your CFO. Not good.

And the answer?

One answer is to do a thorough search of all of the application code for role queries, references to PSROLEUSER, use of the IsUserInRole() PeopleCode function and modify those to use the customized “role master” table that the previous blog entry outlined.

Another answer is to wait for PeopleTools to support the notion of “session level” roles.

Another solution is to use some sort application level firewalling solution. Of course, we’re partial to our own application firewall for PeopleSoft, but there are other ways of achieving this as well.

Labels: 2009, Firewall, Security

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Request a Demo

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

Necessary

Always Enabled

Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Functional

Performance

Analytics

Others

Platforms

Features

Register for an Upcoming Webinar

SAP

PeopleSoft

Appsian360

Review

Webinars

Persona

Register for an Upcoming Webinar

Customers

Video Testimonials

Featured Case Studies

Why Appsian

Management Team

Careers

Press Releases

Partners

Contact Us

Customers

Partners

Home / Blog / Your security options are set improperly. Please contact your security administrator.

Your security options are set improperly. Please contact your security administrator.

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Tuxedo Listening on Multiple IP addresses

Tuxedo Listening on Multiple IP addresses

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Query Tip of the day: Creating a Query from a PeopleSoft Component Name

Query Tip of the day: Creating a Query from a PeopleSoft Component Name

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Query Tip: Updating the Effective Dates of In-Tree Criteria

Query Tip: Updating the Effective Dates of In-Tree Criteria

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Increasing System Availability with PeopleSoft

Increasing System Availability with PeopleSoft

Implementation Options

Notification

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Using PeopleSoft Performance Monitor

Using PeopleSoft Performance Monitor

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Security Issues With PeopleSoft Production Refreshes

Security Issues With PeopleSoft Production Refreshes

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Functional Testing of PeopleSoft Applications

Functional Testing of PeopleSoft Applications

Functional Testing Webinar

Functional Testing Options

Browser based testing

Getting Started with Selenium

Your First Test

At this point

Modifying the Test

Skipping Navigation

Making Assertions

Saving Our Tests

Wrapping Up

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Issues with Dynamic Roles in PeopleSoft

Issues with Dynamic Roles in PeopleSoft

Related Articles.

Put the Appsian Security Platform to the Test

US Office

India Office

Start your free demo

Register
for an Upcoming
Webinar

Register
for an Upcoming
Webinar