PeopleSoft Upgrade Applications

If you would have noticed the recent changes to the Side bar in this blog you would have known that I did upload the recent demo version of Reapply Customizations utility which I had built. To actually know the approach followed by me in building this Tool take a look at this.

I’ve also included the Help document for all these Tools to walk you through the steps required to run the applications. If you have any questions kindly let me know. I would like to hear your feedback after you test these applications. I would also love to hear your suggestions for improvement.

But be warned you will need at least three instances to test the Reapply Customization application. I know – Flash Demo for Reapply Customization is pending. I am working hard on making Reapply Customization work for “Pages” – this is a challenge basically because PNLFLDID was added to PSPNLFIELD only after PeopleTools 8.40. We can see PeopleSoft Compare process failing in identifying exact page Customizations in the PRT files prior Tools 8.40. One of my friend actually wants to know why LASTUPDOPRID field was not added to PSPNLFIELD, I think it is more to do with the tedious task of updating this field for position changes (position changes are actually not very significant in the Report). I think PS could have added this field and updated it when something other than the position of the field changes in the Page – these are just thoughts.

The Customization Analyzer utility available in the Demo version does not provide the complete features – the missing portion is that the utility gives all the Navigation paths for each object in the report to help the functional consultant.

The Reapply Customization utility is aimed at providing comprehensive Documentation for the objects to which it reapplied the customizations. Certain tweaks would actually make these comments more comprehensive.

If you are interested in taking a challenge - try writing an algorithm to achieve Reapply Customizations for Pages (Points to ponder – Must be Tools compatible, Must only reapply customizations.). Any luck on this let me know.

Test it and let me know your feedback at nextrevolutioninerp@yahoo.com

PeopleSoft Upgrade Contribution

Oracle’s ideas on FUSION are headed in the right direction, thanks to its acquisitions. PeopleSoft PeopleTools/Application development worked so closely with the upgrade teams, which resulted in a good upgrade path (I would not call it Best! I still think PeopleSoft could have automated the process of Reapplication of Customizations – at least to a certain extent. With only one programmer at my disposal (which is me!) I was able to automate reapply customizations for records, fields, record fields, indexes, components, menus, indexes and translates (whew!)). They (The Upgrade Development Team) worked closely with the PeopleTools/Application development and ensured that the New Release does not put too much effort requirement into the Upgrade. Can't really take the credit away from PS because a single developer could not have achieved this had they not worried about the Upgrades.

Let me give you a clear pointer to this, PeopleSoft PeopleTools development wanted to remove Menus, but the Upgrade Development team identified the complexity which this would have brought to the upgrade. Although, attaching components to Menus involves a bit of effort it does provide us with the much needed grouping of related business processes. If I remember correctly, it was my mentor who put me this question “Why do we need Menus?” and digging into somebody told us it is for compatibility with Older PeopleSoft releases. We did agree upon this because we thought the advantage of Menus could easily be over-ridden by allowing the user to optionally attach these components to a Menu – This is what we thought the PeopleTools development wanted to achieve with the replacement of Menus. I have always wanted to ask somebody in PeopleSoft development whether this was actually a plan or a Myth! But this being a Myth or reality doesn’t really change things here; the Upgrade development played a critical role in PeopleSoft. Looking into the way Upgrades were presented in PeopleSoft, we really know that this did happen.

I’ll get back to the first line of this post; “Oracle’s ideas on FUSION are headed in the right direction, thanks to its acquisitions”. During my recent conversation with x-colleagues I heard them say that the Upgrade development team is involved with the FUSION development in pointing the challenges which FUSION will have on PS upgrades.

Another important aspect of this post is, I’m not trying to underestimate the capabilities of other Application products. ORACLE could have done it (But doesn’t look like it to me, when I was introduced to ORACLE application upgrade, it did not look like I would have understood it in 2 days. This was the amount of time required to understand PS upgrades.). If there is another company (other than PS) in FUSION whose contribution I wouldn’t doubt it is definitely SIEBEL.

Small note here, another of those useful information which I came across recently is, a Customer of ORACLE migrated from ORACLE applications to PS. One of the senior members in PS had this to say, “PS HRMS 8.9 is easily the best product available in the market currently. Did you ever hear about a Customer moving from the parent company to the acquired company?” Of course heard about this from x-colleagues. I was not successful enough in getting this information from the internet, and I'm not able to recall the name of the Customer. Probably give it to you in a later post.

Disclaimer: The thoughts mentioned here are strictly mine.

