Being able to access other logic from PeopleCode goes all the back to the earliest days of PeopleTools. I’m not referring to be able to schedule batch processes written in some language, but the ability to directly access the other logic directly in your PeopleCode.
“Declare Function” was the syntax of how you could access functions from .DLL files on Windows (.so files on Unix/Linux) and use those from PeopleCode. Passing parameters was a little tricky unless you had C coding experience though, and it was really difficult (but not impossible) if the functions that you wanted to call dealt with C data types, such as structs, that didn’t map well to PeopleCode types.
Even if you could figure out the parameter passing stuff, you really couldn’t do much on the C side in terms of accessing the PeopleTools framework. This was OK if you were accessing some library that wasn’t yours (I used to do a bunch of this to call Windows API functions), but if you were creating the logic yourself everything had to be driven from the PeopleCode side. Overall, the complexity and the limitations combined to limit the adoption of this. All of this is still supported in PeopleTools today though; I know a few customers that make extensive use of this.
A big jump forward came in PeopleTools 6 with good support for calling COM objects (OLE was the term du jour back then and is still reflected in the PeopleCode function names for working with OLE/COM – I’ll just call it COM now). Using COM only works on Windows, but that was still in the “code on the client” days, so not really a big issue. It also works quite well on a Windows server running PeopleTools today.
A huge part of the value was in how much work Microsoft and other 3rd parties put into making it easy to create COM objects. You were no longer required to write C code, but instead you could use something like VB. Also, there was a huge number of 3rd party COM objects that were created and available for reasonable prices.
The other part was that the PeopleCode language and runtime were enhanced so that they actually understood something about COM. You could actually have a COM object reference and use it directly when writing your PeopleCode. As compared with dealing with raw memory references when doing anything tricky with the C code side, this was a big step forward.
Unfortunately, the COM integration suffered the same problem as the C level integration in that PeopleCode could call into COM, but the code on the COM side couldn’t actually leverage any parts of PeopleTools; just parameter passing back and forth. You couldn’t do something like let the COM side tap into your database connection to do some work. Also, COM was pretty much limited to Windows. We were familiar with some of the tools that provided a compatibility layer on Unix, but we never felt comfortable relying on that. Siebel used to use one of these products to provide Unix support, but I remember seeing their platform support notes one time and it had a truly bizarre list of things that didn’t work properly on various Unix versions (lots of stuff along the lines of “text wrapping on report output does not work on foo Unix version”). It might have been the way that they used it, but they had a lot of smart engineers, so there was no guarantee we wouldn’t have borked things up as well.
One thing that I skipped over in the COM section was that PeopleTools 5 actually had some support for DDE (Dynamic Data Exchange), which was the precursor to COM. DDE never caught on in the broad marketplace as well as COM did, so it wasn’t used very much within PeopleCode either.
PeopleTools 8 took the next big leap forward by adding support for Java. This brought all of the good things about COM (good developer support, lots of 3rd party tools, understanding of the language in PeopleCode) to all of the platforms that PeopleSoft supported. Even more importantly was that the integration was bi-directional. You could actually write some Java logic that could do things like reference PeopleTools system variables, use the database connection, etc.
Note that I’m not referring to Component Interfaces here. Component Interfaces are a way of re-using high level PeopleSoft components. They have PeopleCode, Java, COM, and C bindings, but they are not a way of extending existing business logic inside a component. A lot of people confuse the two though.
Additionally, PeopleCode got some long overdue enhancements in PeopleTools 8 (object PeopleCode in particular). Instead of hard-coding references to things like which records and fields you were working with, you could do things like have Record and Field objects, which let you write code that wasn’t so tightly coupled (of course, lots of people still did write tightly coupled PeopleCode, but that’s another story).
The nice thing about this was you could something like creating a Record object in PeopleCode, pass it into your Java code and the Java could would “know” that it was a PeopleTools Record object. In fact, if you look in your PSHOMEclass directory of your PeopleTools installation, you’ll see a peoplecode.jar file. That provides the Java implementations of a large portion (though not all) of the PeopleTools objects that are accessible from PeopleCode.
I’m planning on another posting about some of the, um, quirks of using Java and PeopleCode together, but overall it is a huge improvement over previous methods of integrating with other languages.
The Future That Was To Be
So what was left to do for language integration? One of the things that was planned for PeopleTools 9 was to finally provide direct support for writing Java logic directly in the design tool (today you can call Java logic and have the Java logic call back, but you have to actually write that logic elsewhere, manage the source code elsewhere, etc.).
Another issue was that any business logic in other languages didn’t get the same automatic runtime distribution that PeopleCode did. The automatic code distribution was really a nice feature back in the client/server days, but it still comes in handy for getting code changes out to multiple application servers (occasional cache corruption not withstanding). All of the other language integration that we’ve talked about here requires external effort to distribute the code to the runtime environments. Not impossible to do, but better if it’s just built-in.
Solving those would have really put Java on equal footing with PeopleCode in terms of support. Instead, Java is lapping PeopleCode since there won’t be any PeopleCode in Fusion.
This will cause some people some heartburn (Java is definitely more complicated than PeopleCode), but there’s something to be said for having one clear choice. We actually spent a long time debating this during the oh-so-long and here-we-go-again planning process(es) for PeopleTools 9; drop PeopleCode altogether or offer both?
The idea for dropping PeopleCode was based on the idea of offering more meta-data driven ways of performing the most common customizations and giving a clear choice on language when you did need to write code, but we knew that there are a lot of folks out there that have gone way beyond simple customizations with PeopleCode (I know some that are reading this blog right now!), but aren’t skilled up in Java yet.
But there’s no point in debating that now 🙂