PeopleSoft Techincal Support: PS Technical Stuff

Showing posts with label PS Technical Stuff. Show all posts

Troubleshooting Future Dated Security in Peoplesoft HRMS 8.9, 9 and 9.1 [Video]

Future dated security, or granting access to users based on rows in the future involves 2 important setups:

1. Security Access type:
To turn on future dated security, the corresponding enabled security acceess types in your system must have the "Include Future dates check box" turned on.
2. Security Installation settings.
The actions that trigger future dated security SECTION IN THE INSTALLATION SETTINGS must have all the actions for which you want ENABLE future security.

If you have both of these set ups in place then creating a future dated row in Job for the Employee, in addition to the current row, SJT_PERSON will be updated with information about this Future row.

For example, Employee KU0007 who is currently in the department of "Admin" is to be transferred to a new department of "Finance" in future. This future dated entry in job will automatically create a new entry in SJT_PERSON with the Future flag set as Y for the future row.
In effect any user having access to department of Admin or department of Finance will be able to access the Employee's information.

For troubleshooting issues around future dated security:
1. The first thing you need to check is if include future dates is enabled for the enabled access types in your system.
2. Second step would be to check if the action used in the future dated row is included in the Security installation settings.
**Please note that if you make any changes to these 2 set ups, you need to run Refresh Trans SJT Tables Process and Refresh SJT_CLASS_ALL process..

Additional tips:

Most of the issues related to Future dated security get resolved by running the Refresh Trans SJT process.
If you are having issues with the access of rows that have recently become current rows, then you need to run Refresh Trans SJT Tables Process. This process will delete the history rows and update the future flag of the row that became current now to N.
Please note that Query security records are designed to fetch only current rows. These will not bring up future rows even if you have future security enabled.
Also note that Future security is currently not designed to work with other Security Sets like RSOPN.
Irrespective of whether you have enabled Future security in your system, it is important that you schedule Nightly refresh process to run a short time after midnight to keep your security tables in synch. This process, will update all the future rows that are becoming current on the given date. If this is missed, then running the Trans SJT process will get the table in synch.

Programming Component Interfaces in PeopleCode

• Understand PeopleCode behavior and limitations.
• Generate a PeopleCode runtime code template.
• Use and understand the PeopeSoft runtime code template.

Understanding PeopleCode Behavior and Limitations
This section discusses some behavior and limitations of PeopleCode for component interfaces.
Be aware of this when you write PeopleCode for a component interface.
PeopleCode Event and Function Behavior
PeopleCode events and functions that relate exclusively to GUI and online processing cannot
be used by component interfaces. These include:

• Search dialog processing.
When you run a component interface, the SearchInit, SearchSave, and RowSelect events
don’t fire. This means that any PeopleCode associated with these events will not run. The
first event to run is RowInit.

• Menu PeopleCode and pop-up menus.
The ItemSelected and PrePopup PeopleCode events are not supported. In addition, the
CheckMenuItem, DisableMenuItem, EnableMenuItem, HideMenuItem, and
UncheckMenuItem functions aren’t available.

• Transfers between components, including modal transfers.
The TransferPage, DoModalPageGroup, and IsModalPageGroup functions cannot be
used.

• Dynamic tree controls.

Functions related to this control, such as GetSelectedTreeNode, GetTreeNodeParent,
GetTreeRecordName, RefreshTree and TreeDetailInNode cannot be used.
• ActiveX controls.
The PSControlInit and PSLostFocus events are not supported, and the GetControl
function cannot be used.
• DoSave() and DoSaveNow().
The DoSave() and DoSaveNow() pcode functions are not supported. You should use the
component interface Save() method and wrap the DoSave() and DoSaveNow() functions
so they don’t execute when called from a component interface.
• Functions that are ignored in a component interface call.
Some PeopleCode functions are ignored if they are called through a component interface.
These functions are:
􀀃 WinMessage
􀀃 CheckMenuItem
􀀃DisableMenuItem
􀀃 EnableMenuItem
􀀃 HideMenuItem
􀀃UncheckMenuItem
􀀃 SetCursorPos
􀀃 TransferPanel
􀀃 TransferPage
􀀃 DoModalComponent
􀀃 IsModalComponent
􀀃DoModalPanelGroup
􀀃 IsModalPanelGroup
􀀃GetSelectedTreeNode
􀀃 GetTreeNodeParent
􀀃 RefreshTree
􀀃 TreeDetailInNode
􀀃 GetControl
􀀃 DoSave
􀂃 DoSaveNow

