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.