Today, we are ready to announce availability of the Grey Sparling nVision Auto-Drill snap-on. From our previous postings on nVision and drilling, we've had lots of questions and interest related to the subject matter in them. For those who haven't read the entries, here is the most recent one.

As we spent time helping these customers out, we realized that there was an opportunity to provide a "snap-on" product that addresses these needs (especially since many of the suggestions we provided have development impact across reports that that leverage those suggestions). The idea is that this product is "install-and-go", allowing a customer to put it in place without having to set aside time in the project plan to implement it. It also means that you don't have to modify your existing nVision reports (or drilldown layouts) or write code (or complex excel functions) to extend your drilling functionality.

Product Features

This snap-on replaces the DrillToPIA.XLA. For those not familiar with the PeopleSoft-delivered DrillToPIA.XLA, it's an excel add-in that enables drilling from excel without having to install nVision on a client machine. Our product addresses the following limitations in the PeopleSoft-delivered drilling solution.

• Configurable Excel menu that lists out the drills that can be run (without having to get the list from a page). Click on the menu item, and the drill runs to window without any other user intervention.
• Rules-based layout picker. You can define a mappings between field or tree node values and drills to run. Double-click on any amount in your report instance, and the snap-on figures out which drill to run based on the context of the cell, and runs it without any user intervention.
• Drill to query from Excel menu. The snap-on automatically figures out, based on the number you're drilling from, the parameters to pass to the query (no need to build a hyperlink formula that has the parameter references encoded in it).
• Drill to PeopleSoft page from excel menu. Again, the snap-on automatically figures out, based on the number you're drilling from, the parameters to pass to the PeopleSoft page (no need to build a hyperlink formula that has the parameter references encoded in it).
• Drill URI substitution. Because the link to drill is embedded into report instances, you are stuck if for some reason, you need to drill from the report after your PeopleSoft web server URI changes. Although you could write a program to fix the NvsDrillHyperlink defined name, our snap-on allows you to fix this problem without having to modify the report instance XLS file.

What do you mean, "Install and go?"

Good question. "Install and go" means that you can take the software from us, install it, and start using it right away. Sounds great, right?

We've put a lot of thought on how you would deploy it, so that it is easy to get up and running. As such, the snap-on has the following components:

• PeopleSoft server-side logic to invoke the nVision drilldown without opening the delivered drilldown page.
• Excel add-in with all the client-side code.
• Spreadsheet with configuragle rules used to generate menus, override the URI, and pick drill layouts.

Wow, Sounds great, but it must be expensive

Actually, we've priced it low enough that most project sponsors can buy it within their purchasing authority. We believe that if customers like this product, that they'll come back for some of the products that have some change management impact (such as deploying report security).

If you want more information about this new product, feel free to contact us.

Since Java is the language of choice for the Oracle Fusion applications, I thought it would be nice to have some posts that show some good tips and tricks related to using Java within PeopleSoft today. As I mentioned in the previous post there are a few quirks in the way that Java and PeopleCode work together. Well, as Bill Cosby once said, "I told you that story so that I could tell you this one" :-)

The quirk that we'll cover today has to do with the way that the mapping between PeopleCode and Java datatypes works. I have a few quirks that I've known about for awhile, but I got bitten by this one just recently while working on a follow on to a previous blog entry about version control and PeopleTools. The idea was to show an example of using the JavaSVN java library from PeopleCode to be able to place application data under version control (application setup/configuration data, not something like Ledger entries).

The library works great directly from within Java code, but I hit some strange behaviour when trying it from PeopleCode, and it turned out that the fault is in the way that PeopleCode was passing Null into the Java side.

To simplify things, imagine that you have the following Java class that exposes these static methods.

package com.greysparling.demo;

public class JavaPeopleCode1 {
 
   public static boolean IsObjectNull(Object test1) {
       if (test1 == null) {
           return true;
       }
       else {
           return false;
       }
   }

   public static boolean IsStringNull(String test2) {
       if (test2 == null) {
           return true;
       }
       else {
           return false;
       }
   }
 
}

You'd think that these methods would each return True when you pass a Null from PeopleCode into them and False otherwise. When we call these from a short AppEngine program (side note: using AE is a great way to test out these sorts of quick test things) we see otherwise.

Local String &sClassName, &sPeopleCodeString;
Local JavaObject &demo;

&sClassName = "com.greysparling.demo.JavaPeopleCode1";
&demo =  GetJavaClass(&sClassName);
&sPeopleCodeString = "Testing";

Warning (&demo.IsObjectNull(&sPeopleCodeString));
Warning (&demo.IsObjectNull( Null));

Warning (&demo.IsStringNull(&sPeopleCodeString));
Warning (&demo.IsStringNull( Null));

Here's the output that we get from running this (miscellaneous junk from the log has been trimmed out).

False
True
False
False

Notice that last one? We would have expected that to return True since we're passing Null. It turns out that any object type that PeopleCode has a direct mapping for (such as a PeopleCode string with java.lang.String), you can't pass null. Or more accurately, if you pass Null from the PeopleCode side, you won't actually get null on the Java side.

Annoying eh?

The workaround for this is to create some additional Java glue code and call that from the PeopleCode side.

Labels: PeopleCode

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

"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.

OLE/COM

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.

Java

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 PSHOME\class 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.

One other big benefit of the Java integration is that Java as a platform actually supports a lot of different programming languages. Popular languages such as JavaScript and Python (and numerous others) provides ways of running their code directly in a Java Virtual Machine. I've personally been a big fan of the Rhino implementation of JavaScript for the JVM and have used that to run server side JavaScript inside of a PeopleCode event before.

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 :-)

Labels: PeopleCode