Using the Component Interface Software Development Kit (SDK)
• Set SDK prerequisites.
• Use the SDK_BUS_EXPENSES test page.
• Test the SDK_BUS_EXP component interface.
• Using the component interface SDK Java sample.

The PeopleSoft Integration SDK is installed with the PeopleTools installation. It provides
resources to assist you in developing and testing component interface-based integration
between PeopleSoft and third-party applications. The SDK contains sample definitions with
data and source code. For easy identification, all of the definition names start with SDK_.
The SDK is installed in the PeopleSoft home directory (PS_HOME) under sdk.

Note. The SDK definitions and associated data are for development purposes only and not to
be used in a production environment.

Programming Component Interfaces in COM
• Build the component interface APIs.
• Set up the COM environment.
• Generate a Visual Basic runtime code template.
• Use and understand the generated Visual Basic code.

Building the Component Interface APIs for COM

If you plan to access your component interface from a COM external application, you must
create a component interface API. The APIs are in the form of .reg file and typelib files.
To build the component interface bindings:
1. Open any component interface definition in PeopleSoft Application Designer.
Use any component interface definition, because you can build APIs for all of them,
regardless of which one is open.
2. Select Build, PeopleSoft APIs.
The Build PeopleSoft API Bindings dialog box appears.
3. Select the Build check box in the COM Type Library group box.
a. For the target directory, enter the directory in which you want the COM type library to
be created: typically \bin\client\winX86.
b. Enter the COM Server server DLL Location location to specify where the PeopleSoft
API Adapter (psapiadapter.dll) is located: \bin\client\winX86.
4. (Optional) Select the AutoRegister check box to execute the registry file immediately
upon building the API.

This causes your client machine registry to be immediately updated without having to
register it manually.
5. (Optional) Select the Clean-up Registry check box to clean up the registry if you’ve
applied previous versions of Peoplesoft_Peoplesoft.reg.
This is needed so that the older registry settings don’t remain and conflict with settings
made by the latest version.
6. Click OK to build the bindings that you selected.
The files that constitute the bindings are built in the location that you specified. If the
operation was successful, a Done message appears in the PeopleSoft Application Designer
Build window.

To configure a compiler for the C++ project:
Note. These instructions assume you’re using Microsoft Visual C++. If you use a
different compiler, apply the equivalent settings for that product.
1. In MicroSoft Visual C++, create a new project.
2. Select Tools, Options.
3. Select the Directories tab.
4. In the Options dialog box, click the New button.
5. Enter the path to the SDK include files.
For example:
C:\PT840\SDK\PSCOMPINTFC\SRC\C++\SAMPLES\INC
6. Click OK to save the options.
7. Open the Project Settings dialog box.
8. Select the C/C++ tab.

9. Select the General category.
10. Add PS_WIN32 to the preprocessor definitions.
11. Select the Link tab.
12. Select the Input category.
13. Specify the full path to psapiadapter.lib for the Object/library modules.
This is typically \src\lib\psapiadapter.lib. Make sure that this is the only
entry for psapiadapter.lib.
14. Click OK to save the settings.
Generating

Setting Up a Client Machine to Access the Component Interface API Using C++

To set up your client machine to access the component interface API using C++:
1. Install the PeopleSoft File Server.
See the PeopleSoft 8.4 Installation Guide, Chapter 3, Using the PeopleSoft Installer.
2. Install Sun’s JDK 1.3.1 to enable the Sun JVM, if it is not already installed.
3. Set the environment variable PATH to include:
a. The directory containing jvm.dll (typically c:\bea\jdk131\jre\bin\classic)
b. The PeopleSoft PeopleTools client installation directory:
\bin\client\winx86.
4. Set the environment variable CLASSPATH to include the psjoa.jar file (typically
\class\psjoa.jar)
5. Set the environment variable PS_HOME to point to the installed PeopeSoft PeopleTools
directory (for example, c:\pt840).

Building the Component Interface APIs for C++

