This is another blog entry I started a while back, but never completed. As mentioned in yesterday’s entry, there was a lot of work done in PeopleTools 8 that didn’t get much visibility (because it didn’t makes sense with the new paradigm). This feature fits into that category (but it allows you to do some very cool things).
This interface allows you to control nVision in a manner similar to the design UI. For example, you can programmatically populate an nVision report request and run it from VBA without saving it or using the PeopleSoft-delivered dialogs. You can also use it to define criteria in an nVision report and even invoke nVision dialogs.
Sadly, no. You see, this feature puts a VBA interface on top of the nVision designer features. Again, this was all done back when the primary means of running nVision reports was on the client and not on a server. Because we hadn’t had the paradigm shift of “no code on the client” yet, people were still putting code on desktops and our initial focus of this release was to improve the client/side functionality.
Unfortunately, when we eliminated code on the client; we also eliminated the foundation for these features (unless customers continue to deploy the client/server code).
Okay. I see, so why are you even covering it then?
Good question. You see, there are still a lot of situations where this level of automation is good:
You see, you can create some macros to do things such as swap the data source of a report, etc that are utilities for a developer through the hooks. You can also create a new process definition for running nVision with the designer loaded (the existing process definition causes nVision to start with the designer not loaded for performance and stability purposes). When running this way, you can have simple routines that could ensure that report requests are set up appropriately, etc (which is desirable if you’re not in a position to use the new security hooks in the report request page added in PeopleTools 8.44).
Unfortunatey, this is one of the few places where PeopleBooks will not help you. Although there is a section in PeopleBooks for them, the documentation is wrong. Therefore, you will want to use the object browser in VBA to see what is available (and because the DLL you browse has a couple of issues with the object browser, you’ll need to pull it in twice).
Here are the steps you go through to do this:
Now that you’ve done that, you can start looking at the classes, properties, and methods available to you in VBA
nVision Report Requst
The first class of interest is the report request class. Here’s a screenshot of it (click on the thumbnail to see a full-sized version of it).
Another class of interest is the criteria class (where you can set and change criteria). Here’s a screenshot of it (click on the thumbnail to see a full-sized version of it).
In our nVision bolt-on, we are in the process of building web services for all these classes. These services allow client-side logic to call the server-side code with logic and prompting without requiring installation on the client. This will allow you to perform this level of automation regardless of the entry point.