Thursday, October 30, 2014

PeopleSoft's paths to the Cloud - Part II

In my previous blog post, I've covered some ways in which cloud computing features could be used with PeopleSoft, particularly around Infrastructure as a Service (IaaS) and non-Production environments. Now, I'm going to discuss how cloud technologies bring value to PeopleSoft Production environments.

Gain Flexibility



Some of the advantages of hosting PeopleSoft Production environments using an IaaS provider were also mentioned in the my past article as they are also valid for Non Production environments:

  • Ability to adjust processing power (CPU) and memory according to peak usage.
  • Storage may be enlarged at any time to cope with increasing requirements.
  • Possibility of replicating the existing servers for contingency purposes.

In terms of cost, hosting the Production environment in IaaS may not always be cheaper than the on premise alternative (this needs to be analyzed on a case by case basis). However, the possibility to add more CPU, memory and storage on the run gives IaaS solutions an unprecedented flexibility. It is true that you can obtain similar flexibility with in house virtualized environments, but not many in-house data centers have the available horsepower of Amazon, IBM or Oracle data centers, to name a few.

Be Elastic



Adding additional power to the existing servers may not be the best way to scale up. An alternative way is to add a new server to the PeopleSoft architecture. This type of architecture is called elastic (actually, Amazon EC2 stands for Elastic Computing), as the architecture can elastically grow or shrink in order to adapt to the user load.

Many PeopleSoft customers use Production environments with multiple servers for high availability purposes. You may have two web servers, two application servers, two process schedulers, and so on. This architecture guarantees a better system availability in case one of the nodes fails. Using an elastic architecture means that we can add, for instance, a third application server not only to increase redundancy, but also the application performance.

In order to implement an elastic architecture, you need to fulfill two requirements:

  1. You should be able to quickly deploy an additional instance of any part of the architecture. 
  2. Once the instance is created, it should be plugged in the rest of the components, without disrupting the system availability.

The first point is easily covered by creating an Amazon AMI which can be instantiated at any moment. I've discussed the basics about AMIs in my previous post, but there is plenty of information from Amazon.

The second point is a bit trickier. Let's assume we are adding a new application server instance. If you do not declare this application server in the web servers configuration.properties file, it will not be used.

Of course you can do this manually, but my suggestion is that you try to automate these tasks, as it is this automation which will eventually bring elasticity to your architecture. You need to plan the automation not only for enlarging the architecture, but also for potential reduction (in case you covered a usage peak by increasing the instances and then you want to go back to the original situation).

At BNB we have built a generic elastic architecture, covering all layers of a normal PeopleSoft architecture. If you are planning to move to a cloud infrastructure and you need assistance, we would be happy to help.

Coming Next...

In my next post on this topic, I will cover how Database as a Service could be used to host PeopleSoft databases and what value it brings to PeopleSoft customers.

Tuesday, October 28, 2014

PeopleSoft's paths to the Cloud - Part I


Nowadays, all paths seem to lead to cloud computing. In the business applications world, Oracle is pushing hard to position the Oracle Cloud Applications in an increasingly competitive market. The reasons that favor Software as a Service (SaaS) applications over their on premise counterparties are significant, even though there are still a good number of circumstances under which the latter should normally be the preferred option.

Our beloved PeopleSoft (yes, I like PeopleSoft, so what?) is clearly not a SaaS application. Still, my point of view is that we can still benefit of many cloud computing features without migrating to another application.

On this post, and a few more to come, I will focus on the aspects of cloud computing could be incorporated to your PeopleSoft application.

Infrastructure as a Service

Infrastructure as a Service (IaaS) is a provision model in which an organization outsources the equipment used to support operations, including storage, hardware, servers and networking components. The service provider owns the equipment and is responsible for housing, running and maintaining it. The client typically pays on a per-use basis.

Probably the best known service in this category is Amazon EC2, but there are many other providers with similar features. We have installed PeopleSoft quite a few times under Amazon EC2, and the advantages are visible immediately:

  • CPU, memory and disk space can be dynamically allocated. This is particularly useful when facing system usage peaks, for instance close to the evaluations submission deadline when using the PeopleSoft ePerformance module.
  • Servers can be seamlessly cloned, which enormously reduces the time needed to set up new environments.
  • The instance cloning can also take place between different geographical areas, providing a perfect solution for contingency environments.
  • As mentioned before, the allocated servers are paid on a per-use basis. The only exception is storage, for which you will get charged even if the server is down (and assuming you still keep the storage space busy for the next time the instance is booted).

Use Case: Development Environments

One of the most typical uses of IaaS with PeopleSoft is for non-production environments. In many cases, these environments do not need to be up and running 24x7, so the solution provided by Infrastructure as a Service is not only more flexible, but also normally more cost effective.

