Using OLE Functions
This section provides an overview of OLE functions and discusses how to:
Use the Object data type.
Share a single object instance.
Use the Exec and WinExec functions.
OLE automation is a Microsoft Windows protocol that enables one application to control another’s operation. The applications communicate by means of an OLE object. One of the applications (called the automation server) makes available an OLE object that the second application (the client application) can use to send commands to the server application. The OLE object has methods associated with it, each of which corresponds to an action that the server application can perform. The client runs the methods, which cause the server application to perform the specified actions.
PeopleCode includes a set of functions that enable your PeopleCode program to be an OLE client. You can connect to any application that’s registered as an OLE automation server and invoke its methods.
Note: Differences in Microsoft Windows applications from one release to the next (that is, properties becoming methods or vice versa) can cause problems with the ObjectGetProperty, ObjectSetProperty and ObjectDoMethod functions.
See the documentation for the OLE-automated application.
To support OLE, PeopleCode has a special data type, Object, which it uses for OLE objects. The purpose of the Object data type is to hold OLE objects during the course of a session so that you can run its methods. You cannot store Object data for any extended period of time.
Important! Object is a valid data type for variables, but not for record fields. Because OLE objects are by nature temporary, you cannot store Object data in a record field, including work record fields.
Some OLE object methods return data to the client. You can use such methods to get data from the automation server, if the method returns the data in a PeopleCode-supported data type. If the method returns data in an spreadsheet, for example, you cannot accept the data, because PeopleCode does not support spreadsheets.
When you need the services of an OLE automation server, you create an instance of its OLE object, using the CreateObject function. After you have the object, you can run its methods as often as you like. You do not need to create a new instance of the object each time.
In a typical scenario, you have a PeopleSoft component that needs to access Microsoft Excel or Word, or some other automation server, perhaps one you have created yourself. Various PeopleCode programs associated with the component must run OLE object methods.
Rather than create a new instance of the OLE object in each PeopleCode program, you should create one instance of the OLE object in a PeopleCode program that runs when the component starts (such as RowInit) and assign it to a global variable. Then, any PeopleCode program can reference the object and invoke its methods.
The WinExec and Exec built-in functions provide another way to start another application from PeopleCode. Unlike the OLE functions, however, Exec and WinExec do not enable you to control what actions the application takes after you start it. You can start the application, and if you use the synchronous option you can find out when it closes, but you cannot affect its course or receive any data in return.
WinExec is appropriate in two situations:
When you want to start an application and continue processing.
When you have a short, unvarying process that you want to run, such as copying a file.
The Exec function, unlike WinExec and the OLE functions, is not Microsoft Windows-specific. You can run it on an application server to call an executable on the application server platform, which in PeopleTools release 7 and later can be either Windows NT or UNIX.
Important! If you use the WinExec function with its synchronous option, the PeopleCode program (and the PeopleSoft application) remain paused until the called program is complete. If you start a program that waits for user input, such as Notepad, the application appears to hang until the user closes the called program. The synchronous option also imposes limits on the PeopleCode.