Oh! blogs are so much easier to write (No flashy marketing lingo required), White Papers are not!!! I really have miles to go before I could finish the White Papers assigned to me. I'll try finishing atleast a couple before I could return to the blogspot.

Past, Present and Future of Applications

1980’s

XYZ Corp is a huge organization, the business requirements of this organization are spread across various processes. XYZ is facing the requirement of using Software to make their business process efficient. XYZ talks to developers and suggest that they build applications for each of their complex business process. The developers at this stage build applications for XYZ which will help XYZ in making their business process efficient. The problem with this was that the developers had to build each business process individually and the amount of effort required for this is a lot. Applications developed for different processes were developed using different technologies. Now, when the XYZ thinks about integration the Technology factor of the applications has a big disadvantage. The other constraint on these applications was that, certain developers chose not to make their source code available to the Customer. XYZ has to depend on the developer to make any changes to the application and XYZ were at the mercy of these developers to support these applications.

1990’s

XYZ Corp was looking for something reliable. The ERP companies came to the market with lots of promises. An ERP would contain all the applications required for any organization – this reduces the requirement of building separate applications for each business requirement. These applications would be built on a single platform – makes life so much easier! XYZ has gained control on the developers and restricts them to use only the ERP development framework to build the applications. The other major breakthrough which came in was, the ERP companies were willing to make available all the code which drives the various business processes – XYZ has the capability to customize the application and can make it work the way they want.

2000’s

The ERP industry has become a place where only big players can be present. All the major ERP players (Why did I say that? I could have said the two major players!) are focused on companies like XYZ Corp. The major players know for a fact that companies like XYZ can provide all the funds required for running the ERP industry. The annual support fee charged by the ERP players would give them the capability to grow in the market. Also companies like XYZ would move to the newer releases of ERP. XYZ expects these newer releases to make their life simpler, replace their Customizations with delivered Processes, whereby the number of staff (read: Customer staff) required in maintaining these Customizations can be reduced. But in reducing these Customizations they do not realize the fact that these applications are making their business rigid. Yes I concur with this quote which I took from Neil’s comment

“Yes, I like that term: “adaptation” rather than “customization”.

2010’s

The major players in the ERP industry have forgotten about the millions (or billions) of small and mid sized companies which could prove to be a bottomless well of fortune. The next generation of major ERP players are raising the bars rapidly. The Customers of interest for these ERP vendors are the smaller companies which face the same problem as what XYZ did in the 1980’s. Now these ERP vendors provide the smaller customers the applications required by them at a very low cost of ownership. They have achieved this by allowing multiple Customers to be placed on a single instance which will be hosted by these ERP companies. The data security is the responsibility of the ERP Company and they have achieved this by extending the Row-Level (Row-Level security allows user’s with proper rights to access their information) security concept of the previous decade. These ERP companies also allow Customizations to these applications by providing the Customer with the business process source-code. The Customer can make Customizations to the business processes and send the Customizations back to the ERP Company; they would host his application with Customizations at a slightly higher fee than the non-customized applications.

Although, the very essence of hosting Applications in a single instance started with the concept of all the application available to the Customers will be uniform. The decade saw the process evolve, the Processing Server (Application Server in the case of PeopleSoft) knew how exactly to present different Customizations to different Customer’s from a single instance. But at this stage these companies have found out ways of allowing multiple processes co-exist nevertheless still can’t find ways of making the Customizations at the Database Table (PeopleSoft Record) level co-exist.

The important aspect of this post is that 2010 has not started and there will be many more innovations which would drive 2010 to be what I expect it to be. And for the constraints that I’ve mentioned and omitted, the solution will be provided by a conglomeration of ideas (I mean not just my thoughts!). I’ve a couple of White Papers to write and should be some time before I can start posting again.

Security Part 2

It was an awesome week! (I mean the last week) I went out trekking with my cousins. I was out of work for two weeks and I make sure that I do not go to the computer when I’m on a break. I’m back to work today and back blogging. I just finished preparing a presentation and started to hack PeopleSoft. Thought I would reveal some aspects of it here.

Firstly, PeopleSoft PeopleTools Team is great. I hacked into the first level (I’ll not precisely mention the route which I took, but it is all there in the post “Security”.) and found out the private key used by PeopleSoft to encrypt the password. My God! What a Key (It just made me feel what it said)! (As before, I’ll not give it out.) Then started doing a Google search for this particular weakness of PeopleSoft at the Development Environment in two-tier and this is what I found,