The flexibility of IaaS is major advantage when a sandbox environment is needed. Cloning any existing environment just takes a few minutes allowing the developers to build prototypes on a new and isolated environment that is out of the migration path.

Use Case: Test a New Release

Another functionality of IaaS is the ability to use templates that could be rapidly be used to create a new instance based on it. The Amazon name for these templates is AMI. In the past, Oracle used to provide AMIs for PeopleSoft 9.1, so if you wanted to test that release, it was just a couple of minutes away.

However, currently there are no AMIs provided by Oracle for PeopleSoft 9.2. Luckily, you may still contact consulting companies like BNB to provide you the AMI, as long as you have a valid PeopleSoft license (the Oracle provided AMIs are under a trial license, so even if you are not currently a PeopleSoft customer you can use them).

Note: An alternative way to test a new release is to download the latest PeopleSoft Update Manager image, but it takes considerable time to do it due to the size of the files (over 30 Gb).

Use Case: Training

IaaS can also be used to quickly deploy PeopleSoft instances for internal user training. We actually use this approach at BNB for training our consultants. We have created an AMI for each course, so before the training session starts, we create one instance per student, so they have a completely isolated environment to learn and play with.

Coming Next...

In the next post, I will cover the value that cloud computing brings to PeopleSoft Production environments. But that's not the end of it, so stay tuned.






Monday, October 27, 2014

PeopleTools 8.54 Feature: Application Engine Trace File Enhancements

In this blog, we have been reviewing the new features of PeopleTools 8.54. Today is the turn of Application Engine, particularly on its troubleshooting. This release of PeopleTools include several enhancements on Application Engine tracing, which are outlined below:


  • The .AET trace file can now include the PeopleCode trace. This removes the need of checking the .AET file for the the non-PeopleCode steps and the .TRC file for the PeopleCode steps. Surely, .TRC files could also contain the SQL executed in non-PeopleCode steps if needed, but it was significantly more difficult to read as the SQL statements were not formatted.


This new feature is enabled by setting the TraceAECombineOutput parameter in the server configuration file for Application Server or Process Scheduler Server.

TraceAECombineOutput=Y


  • You can set the file size of the Application Engine Trace file. This way, if the trace file exceeds the threshold, it splits into a different file. For certain processes, this could be quite handy, as sometimes the trace sizes become unmanageable.

This new feature is enabled by setting the AETFileSize parameter in the server configuration file for Application Server or Process Scheduler Server. The size is measured in Megabytes.

AETFileSize=20

  • You can actually select which sections of an Application Engine program should be traced and which not. This can contribute to reduce unneeded trace information, just focusing on the potential error areas.


This new feature is enabled by setting the TraceAEEnableSection parameter in the server configuration file for Application Server or Process Scheduler Server.


TraceAEEnableSection=Y


Then, using Application Designed, you should mark the sections you want to trace. Keep in mind that by default all sections are unmarked:

In order to enable the flag in Application Designer, the Enable Section Trace(g) setting has to be enabled in Configuration Manager:


Note: As far as I can tell, you can only set this flag when you create a new section. If you need to modify an existing one, you would need to copy and paste, and then remove the original one. Have any of you found a more efficient way of setting the flag?


  • The Application Engine Trace file name now includes the Date/Time stamp.


These enhancements should simplify troubleshooting of Application Engine program issues, particularly those ones containing a significant amount of PeopleCode processing or generating very large trace files.

Friday, October 24, 2014

PeopleTools 8.54 Feature: ExcelToCI Errors and Warnings Worksheet

Some years ago, I wrote this post on ExcelToCI limitations. One of the limitations I've found annoying in the past was the need to move the mouse over each Warning or Error result cell. It was not just annoying, it actually didn't allow the users to easily work on the different error types and analyze useful information such as the most common error messages, how many rows would go through if they solved a particular issue, etc.



PeopleTools 8.54 has introduced a new worksheet showing all the warning and error messages. The following screenshot provides a clear view on how the information is presented:



From that point on, the users may analyze the messages using Excel dynamic tables, filters, etc. Yet, there is some room for improvement. The most obvious one is to put each particular error in a different Excel row. That would make error analysis much richer.

Let's see how this evolves with the next releases of PeopleTools.

Thursday, October 23, 2014

PeopleSoft's PS_HOME evolution

One of the new features of PeopleTools 8.54 is the portability of the PS_HOME directory. Before going into the analysis of its benefits, let's have a look back to how  PS_HOME has evolved.

One Directory for Everything

PS_HOME is the name of the environment variable holding the PeopleSoft installation directory. Before PeopleTools 8.50, the full PeopleSoft installation was done on a single directory, including PeopleTools binaries, application external files, customized files, logs, etc. Also, in those installations using WebLogic and WebSphere, the J2EE deployment was normally located at PS_HOME/webserv (this was not the case for Oracle Application Server, which its their own directories for that purpose).

