PeopleSoft and Docker's value proposition

If you haven't heard yet about Docker and/or container technologies, you will soon do. Docker has made one of the biggest impacts in the IT industry in 2014. Since the release of its 1.0 version on past June, it has captured the attention of many big IT vendors, including Google, Microsoft and Amazon. As far as I'm aware, Oracle has not announced any initiative with Docker, except for the Oracle Linux container. Still, Docker can be used with PeopleSoft, and it can actually simplify your PeopleSoft system administration. Let's see how.

What is Container Technology?

Docker is an open platform to build, ship, and run distributed applications. Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.

In a way, it is similar to virtualization technologies like VMWare or Virtualbox where you can get an image of a machine and run it anywhere you have the player installed. Docker is similar except that it just virtualizes the application and its dependencies, not the full machine.

Docker virtual machines are called containers. They run as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.

Docker uses a layered file system for its containers, in a way that they can be updated by just including the changes since the last update. This greatly reduces the volume of information that needs to be shipped to deliver an update.

How can it be used with PeopleSoft?

As we have seen, Docker containers are much easier to deploy than an entire virtual machine. This means that activities such as installations can be greatly simplified. All you need is to have Docker installed and then download the PeopleSoft container. Of course, this requires that you first do an installation within a Docker container, but this is not more complex than doing an usual installation, it just requires some Docker knowledge in order to take advantage of all its features. Under my point of view, if you are doing a new installation, you should seriously consider Docker. At BNB we have prepared containers with the latest PeopleSoft HCM and FSCM installations so we can quickly deploy them to our customers.

Also, when you make a change to a Docker container, just the incremental changes are applied to existing running instances. This poses a great advantage when you apply a patch or run a PeopleTools upgrade. If you want to apply the patches to a new environments, you just need to make sure that you apply the latest container changes in all the servers running the environment.

Isolation between running instances is also a major advantage when you have multiple environments in the same server. Suppose you want to apply the later Tuxedo patch just in the Development environment, which coexists with other environments on the same server. Unless you had one Tuxedo installation for each environment (which is possible but normally unlikely), you would need to go ahead and hope the patch did not break anything (to be honest, this happens very rarely with Tuxedo, but some other product patches are not so reliable). If you have a separate container for the Development environment you can apply the patch just to it and later deploy the changes to the rest of environments.

Last but not least, the reduced size of Docker containers compared to an entire virtual machine greatly simplifies the distribution to and from the cloud. Docker is of great help if you want to move your on premise infrastructure to the cloud (or the other way around). This is even applicable when you want to keep a contingency system in the cloud, as delivering the incremental container changes made to your on premise system requires less time than using other methods.

Not only that, Docker can be hosted in most operating systems. This means that moving a container from one public cloud facility to another is significantly easier than it was with previous technologies. Exporting a virtual machine from Amazon EC2 to Google Cloud was quite complex (and under some circumstances even not possible).

Limitations

But as any other technology, Docker is no panacea. It has some limitations that may restrict its adoption for your PeopleSoft installation. The main ones I can think of are:

• Currently there is no support for containers using Windows as a guest operating system. This is not surprising, as Docker in intimately linked to Unix/Linux capabilities. Still, Microsoft has announced a partnership with Docker that will hopefully help to overcome this limitation. For the moment, you will not be able to use Docker for certain PeopleSoft components, such as the PSNT Process Scheduler, which is bad news if you are still using Crystal Reports or Winword reports. Also, if you are using Microsoft SQL Server as your database, this may be a major limitation.

• Docker is most useful when used for applications, but not data. Logs, traces and databases should normally be kept out of the Docker container.

Conclusions

Although container technology is still in its initial steps, significant benefits are evident for maintaining and deploying applications, PeopleSoft included. Surely enough, the innovation coming on this area will have a big impact in the way PeopleSoft systems are administered.

PS: I would like to thank Nicolás Zocco for his invaluable research on this topic, particularly in installing the proof of concept using PeopleSoft and Docker.

PeopleSoft's paths to the Cloud - Part III

In my previous posts on this series, I have covered how cloud computing could be used to reduce costs and maximize the flexibility of PeopleSoft Development and Production environments. In both cases, I focused on one specific area of cloud computing, Infrastructure as a Service (IaaS).

Today I will explain what kind of benefits can be expected by using another important area: Database as a Service (DBaaS). Instead of using an IaaS provisioned server to install and maintain your database, DBaaS providers take responsibility for installing and maintaining the database.

There are many players in this market, including Amazon, Microsoft and Oracle. The service features may differ, but in a nutshell, they normally offer these capabilities:

• Backups: the database backups are automated, and you can decide to restore point-in-time backups at any moment. You can also decide when to take a snapshot of your database, which may be eventually be used to create another database instance (for example, to copy your Production database into the User Acceptance environment).
• High Availability: while some IaaS provider do not support high-availability database solutions such as Oracle RAC (for instance, it is not supported by Amazon EC2), many DBaaS providers include high availability by default.
• Contingency: some providers maintain a standby copy of your database in another data center. This allows you to quickly restore your system in the case the original data center's services are lost.
• Patching: although you can decide when to apply a database patch, the DBaaS will do that for you. In many case, you can turn on automatic patching, in order to make sure your database engine is always up to date.
• Monitoring: providers give the system administrators access to a management console, in which they can monitor the database behavior and add or remove resources as needed.
• Notifications: in order to simplify the monitoring effort, you normally have the possibility of setting up notifications to be received by email and/or SMS upon a list of events, which may include CPU usage, storage availability, etc.