http://seclists.org/lists/bugtraq/2006/Feb/0080.html

I would like to quote a few points from the above mentioned link; PeopleSoft (ORACLE) has provided the following solution…

Vendor Solution: (Provided by Oracle)

In Enterprise PeopleTools 8.47 and above, PeopleTools provides Triple DES encryption (i.e 3DES) for increased data security. The PSCipher Utility has been enhanced to provide a command line utility to encrypt a variety of text values stored in various configuration files throughout your system. In addition, the PSCipher includes the following features:

• Dynamic Key generation: The ability to generate unique encryption keys.
• Version maintenance: The key file maintains a version history of all previous versions of the keys, which enables text previously encrypted to be encrypted or decrypted.

Important additional information:

It is important to provide proper scope to the usage of PSCipher.

PeopleSoft does NOT use PSCipher for the following encryption purposes:

PSCipher is NOT used for the encryption of ANY application data -

PSCipher is NOT used for the encryption of ANY data stored in the PeopleSoft DB.

ALL user passwords stored in the DB are hashed using the SHA-1 Secure Hash Algorithm

At last with PeopleTools 8.47 we have Dynamic Key generation and version maintenance. But still it can be hacked! How safe is safe? This time I’ll not tell how I’m planning to break this Dynamic Key security, but if you see closer you could probably see the weakness.

So, what is my purpose with hacking PeopleSoft? (I’ll not be unethical in retrieving sensitive information.) It is got to do with the Tools that I have; I just want to add the feature of PeopleSoft USER ID capability to the Tools. One of the Tools which I’ve built will actually run all the SQRs (in any given folder) in one shot, but it requires access id and password. This did not find much appreciation because Reports were to be run with specific user privileges, for this I wanted the users to create separate access ids with different grant permissions and then use the Tool. Users are against the concept of creating separate ids and want it to be done with PeopleSoft User id. This can only be achieved if I could decrypt the PeopleSoft encrypted password and use it to connect to the database (Initial connection to retrieve passwords can be done using connect id and password).

Although the other aspect which has to be considered for the SQR tool is that Application Server will have direct access to the SQRs but I’ll need the exact location of the files to be provided to the utility and most users will not have this information. Trying to work something out for this. If I dynamically accept SQR locations, user could very well provide a fake location and place a custom SQR with the SQR name that he has access to and write any SELECT or INSERT within it! Security not to be overlooked from my side.

I have lots more to write about (a post on Foreign Key usage in ERP….a post on removing Menus from PeopleSoft….). I would reserve these for sometime later in this week. Think it is going to be a hectic week, two-week work pending!

PS: Started learning Java. I tried coding a Message Box….oooppphhh…it sure is one coding language…then settled for printing in the console.

PeopleCode to Java

A couple of my x-Team-members told me recently that they would be a part of the Team which would build the PeopleSoft-Oracle Fusion Upgrade (Note: I was never part of ORACLE Corporation and will never be.). I was exited about this and thought I would post some ideas that I would have implemented if I were to do this.

Most of the blogs that I’ve read recently point to one of the most crucial aspect of this Upgrade – Replacing PeopleCode with Java. I will post some thoughts of achieving this and then talk about the object level differences. The amazing thing about PeopleSoft upgrades is that they make life of an Upgrade Consultant to be a cake-walk.

The Fusion team must first concentrate on building an application which would parse the PeopleCode and convert them into Java equivalents. Make modifications to PeopleTools so that the compiler will actually compile Java instead of PeopleCode. Now, anybody who has written a small piece of code to parse a file will know for certain that the amount of time required to parse the file is going to take ages. Let me give you an example, I used to upgrade SQRs from older PS release to newer releases (7.5 to 8.8). PERSONAL_DATA was a pain – if an SQR had PERSONAL_DATA in old release, then in 8.8 it was not available to upgrade the SQR we had to replace PERSONAL_DATA with PERSON, ADDRESSES, NAMES and PERSDATAEFFDT depending on which fields were selected from PERSONAL_DATA, i.e. if in the old release NAME was selected from PERSONAL_DATA we had to replace it with NAMES and add two more criteria (NAME_TYPE = ‘PRI’ and EFFDT = current date). The code that I wrote had to check for so many different possibilities (Nobody follow standards!) and also take care of the documentation within the SQR ( “! Modified by ps-guy” – this kind of stuff for each modification). I think that is enough (I feel bored about it!), the point that I’m trying to make here is, when I finished this code I astonished by the amount of memory constraint on my machine and the amount of time it took, although I used a very efficient logic (This could also be attributed to the fact that I’m a VB programmer and not a Java geek – Too lazy to learn something, VB and PeopleSoft did not require any effort – Refer to the Title “Driven by …” – a small note here planning to change the Title to “Powered by PeopleSoft Motivated by MicroSoft”). The other important aspect of an application performing that job for you is that you do not have to do it anymore – Keep your machine busy rather than yourself. Although there will be huge amount of constraint on the time required for the application to complete this conversion of PC (PeopleCode) to Java it could save the effort.