The main issue with this approach is that the Ops team would normally go nuts when they saw how the directories were structured in PeopleSoft. Very often, keeping read-only binary files and always changing log files on the same directory structure would not comply with the internal policies in many organizations. With some degree of manual configuration and symbolic linking, this issue could be tackled, but the solution increased the maintenance costs, particularly when a PeopleTools or application upgrade came into the scene.

Splitting Logic and Data

PeopleTools 8.50 provided the ability to split the PS_HOME directory contents into three different places:
  • PIA_HOME: contained the J2EE deployment, equivalent to the former PS_HOME/webserv directory.
  • PS_CFG_HOME: contained logs, traces and search indexes. Basically, any file created, modified or deleted at run time.
  • PS_HOME: contained the binaries and external programs such as Crystal Reports. Cobols and SQRs.
This was a major improvement. Now the binaries could be kept as read-only except when an external program was migrated. Moreover, the monitoring of disk space could now be restricted to PIA_HOME and PS_CFG_HOME.

PeopleTools and Applications in Different Rooms

PeopleTools 8.52, together with the PeopleSoft 9.1 applications, introduced a new directory: PS_APP_HOME. This directory contained exclusively the application binaries and external program files, leaving PS_HOME just for the specific PeopleTools files.

This approach allowed a simpler maintenance of the product. For instance, you could use the same PS_HOME for both PeopleSoft HCM and FSCM, keeping the specific application files in their own PS_APP_HOME directories. This way, when you applied a PeopleTools patch on PS_HOME, it would be available for all applications.

Clearly Identify your Customizations

The natural evolution of PS_APP_HOME was PS_CUST_HOME, which was introduced by PeopleTools 8.53. This new directory was meant to hold all the customized external files. This helped not only in maintaining PS_HOME and PS_APP_HOME almost readonly (they would be updated only by PeopleTools or application upgrades), but also to clearly identify the customizations, which is a tremendous gain when performing an application upgrade.

And now... Portable PS_HOME

PeopleTools 8.54 has gone a step further in simplifying the maintenance of the PeopleSoft installation. One of the issues we still faced with PS_HOME is that we could not move it to a different directory without facing issues, as there were some symbolic links and files containing absolute directory references within it.

This could be solved by adjusting the symbolic links and directory references, but it was a time consuming process. The alternative was to reinstall PS_HOME from the delivered install images, but in the best scenario, this could take a couple of hours.

In the latest PeopleTools release, all symbolic links were removed, and all the directory references are relative, not absolute. This allows the system administrator to easily move the directory to another location, or even to another server. Actually, you may not even need to move it. Just mounting the PS_HOME directory installed in one server into all the different PeopleSoft servers would make the trick, so you only need to apply changes in a single place.

I'm sure System Administrators and Installers will love this new feature. At BNB we are also analyzing other potential uses for it, but let me keep the secret for the moment ;).

Tip: One of the symbolic links removed in UNIX/Linux platforms was the PS_HOME/appserv/psadmin link. If you have any maintenance script to boot or shutdown services using this path, you will need to adjust it to the source location: PS_HOME/bin/psadmin, or just call psadmin after executing psconfig.sh.

Tuesday, October 21, 2014

PeopleTools 8.54 Features: Dynamic Alert Sliding Windows

One of my first memories in the PeopleSoft world was from by training bootcamp when I joined PeopleSoft. The instructor was showing us the Process Monitor functionality in PeopleSoft 7.5, where the button used to refresh the list of scheduled processes was represented by fetching dog named Sparky shown to the right of this paragraph.

It actually surprised me that an application button had a name, but that was the PeopleSoft style. Anyway, the poor dog did not last too much. In year 2000, with the introduction of PeopleSoft 8, our beloved Sparky was replaced by a boring Refresh button.

PeopleTools 8.54 has pushed this functionality to the next generation, making it potentially redundant. One of the new features in this release is the ability to show the status of the process within the same page were it is scheduled. This is a major usability improvement, as the users do not need to navigate to Process Monitor to check the status of the process instance. True, in previous PeopleTools versions there was also the possibility of running the process with output to Window, which using REN Server would achieve a similar result. The main drawback of REN Server is that it opened a new page/tab even before the process was finished, making the navigation more complicated.

The new functionality is called Dynamic Alert Sliding Windows, which is still more boring than Sparky, but what matters is the functionality, not the name. These notifications are enabled in the Process Scheduler System Settings page:


In this page, the administrator chooses which Status are going to be displayed to the user when running a process. As you see, the functionality is quite easy to setup and a significant step forward in usability of batch process scheduling.




Thursday, October 16, 2014

My global view on Oracle OpenWorld 2014

For those who can read Spanish, I just posted in our company blog an entry describing a general overview of Oracle OpenWorld announcements. A couple of weeks ago I made a post on this blog describing the most important outcomes from a PeopleSoft point of view. This new post gives a broader view.