If you plan to access your component interface from a Java external application, you must
create a component interface API. The APIs are in the form of C header files (*.h), which
needs to be included in the calling program.

To build the component interface bindings:

1. Open any component interface definition in PeopleSoft Application Designer.
Use any component interface definition, because you can build APIs for all of them,
regardless of which one is open.
2. Select Build, PeopleSoft APIs.
The Build PeopleSoft API Bindings dialog box appears.
3. Select the Build check box in the C Header Files group box.
For the target directory, enter the directory in which you want the C++ header file to be
created: typically \bin\client\winX86
4. Click OK to build the bindings that you selected.
The peoplesoft_peoplesoft._i.h file that constitutes the bindings is built in the location that
you specified. If the operation was successful, a Done message appears in the PeopleSoft
Application Designer Build window.

Setting Up the C++ Environment

When deploying component interfaces on a local client machine with C++ bindings, you must
have:
• The third party C++ application.
• The PeopleSoft application server and database.
• The Java Virtual Machine (JVM) supplied with Sun Microsystem’s JDK 1.3.1.
• Your compiler, configured for the C++ project.
Third Party Application
For applications written in C or C++, note the following:
• The function names generated by the Build APIs process can be quite long. You may
want to consider creating classes within your C++ code to mask this length throughout
your program.
• When you create your installation for your C or C++ program, make sure you include
the setup of the path to the psapiadapter.dll.

Generating a Java Runtime Code Template Peopleosoft Component Interface

To access a component interface through PeopleSoft APIs using Java, PeopleSoft Application
Designer generates a template in the form of boilerplate Java code that you can adapt to your
purposes. This section describes how to generate the template code.

To generate a Java template for a component interface:
1. Open a component interface definition in Application Designer.
2. Right-click anywhere in the definition view to display the pop-up menu.
3. Select Generate Java Template.
When the template is successfully generated, a message appears stating the name and
location of the template file.

Note. The template file is generated in the directory specified by the TEMP or TMP
system environment variable on your client machine.
4. Edit the generated file and modify the source code to suit your needs.
5. Compile the source code to generate a .class file.
In the case of the example used in this manual, you could use this command.
javac –classpath c:\temp;c:\pt8\class;c:\PT8\class\psjoa.jar SDK_BUS_EXP.java

Setting Up the Java Environment for Component Interface

When deploying component interfaces on a local client machine or web server with Java
bindings, you must have:
• The third party Java application.
• The PeopleSoft application server and database.
• The Java Virtual Machine (JVM) supplied with Sun Microsystem’s JDK 1.3.1.

To set up your client machine to access the component interface API using Java:

1. Install Sun Microsystem’s JDK 1.3.1 to enable the JVM, if it is not already installed.
2. Set the environment variable PATH to include the directory containing jvm.dll (typically
c:\bea\jdk131\jre\bin\classic).
3. Set the environment variable CLASSPATH to include:
a. The file psjoa.jar (typically \class\psjoa.jar).
b. The target directory selected during the Build API process (\class)

Programming Component Interfaces in Java

If you plan to access your component interface from a Java external application, you must
create a component interface API. The APIs are in the form of *.java source code files, which
should be compiled into Java classes.

To build the component interface bindings:

1. Open any component interface definition in PeopleSoft Application Designer.
Use any component interface definition, because you can build APIs for all of them,
regardless of which one is open.

2. Select Build, PeopleSoft APIs.
The Build PeopleSoft API Bindings dialog box appears.

3. Select the Build check box in the Java Classes group box.
For the target directory, enter the directory in which you want the Java class source files to
be created. This directory is typically \class.

4. Click OK to build the bindings that you selected.

The files that constitute the bindings are built in the location that you specified. If the
operation was successful, a Done message appears in the PeopleSoft Application Designer
Build window.

5. Compile the APIs that you’ve just generated.
You could use these commands.
cd %PS_HOME%\class\PeopleSoft\Generated\CompIntfc
javac –classpath %PS_HOME%\class\psjoa.jar *.java
cd c:\pt8\class\PeopleSoft\Generated\PeopleSoft
javac –classpath %PS_HOME%\class\psjoa.jar *.java

