[searchandfilter taxonomies="search"]

Introducing Automatic URL Shortening for your PeopleSoft URLs (automatic bit.ly or TinyURL for PeopleSoft)

Did you know that the average PeopleSoft URL is over 100 characters long and is completely nonsensical to the average PeopleSoft user? Long PeopleSoft URLs cause confusion, make it more difficult for users to access the pages they need, limit your ability to use PeopleSoft with collaboration tools, and generally increase your cost of operating PeopleSoft. Grey Sparling has provided a very simple solution to this problem without adding additional administrative effort, without requiring you to register each individual internal PeopleSoft address to public services (causing security risks), and without adding additional infrastructure to your PeopleSoft Environment. Here’s what it does A standard PeopleSoft URL to the portal homepage is as follows: http://example.com/psp/hcm91dev/EMPLOYEE/HRMS/h/?tab=DEFAULT Here is what the same URL would be with the Grey Sparling’s PeopleSoft URL Shortener: http://example.com/ A URL directly into an Employee Self Service page may look as follows: http://example.com/psp/hcm91dev/EMPLOYEE/HRMS/c/ROLE_EMPLOYEE.TL_MSS_EE_SRCH_PRD.GBL The shortened URL would be: http://example.com/c/tl_mss_ee_srch_prd Finally, a PeopleSoft URL to an iScript to turn on tracing may look as follows: http://example.com/psp/hcm91dev/EMPLOYEE/HRMS/s/WEBLIB_GS_TRACE.SET_TRACE.FieldFormula.IScript_SQLTraceBasic would convert to We also allow you to use lowercase characters to increase readability and reduce the potential for data entry error. This works automatically across your entire PeopleSoft system. In the case of PeopleSoft HCM 9.1, for example, that’s approximately 10,000+ URLs that instantly go from from so-ugly-they-terrify-people to nice enough that you can post them publicly without people making fun of you 🙂 It even automatically understands any custom bolt-ons that you have added (or will add) to your PeopleSoft environment. Availability and Pricing This product will be available within the next couple of weeks. It is priced at $7,500, but we will be discounting it to $5,000 for organizations who purchase it by December 15, 2010. If you would like to get more information, feel free to contact us.

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

Advanced PeopleSoft Security Audit – OpenWorld 2010

David Pigman of SpearMC consulting presented Advanced PeopleSoft Security Audit.

Most of the presentation consisted of walking through slides of the PeopleTools security table structures, along with some discussions of things to watch out for. Some examples included key field names that are different between tables (which means Query won’t autojoin), decoding the ACTIONS field (which is a bitfield) into meaningful data, and understanding that PeopleTools like Data Mover, Application Designer, etc actually get secured by menu names (eg DATA_MOVER) that don’t actually exist as menu definitions, but are hard-coded in the PeopleTools internal code.

The presentation was good (although I don’t think that I would call it advanced audit). A little more demo vs slides would be nice as well. A number of the queries that David did show (either in ppt or in an environment) are available with the presentation to be downloaded later.

They also have a product offering with additional queries that a security auditor might find useful. Towards the end of the presentation David showed a few of these in a live environment.

Labels: 2010, OpenWorld, Oracle

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

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

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 / Introducing Automatic URL Shortening for your PeopleSoft URLs (automatic bit.ly or TinyURL for PeopleSoft)

Introducing Automatic URL Shortening for your PeopleSoft URLs (automatic bit.ly or TinyURL for PeopleSoft)

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Advanced PeopleSoft Security Audit – OpenWorld 2010

Advanced PeopleSoft Security Audit – OpenWorld 2010

Related Articles.

Put the Appsian Security Platform to the Test

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

US Office

India Office

Start your free demo

Register
for an Upcoming
Webinar

Register
for an Upcoming
Webinar