http://example.com/psp/hcm91dev/EMPLOYEE/HRMS/h/?tab=DEFAULTHere 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.GBLThe shortened URL would be:
http://example.com/c/tl_mss_ee_srch_prdFinally, 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_SQLTraceBasicwould 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. Labels: Email, OpenEnrollment, Products, User
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
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.
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
In the past few weeks, we’ve had a lot of interest in our new Version Control for PeopleSoft product. For those interested in learning more about it, here’s a link to the product pages (with a full demo embedded into the “Demonstration” tab).
If you aren’t using anything for Version Control for your PeopleSoft objects, you’ll definitely want to check it out (and share it with others in your organization).
Feel free to contact us at Info@GreySparling.com if you are interested in trying this product out.
When workflow was first added to PeopleSoft 5 back in 1995, the mantra was the three Rs: Rules, Roles, and Routings. I’ll bet that Rick Bergquist still has dreams where he is talking about rules, roles, and routings 🙂
Routings are the part that I wanted to highlight here. The two primary mechanisms for routings that PeopleSoft delivered as part of PeopleSoft 5 were worklists and email.
Worklists are great for people that spend a lot of time in PeopleSoft applications and have enough activity being routed to them that they actually check their worklist, but the broader audience does not typically log in to PeopleSoft to check their worklist to see if there is anything waiting for them to do.
It’s sort of a shame that more work didn’t happen on pushing out PeopleSoft worklist entries to whatever the end-user really use as their “stuff I need to do” list. There are some decent APIs that PeopleSoft delivers these days for accessing that data, but I’m not familiar with them being used for generically pushing PeopleSoft worklists into something like the Todo List functionality in Outlook or Lotus Notes.
In the absence of integrating their worklist entries with something else, most people ended up just using email as the primary mechanism of notifying people that they needed to do something like approving a purchase order in PeopleSoft.
Issues with Workflow Email Notifications.
There are some problems with relying on email though.
Please Do Not Reply To This Email.
Historically the emails generated by PeopleSoft came from a system account, instead of being from an actual person. So PeopleSoft customers would make sure that the emails that were sent out all had text in them telling the person “please do not respond to this email”.
Makes sense, except that the whole reason that we’re sending out emails is because of its universality. Getting an email that you can’t respond to is kind of like getting phone calls from the robot dialers that political campaigns use; pretty annoying.
In newer releases of PeopleSoft, this is less of an issue because there are more places where PeopleSoft application developers took advantage of the ability to generate emails themselves in PeopleCode with more control than the core workflow framework provided. In fact, the Financials/Supply Chain development group did enough of this that they wrote an entire workflow framework using PeopleCode application classes.
In PeopleTools 8.48, that code (known as Approval Workflow Engine) was moved to core PeopleTools so that all PeopleSoft applications and customers could use them. So if you’re up on an applications release 9.0 and higher, be sure to take a look at that.
Stop Sending Me So Many Emails!
We’ve talked with a number of PeopleSoft customers over the years that have ended up turning off workflow because of user complaints regarding the sheer volume of email that they receive. In fact, we just had someone searching our blog today for how to turn off notifications in PeopleSoft HCM.
The problem is that each event that happens (purchase order is entered) and the notification is tied directly to that. Immediate notification is important in some scenarios (confirmation of a customer’s order, employee terminations, etc.), but when someone in management gets 12 expense reports, 15 purchase orders, 9 regularly scheduled reports, etc. showing up in their inbox scattered during the day they sometimes get annoyed.
One way of solving this problem is to re-write your notification processes so that the event and the notification are de-coupled. When the event happens, save off the data (could be in the worklist tables or some other tables) and then have a separate process that delivers the notifications separately.
The problem with re-writing these processes is that it’s time-consuming and expensive, which is why a lot of people end up just turning off the notifications altogether.
The 1990s are calling and they want their email formats back
It’s possible to send HTML emails with PeopleTools, but a lot of the delivered workflow does not take advantage of this. On top of that, the lengthy hyperlinks that can be generated for navigating directly to a particular place in PeopleSoft (the navigation, plus the key values for pulling up the data) are not that attractive.
Who got what and when
Generating notifications as worklist entries leaves a rich history of when the notification was created, worked on, and closed out. There are some nice delivered reports that come with PeopleTools that can show this sort of information. Take a look at the PeopleTools delivered Queries that start with WF. There are some Crystal Reports for those as well.
Tracking email notifications doesn’t happen unless it has been specifically coded into the notification process though. Lots of PeopleSoft applications have added this functionality to key processes, but it’s tied to specific processes. There’s no way to figure out what are all of the emails that a particular user is receiving (or see how many notifications are being generated for a particular process).
The topics discussed in this blog entry come directly from conversations that we have had with different PeopleSoft customers (especially from folks that are familiar with the email functionality in our Report Security and Distribution product; see the Report Notification section on the flash demo). Since we’ve seen continued interest in this topic, we went ahead and built something to fix it.
Announcing the Grey Sparling Email Proxy for PeopleSoft
Here is a high-level overview of what the Email Proxy does:
- It intercepts emails that PeopleSoft generates.
- Classifies them according to your rules (who is getting it, what process is it part of, etc.)
- Optionally rewrites the email
- Provides nicer formatting, rewrites generated links, custom signatures, etc.
- Combine multiple emails together (so someone that gets 20 purchase order notifications in a day can just get one summary email).
There are setup pages where you define the rules that you want for classifying the emails as well as the look and feel of the generated emails, as well as pages for being able to view the emails being generated, statistics regarding the emails, etc.
The Email Proxy server is in beta-testing now at a large PeopleSoft customer that services multi businesses with their PeopleSoft applications and should be generally available shortly.
Continuing on in the cool stuff we’ve been working on series, I wanted to post something about a topic that goes way, way back.
Many years ago, Dave Yoder of Rainbird asked me at a DMUG user conference about how to get variable expansion support for file name references when building a project inside Application Designer.
Without having variables that you can expand, you always have to remember to change the name of the file that will be generated each time you build records/views/indexes, etc. It’s really easy to forget and lose old copies. If you care about saving copies for yourself or for audit purposes, then it gets tiresome to always remember.
Here’s some screenshots of what we have put together to address this particular issue. The first two screenshots show the Application Designer Build Settings dialog with the build log file set to c:temp%YEAR%%MONTH%%DAY%PSBUILD_%DBNAME%.log. Here we are just changing the log file, but it works for any of the files that would get generated when doing builds in Application Designer.
The strings that are between percent signs (YEAR, MONTH, etc.) are variables that get expanded out to real values at the appropriate moment.
Here is what it looks like when you actually run the build.
As you can see, the generated log file has been created as c:temp2009126PSBUILD_PTSYS.log. Since today is January 26, 2009 and I was working in a PTSYS database, that’s exactly what we expected
There are also tokens for things like current hour, minute, second so if you like to do lots of builds in a short time frame you might want to take advantage of those as well.
In addition to things like date/time and connectivity info, there are also tokens that are supported by other Grey Sparling products.
For example, when you are using Grey Sparling Version Control for PeopleSoft you can also do things like reference which ticket number that you are currently working on. Here’s the build settings showing the log file setting as c:tempTicket-%TICKET%PSBUILD_%DBNAME%.log
After running the build (note that our version control plugin is active now; it has to be to supply the current ticket number), you’ll see that the build log file was generated as c:tempTicket-4PSBUILD_PTSYS.log. We could have included the date/time tokens as well if we had wanted to.
Now the build scripts, log files, etc. can easily be associated with the work that you are doing, and even automatically attached to the ticketing system if you want. That helps when your developers and DBAs need an audit trail of these sorts of activities. Fun to use and keeps the suits happy!
So if you run into Dave Yoder at a conference, be sure to thank him for coming up with the idea (and asking about it enough that it finally got built!)
Labels: 2009, ApplicationDesigner, Database, Products, VersionControl
- We capture the information that describes the content of a report.
- We allow you to use that information in combination with information in your PeopleSoft application to provide a rich user interface for organizing, finding, and describing the reports.
- We allow you to configure the behavior of organizing, accessing, and using reports.
(Sept. 20 update: since writing this we have created a Desktop Single Signon snap-on product that works with PeopleSoft Enterprise. Here’s the announcement and here is the product page).
Single signon is widely desired, yet not widely understood. As usual with PeopleSoft, there isn’t one simple answer, but the good news is that it’s not that hard to get what you want. The biggest challenges are political rather than technical.
So, let’s start by listing a few of the different common definitions of single signon. What most people mean (and want) is that a user signs on once in the morning and is then granted access to all other applications based on that signon. No additional login screens, etc.
Another common definition is that there is only one place for a user to authenticate with. No need to remember 17 different passwords from systems that have different rules about how often to change the password and how long it has to be. The drawback here is that the user still has to authenticate for each system that they access. I’ll refer to this style as “single password”.
Note that I use the word “authenticate” rather than saying “fill in their username and password”. Although most environments are based on username and passwords, the best run environments go beyond just username/password in order to validate the user (think SecureID token).
One interesting wrinkle to all of this is somewhat PeopleSoft specific. PeopleSoft supports a notion of single signon between PeopleSoft instances.
If you have PeopleSoft HR, Financials, CRM, and EPM, then you actually have four different environments, not just four different product lines in one environment. There are some advantages to this loosely coupled model, but unified administration wasn’t one of them. We actually made some progress at this at PeopleSoft towards the end, but it still never got to be as simple as administering one large system.
Given those four separate environments, PeopleSoft supported single signon between them. If a user logged into, say, Financials and then followed a link to the HR system they would not have to signon again. You do need to configure each system to trust each other (you don’t want someone with access to a demo CRM system to be able to access your production Financials), but that is not difficult at all. PeopleBooks has good information on how to do this.
Note that the word LDAP has not yet been mentioned. LDAP is just a common place for storing user information (such as their password, their email address, etc.). By itself, it doesn’t provide single signon. It only simplifies getting single signon working by having a standards-based common location for storing user credentials.
We made some big bets on LDAP support in PeopleSoft 8. When that came out back in 2000, there weren’t really too many enterprise application vendors that supported LDAP. Of course, all of our customers in Higher Education had been telling us to do this for years (especially the University of Michigan). We even had fantasies about dropping our internal authentication support and using LDAP as the out of the box authentication mechanism for PeopleTools 9.
One problem that we had though was that when our field was trying to explain to other customers how this stuff worked, that the concept of single signon and LDAP got confused. Even to the point where the single signon section in PeopleBooks had to be changed to explain that they are not the same thing.
So, out of the box, you can get support for “single password” from the desktop level if your desktop signon uses a backend that supports LDAP (such as Microsoft Active Directory). The first time that the user accesses PeopleSoft they get prompted for their password again, but then (via the PeopleSoft single signon) the user can access all of your PeopleSoft systems.
If you want to go beyond this and have desktop level single signon, then you’ll need to do some customization. A common way of doing this is to have a Windows server running IIS that acts as a proxy server to PeopleSoft. You setup IIS to use NTLM authentication for the proxy link, which will cause Internet Explorer to send in the user’s desktop signon information. Then you create a little bit of signon PeopleCode that will check the custom HTTP header that IIS will attach to the request with the user’s domain and login ID.
If you do this make ABSOLUTELY sure that you validate requests with this header come through the IIS server. Otherwise you’ve just opened up access to your entire PeopleSoft system to anyone that knows how to create an HTTP request with a custom header (which is painfully easy). This is because the IIS server just passes back the domain and username, but does not cryptographically secure it.
The nice thing is that this is not just limited to Internet Explorer. Recent versions of Mozilla based browsers (Mozilla 1.6+, Netscape 7.2+, Firefox 0.8+) also have support for Microsoft’s NTLM protocol. If the user is on a different platform than Windows, then their desktop signon won’t be passed along, but at least they won’t be locked out.
If you want to do this type of Windows desktop single signon, but don’t want/can’t have an IIS proxy server, then you’ll want to look at using jCIFS for that.
How about if you don’t want to use the Windows login as the basis for desktop single signon. Is that even possible with PeopleSoft applications?
Sure. It takes a little bit more work, but it’s possible. You’d have to install something locally on the client machine that get the user’s credentials once, and then passes that along to somewhere where the PeopleSoft server can validate it. Either by passing it along in the browser headers or some other way. If you’re interested in this, take a look at Steve Friedl’s Illustrated Guide to SSH Forwarding. Using SSH as a mechanism for desktop single signon for PeopleSoft applications strikes me as an interesting idea.
Well, there’s more to be said on this topic, but this has been sitting in the queue for too long, so I’m publishing what I’ve got. Please comment if you’re interested in hearing more (as well as what you’d like to hear).
Labels: Products, Security
Our apologies to our loyal blog readers for the lack of content in the past few weeks. Grey Sparling Solutions has had all hands on deck for a go-live for a large financial institution with our Reporting Security and Distribution PeopleSoft Solutions Extender. Taking the lead from Joel Spolsky, a blogger that we at Grey Sparling Solutions follow, we thought it might make sense to discuss a little about the product and how the customer plans to use it.
As with most financial services institutions, financial reporting is a very important aspect of their ERP solution. This customer has several thousand financial reports that they need to run periodically, and need to secure and distribute to many users. The process of securing and distributing the reports is a very challenging problem for them (and in an era where controls need to be easily audited, the lack of good report security and distribution functionality in ERP systems is a challenge for them).
Additionally, most of the people receiving reports do not use the ERP system other than to look at reports and drill into results. Therefore, the customer would prefer that reports are distributed through email. However, many of these users receive several reports at once, and the customer would like the links to the reports to be consolidated into a single report.
The Report Security and Distribution PeopleSoft Solution Extender (we recently renamed it from the process scheduler extender) is what this customer is utilizing. This extender has the following major components:
- A means of defining the security rules: as in which users should have access to what data.
- A means of defining the reports to be run and linking in the security rules to ensure that the report data is filtered appropriately and the results are distributed to the right people. The filtering and routing happens automatically.
- A means of graphically organizing the nVision reports into jobs to be run on different schedules and organized appropriately. This allows the administrator to see the complete jobstream and all the times different reports are to be run in a single graphical view.
- A means of defining and personalizing the content of the emails with information in the ERP system. This allows robust, highly formatted emails to be generated with highly descriptive information about each report in the email itself.
- A means of generating the emails on a pre-defined schedule. This allows the reports to be distributed in bulk, with multiple reports in a single email.
- A means of auditing which users have access to which data and which reports. This allows the customer to determine whether the right people are getting the right data (which makes auditing for compliance purposes very easy).
Once this go-live is completed, the customer will implement the report manager part of the extender, which will provide a robust means of organizing and accessing the reports outside of email (through a browser). The users will be able to find reports based on the data in the reports, as well as setting up favorite reports that they won’t have to search to find. In addition, we will track which users have viewed which reports at what times (which allows the organization to understand which parts of the business are a compliance risk, because without reviewing the financial reports, they are probably not enforcing the appropriate controls in that area).