Under my point of view, these services offer significant advantages for PeopleSoft customers, particularly if your current architecture does not support all the previously mentioned services or you do not have the right DBA skills in-house. Even if your organization does not fall in these categories, the scalability and elasticity of DBaaS providers is very difficult to match by most internal IT organizations.

In any case, if you are interested in using Database as a Service for your PeopleSoft installation, make sure you correctly evaluate what each provider can give you.

PeopleSoft's paths to the Cloud - Part II

In my previous 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.

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.

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

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

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

b) Add the new field in the original record.

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

However, this option also has its limitations:

• Querying the table now would involve joining two tables. This leads to additional complexity and performance issues (particularly if customizations have been made by adding sibling records to multiple records in a query).
• When creating a query, you may need to filter on both the standard record and the sibling one. In that case, you won't be able to use an index on both filters, as the fields are placed in different tables.
• Adding a sibling records means you need to use an additional scroll area in components showing both the original record and the standard one. In some situations, this may put in a situation where the 4 allowed scroll levels (0, and 1 to 3) are not enough.
  

Mainly due to performance reasons, my preferred option is b). In order to keep a clearer track for upgrades and fixes, what we normally do is to place new fields in a subrecord defined explicitly for customized fields. In such way, it is always easy to identify the customized fields in a record.

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

ExcelToCI limitations: when not to use it

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

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

What are the most significant ExcelToCI limitations? You may find others, but from my experience, these are quite important:

• ExcelToCI does not allow to determine the order in which fields are loaded into the application. The order is determined by the tab order defined at the page level in Application Designer.
• Loading large data volumes becomes unpractical for performance reasons. Excel could easily hang when manipulating spreadsheets with over 10,000 rows.
• Excel becomes nearly blocked when executing the load. It's difficult to perform any other action on the same workstation, and particularly to load several files in parallel.
• Can only run in Add or Update mode, but there is not hybrid option to first try to Add and then Update is the row was present.
  

At BNB, we built a tool called FileToCI (Ok, not much marketing brainstorming here!) that deals with most of these limitations:

• Lets you choose in which order you want fields to be loaded.
• Loads from CSV files or database tables, which are much easier to handle than Excel files.
  
• Lets you load different files in parallel. Processing is done at the server level, without capturing your local resources.
• Includes a Hybrid load option, which only adds the rows that were not present before the load and updates the remaining ones.
  

Again, I'm not saying ExcelToCI is useless. That would be far away from the truth. Reality still is that for setup data load and certain types of conversion, ExcelToCi remains a very intuitive and powerful tool.

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

How BPEL adds value to PeopleTools 8.48?

One of the key enhancements delivered in PeopleTools 8.48 was integration with Oracle BPEL Manager. Oracle's description of BPEL is:

Oracle BPEL Process Manager, a member of the Oracle Fusion Middleware family of products, enables enterprises to orchestrate disparate applications and Web services into business processes. The ability to quickly build and deploy these processes in a standards-based manner delivers critical functionality for developing a Service-Oriented Architecture (SOA).

Now... how this translates into real-world cases?

Recently, we had to design for one of our customers a Web Service based integration of PeopleSoft Financials with a Third Party Billing system. One of the integrations consisted in the Third Party system sending information to PeopleSoft Financials in order to perform the following actions:

• Create the customer if it was not present.
• Create the invoice as a pending item in PeopleSoft Receivables module.
• Run Receivables Update process.
• Create the deposit and apply it to the item.
• Run Receivables Update process again to update customer's balance.

Before BPEL, if we wanted to create this integration, a solution would have to create a Web Service in PeopleSoft that encapsulates all these activities. The problem of this approach is that this new Web Service would not easily reusable, as most consumer applications will only require part of the operations performed in it.

With BPEL, we can keep Web Services at the right granularity to help making them reusable. Following with the example, we would just make sure the following Web Services exist (taking into account that some of them may be already available in the delivered product):

• Customer creation.
• Pending item creation.
• Receivables update processing.
• Deposit creation and application.
  

BPEL would then be used to orchestrate these Web Services, without requiring to build aggregated and poorly reusable Web Services in PeopleSoft.

In summary, BPEL seems to bring PeopleSoft applications to the next level in what relates to integration with Third Party applications. Also, being BPEL one of the keystones of Oracle Fusion Architecture, it seems a wise decision to gain some BPEL experience as this might be a highly demanded skill in the near future.

Note: Although Oracle ships its BPEL Manager product together with PeopleTools 8.49, this license only covers design-time use. For runtime use, you should purchase Oracle BPEL Manager separately. For more information, please refer to:

http://download.oracle.com/docs/cd/E05453_01/psft/acrobat/pt849_lic_notes.pdf