Understanding Runtime Considerations for Component Interface
Programs
In many ways, accessing a component interface is functionally equivalent to working with an
online component. However, there are some important differences between component
interfaces and components. This section describes how those differences affect interactive
operation, functionality designed for graphical interfaces, client vs. server operation, and
several miscellaneous situations. These considerations, unless otherwise noted, apply to all
the programming languages listed in this manual.

This section discusses:
• General considerations
• Scope conflicts
• Interactive mode

General Considerations
This section discusses general considerations for component interface programs.

Saving a New Row
When you use the Create method, you must assign a value to at least one non-CreateKey
property to ensure that the Save method properly validates the row data. If you don’t assign a
value to at least one property, the Save method could erroneously save an invalid record
without generating any warnings.

WinMessage Unavailable
You can’t use WinMessage in a component that will be used to build a component interface.
Use MsgGet() instead.

Email From a Component Interface
To use a component interface to send email, use TriggerBusinessEvent PeopleCode event, not
`SendMail.

Testing the Component Interface
To test the component interface, you search for the component interface to test, then you test
it.

To search for a component interface to test:
1. Open the component interface in PeopleSoft Application Designer.

2. Select Tools, Test Component Interface from the PeopleSoft Application Designer menu.
The Component Interface Tester search dialog box appears. This dialog box displays the
keys (in the left-hand columns) for getting, creating, or finding an instance of the
component interface. The right-hand columns provide a place for you to enter sample key
values for testing.

3. Enter key values.
a. Double-click the column to the right of any displayed keys.
b. Enter the value in the right-hand column.
The data that is used for the test corresponds to the key values that you enter here. In the
preceding example, we’ve entered an employee ID of 6602.

4. Specify whether to run in Interactive mode.
When in Interactive Mode, any action request occurs immediately. Each property being
set causes an immediate trip to the application server (or database server in two-tier
mode). This differs from non-interactive mode, in which actions are often held and later
sent in batches. For example, in non-interactive mode, if you set a property, the property
is not validated until you perform the save. However, in interactive mode the property is
validated immediately. This means that edit processing (and other processing, such as
FieldChange PeopleCode) occurs for each set property.
Whether you select this option depends on how you expect a particular component
interface to be used and what you are currently testing. In a real production system, this
parameter can significantly affect performance, but it makes little difference in the test
component. In non-interactive mode, errors and properties are not updated until a method
is run. By default, Interactive Mode is selected in the component interface tester.

5. Specify whether to get or edit history items.
Selecting Get History Items retrieves history data. Selecting Edit History Items enables
editing and saving of history data. These options apply to effective-dated fields only and
are equivalent to running in either Update/Display or Correction mode online. These
options are initially cleared.

6. Getting existing records for the test.
Clicking Get Existing is equivalent to opening a record in Update/Display or Correction
mode online. It retrieves one row from the database. After you click the Get Existing
button, the Component Interface Tester dialog box appears.

7. Getting existing records using partial keys.
If you want to retrieve a partial key, click the Find button. The Find Results dialog box
appears. You then can choose the specific instance by selecting and clicking the Get
Selected button. If you do not enter a partial key before clicking Find, all key values in
the database are returned (subject to the maximum count of 300, just as when online).
This is the same as calling the Find method through the Component Interface API,
followed by selecting a value from the Find results, setting the Get key, and calling the
Get method. After you click the Get Selected button, the Component Interface Tester
dialog box appears.

8. Creating new records for the test.
Clicking Create New is equivalent to creating a new row in Add mode online. If your
component does not support the Create method, this button is disabled. After you click
the Create New button, the Component Interface Tester dialog box appears.

Testing the Component Interface (after searching)

To test a component interface (after the search is performed):

1. Test component interface properties.

From the Component Interface Tester dialog box, change a value of a property, doubleclick

a value and enter a new value. Some basic validation is done when you leave the

field, which is equivalent to exiting a field using the TAB key in the online case. This

validation includes system edit, FieldChange PeopleCode events, and FieldEdit

PeopleCode events. Further validation may be done when the Save method is called

(SaveEdit, SavePreChange, Workflow, and SavePostChange). If errors or warnings are

encountered, they are displayed in the Error Message Log area at the bottom of the

window. The Error Message Log displays the same text that would appear in the

PSMessages collection of the Session object if you accessed the component through the

Component Interface API.

2. Test component interface methods by right-clicking the component interface name.

A pop-up menu appears showing the Save and Cancel standard methods and any userdefined

methods that exist for the component interface. The Find, Create, and Get

standard methods are not valid for an instantiated component, and therefore are not

shown.

If a component interface method requires one or more parameters, a dialog box in which

you can enter the parameters appears. After the method gets executed, the same dialog

box appears again, displaying changes to the parameters that were caused by the method.

The return value of the function appears in the title of the dialog box. If a component interface requires no parameters, you do not see the initial dialog but, you do see the

return value dialog box following the function call.

Note. Because running a component interface method can result in a change to the

component interface structure, PeopleSoft Application Designer always redraws the

component interface tree in its collapsed form following a method call.

3. Test collection methods by right-clicking the collection name.

A pop-up menu appears, showing the standard collection methods. Select the collection

method that you want to test for this component interface. After you select a collection

method to test, the Enter parameters dialog box prompts you to enter an item number for

the collection method that you are testing. The value that you enter for index [Number]

is used to retrieve, insert, or delete an item, according to the following rules.

After you enter an index number, the result appears in the dialog box. If there is a return

value, it is displayed in the title bar. Otherwise the message No value is displayed. Click

OK or Cancel to dismiss the dialog box.

Testing the Component Interface

After setting the security for a component interface, you can test the contents and behavior
using the component interface tester. You should test the component interface before using it
in your external system. This proactive tool helps you discover problems with the underlying
component or the component interface itself, including user defined methods. When you are
testing a component interface, real data from the database is used. Therefore, if you save the
information that you change by calling the Save method, the information is changed in the
database.
With the component interface tester, you can:

• Test the component interface in interactive mode.
• Retrieve history items.
• Test the standard, custom, and collection methods.
This section discusses how to:
• Test the component interface.
• Determine ItemByKeys parameters.

Setting Component Interface Security - Peoplesoft

After creating a component interface, you must set security for it. Each individual method
also needs to be provided security. Security for the component interface is provided through
the PeopleSoft Internet Architecture pages.

To set up component interface security:
1. Through the browser login to PIA. Select PeopleTools, Security, Permissions & Roles,
Permission Lists.
2. Select the permission list for which you want to set security.
The Permission List component appears.
3. Access the Component Interfaces page.
4. Select the component interface for which you want to set security.
To add another component interface to the list, click the Add button.
5. Click Edit.
The Component Interface Permissions page appears, showing all of the methods (both
standard and user-defined) in the component interface and their method access.
6. Set the access permission for each method.
Select Full Access or No Access. You must grant full access to at least one method to
make the component interface available for testing and other online use.
7. Click OK when you’re done.
8. Press the Save buttom to save these settings.

Validating the Component Interface

Validation ensures that a component interface definition has not deviated from its source
component. This can happen whenever a component deletes or adds a record or field. It can
also happen if the keys on the component are added or removed. Properties and keys that no
longer synchronize with their associated components are marked with an X icon.
Note. The validation process only determines whether the underlying component of a
component interface has changed. It does not validate the PeopleCode that is associated with
a component interface. To validate the PeopleCode, open the component and select Tools,
Validate from the PeopleSoft Application Designer menu.

To correct an invalid component interface, you might have to delete properties for which there
are no longer appropriate fields or records. If the structure of the source component has
changed, you might have to delete old properties and re-add the new properties in their
appropriate locations.

To validate a component interface:
1. Open the component interface in PeopleSoft Application Designer.
Validation occurs automatically whenever you open a component interface in PeopleSoft
Application Designer.
2. Select Tools, Validate for Consistency from the PeopleSoft Application Designer menu to
validate an open component interface.

As you change components or other related definitions, you should validate a component
interface that is already open in PeopleSoft Application Designer.

Creating User-Defined Methods - Component Interface - Peoplesoft

To create a user-defined method:
1. Right-click anywhere in the component interface view.
2. Select View PeopleCode from the pop-up menu.
The PeopleCode editor appears. If using a new component interface no PeopleCode will
appear in the editor because no user-defined methods have been created.
3. Write the required PeopleCode functions.
PeopleCode functions that you write are stored in a single PeopleCode program that is

attached to the component interface and associated with the Methods event.
Note. New user-defined methods do not appear in the list of methods until you save the
component interface. Double-click the icon of any existing user-defined method to return
to this PeopleCode program.

4. Set permissions for the methods that you created.
You must set permissions for every user-defined method. If you set permission to Full
Access, at runtime that function is exposed to external systems as a method on the
component interface object.

Enabling and Disabling Standard Methods Component Interface

You can control whether standard methods are accessible at runtime.

To enable or disable standard methods:

1. Select File, Definition Properties from the PeopleSoft Application Designer menu.

The Definition Properties dialog box appears.

2. Select the Standard Methods tab.

You can enable or disable any of the standard methods selecting the corresponding check

box. Doing so determines whether the method is available at runtime when the component interface is accessed. The Create option is available only if the component interface has Create keys.

Working With Collections

A collection is a property that points to a scroll, rather than a field, in the underlying
component for a component interface. A collection groups multiple fields in a scroll. All the
fields in the scroll are mapped to a property. These properties are part of the collection.
You create collections the same way you create properties—drag the scroll from the
component view into the component interface view. Consider these points when creating
collections:

• When dragging a scroll into the component interface view, all child scrolls come with
it.

This is the same behavior that you would expect when creating a property. Child
properties are always added automatically when you drag a field from the component
view to the component interface view. After the property or collection has been created,
you can delete individual child properties or collections manually, if necessary.

• When dragging a scroll into the component interface view, all record fields contained
in that scroll come with it—not just those from the record that defines the scroll.
The fields from all records at that scroll level are exposed as part of the same collection.

• Keys that appear in parent and child scrolls are not added to child collections.
For the component interface to function as expected, the keys must remain synchronized
at all levels of the component. Having keys at lower levels makes it possible to
compromise this synchronization. Therefore, lower-level keys are not introduced into the
component interface and are not exposed to the user because those keys have already been
set at the parent level.

• When dragging a child scroll into the component interface view, parent collections are
created automatically.

For example, if you drag just the level-two scroll from the component view into the
component interface view, a level-zero collection and a level-one collection are created
automatically in the component interface. This hierarchy of collections is necessary so
that it’s possible to navigate to the child collection at runtime.

Creating User-Defined Properties for Component Interfaces

User-defined properties come from the component with which the component interface is
associated and must be added manually. They are the specific record fields that you expose to
an external system with the component interface. You create user-defined properties in
addition to the standard properties to enable additional manipulation of the component. When
you create a new component interface, if you accept default properties, user-defined properties
are created automatically.

User-defined properties are the points where the component and the underlying database are
exposed to the external system. This is the means that component interfaces use to add or
change fields and data in the database.

To create a property:

1. Drag a record, field, or scroll from the component view to the component interface view.
It does not matter where you insert the definition in the component interface view. The
system automatically converts the field or record into a component interface property and
places it in the appropriate place in the list of properties. Also, when you drag a definition
from the component view into the component interface view, all “child” definitions are
brought into the component interface automatically. Once these child properties are added
to the component interface, you can remove each property individually, if desired.
Dragging a key from the search records, which precede the level-zero record in the page
view, adds a key to all appropriate key collections (Get, Create, and Find) in the
component interface. Because appropriate keys are added automatically when a
component interface is first created, you typically must add keys only if the new keys are
added to the underlying component after the creation of the component interface.

Setting Component Interface Security : Peoplesoft

After creating a component interface, you must set security for it. Each individual method
also needs to be provided security. Security for the component interface is provided through
the PeopleSoft Internet Architecture pages.

To set up component interface security:
1. Through the browser login to PIA. Select PeopleTools, Security, Permissions & Roles,
Permission Lists.
2. Select the permission list for which you want to set security.
The Permission List component appears.
3. Access the Component Interfaces page.
4. Select the component interface for which you want to set security.
To add another component interface to the list, click the Add button.
5. Click Edit.
The Component Interface Permissions page appears, showing all of the methods (both
standard and user-defined) in the component interface and their method access.
6. Set the access permission for each method.
Select Full Access or No Access. You must grant full access to at least one method to
make the component interface available for testing and other online use.
7. Click OK when you’re done.
8. Press the Save buttom to save these settings.

PeopleSoft Techincal Support

Visitors

Popular Posts

Blog Archive

Label Cloud

Newsletter

Subscribe Our Newsletter

About Us

Search This Blog