But I think that ORACLE should plan this properly, Replacing Java compiler for PC compiler should be done with one more release of PeopleTools (say Tools 8.9, I heard that work for Tools 8.48 has started). Build PC-Java Converter and convert all the PS delivered PC for Application 8.9. Now the PS QA team (PS QA has a total strength of approximately 60 people for HR CORE compare this to 5 people on ORACLE side – Info based on yesterday’s discussion with my friends – PeopleSoft does not treat QA lightly) - will have their part to play, they will have to test all these conversions and make sure that they work as they used to. If any error is found then PC-Java team must review the code and try modifying the application to handle this scenario.

Once PC-Java is internally tested ORACLE could deliver it to the clients so that they can convert all their Customizations in PeopleCode to Java. The PC-Java application must allow the user to select all the PeopleCode that he wishes to convert (This will allow me to convert only the Customized PC and replacing the Non-Customized PC with the new delivered Java Code), thus reducing the amount of time required at the Client location. The application must allow the user to phase the conversion of PC to Java.

So will the PC-Java converter do the trick for us? It will to a certain extent, but still there is an issue of Customer training. We cannot ignore this factor as a Client would have recruited 100 Consultants with PC skills, they being his permanent employees and he cannot do away with them. For this ORACLE must take an initiative which would benefit them in the long run. ORACLE must provide Java training to all the Clients and Partners at their own expense. This would motivate the Clients in moving to Fusion (A benefit in the long run!).

I have solved the PC – Java puzzle to a certain extent (I strongly believe that this can be achieved!). How about the other objects? It still remains a mystery to me as to how ORACLE is planning to store the objects (Fields, Records, Pages etc…PS terms). I do have some idea on the approach that ORACLE will be taking and as always have a plan to clean things up – I’ll reserve that for a later post.

This is how I would handle Fusion Migration. If you have better ideas do let me know.

SQL

There is one question which keeps coming to my mind, Are my thoughts wise or rotten? The answer to which is still not known, but I use this blog to document all that which comes to my mind about an ERP product. Another important reason is that if someday I start building my ERP it should at least be satisfactory to myself.

The PSQuery is a very good application to develop your queries; but I’m not satisfied with it. When I want to create a query which will select all the employee names from person table with some criteria, the steps to be performed are:

New Query
Select PERSON from the list of tables.
Select NAME from PERSON table
Go to the criteria tab and provide my criteria

Simple isn’t it? A simpler solution would be, allowing me type “SELECT NAME FROM PS_PERSON WHERE blah-blah”. The SQL tab provided by PSQuery is non-editable. The reason is, once I build the query following PeopleSoft PSQuery standards then the application will know how to construct the SQL from my definition, this is non-geek. PeopleSoft answer to the non-geek community. This is where the geek community should be addressed, it would be wonderful if the SQL tab is editable and allows me to directly type the SQL and then constructing the Query objects (Query objects refers to PeopleTools data for each query) from my SQL statement.

Although the Application Designer has become an integral part of every Technical Consultant, the geek interface for this is still missing. I know how to create a table using SQL and Application Designer (I agree that most of us do know this), but wouldn’t it be better if I could do this,

New Record
From SQL
Type in the SQL – “CREATE….”
The Application Designer must parse this statement and create the field definition. (I know I’m missing a lot of pieces here…read on)
Then create the record definition

When the Application Designer tries to create the first field it would get the basic information (Field name, Field type and length) but there are other properties which will be needed by the Application Designer to complete the creation of field, it includes Labels, Formats, the option of creating translates in a few cases, description and chartfield. The Application Designer must prompt the user to provide these inputs which cannot be found in the SQL. If a Field name does not fulfill the criteria set by PeopleSoft for fieldnames it could prompt the user to change the fieldname and set the cursor on that field in the SQL. The record creation will include the complexity of index creation, but this should not be an issue if we follow the same pattern as prompting the user for key information or allowing him to type the “CREATE INDEX” SQL.