Académique Documents
Professionnel Documents
Culture Documents
PeopleSoft 8
Restricted Rights
The information contained in this document is proprietary and confidential to PeopleSoft, Inc.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying and recording, for any purpose without the express written permission
of PeopleSoft, Inc.
This document is subject to change without notice, and PeopleSoft does not warrant that the material
contained in this document is error-free. If you find any problems with this document, please report them to
PeopleSoft in writing.
This document contains or may contain statements of future direction concerning possible functionality for
PeopleSoft’s software products and technology. All functionality and software products will be available
for license and shipment from PeopleSoft only if and when generally commercially available. PeopleSoft
disclaims any express or implied commitment to deliver functionality or software unless or until actual
shipment of the functionality or software occurs. The statements of possible future direction are for
information purposes only and PeopleSoft makes no express or implied commitments or representations
concerning the timing and content of any future functionality or releases.
Overview .................................................................................................................................. 3
Writing PeopleSoft Business Logic in Java ............................................................................. 6
Invoking PeopleSoft Components from Java ......................................................................... 10
Frequently Asked Questions Concerning PeopleSoft 8 and Java........................................... 15
Overview
Java is an extremely popular programming language today, especially for internet applications.
Many PeopleSoft customers have invested heavily in building Java skills within their IT
organization and would like to leverage this investment within their PeopleSoft environment. We
have good news for these customers: with PeopleSoft 8, developers can definitely leverage their
Java skills with PeopleSoft applications. With PeopleTools 8, PeopleSoft has added support in
several key areas to enable developers to create Java-based PeopleSoft applications.
There are two primary areas where the developer can program in Java within the PeopleTools
environment:
1. Writing PeopleSoft Business Logic in Java: The vast majority of PeopleSoft business logic
is created in PeopleTools using tools such as the Component Designer and the PeopleCode
Editor. With PeopleTools 8, developers can write business logic directly in Java, or invoke
third party Java classes from PeopleCode.
2. Invoking PeopleSoft Components from Java: All PeopleSoft Components can be invoked
from Java programs through the Component Interface technology of PeopleSoft 8. This is
useful for those developers who want to create Java servlets, applets, JSP programs, or
Enterprise Java Beans that invoke PeopleSoft business logic.
Also, one of the leading Java 2 Enterprise Edition (J2EE) web application servers on the market is
packaged with PeopleSoft 8: WebLogic Server from BEA Systems. WebLogic Server
implements the J2EE platform specification that includes Servlets, Java Server Pages (JSP),
Enterprise JavaBeans (EJB), Java Messaging Services (JMS), and other platform services. When
developing WebLogic Server applications, developers create and assemble components using
these services and APIs. PeopleSoft customers can leverage these WebLogic J2EE services when
creating PeopleSoft content in Java.
A fourth area where PeopleSoft customers can leverage their Java skills is with the PeopleSoft
Portal, which is a completely URL addressable portal. For example, a customer can develop a
custom PeopleSoft application using JSP within WebLogic, and this content can be seamlessly
integrated with the PeopleSoft Portal. Any content, developed using Java that is HTTP-based and
addressable via a URL, can be easily integrated into the PeopleSoft Portal over the internet. This
allows customers to distribute their development and runtime environments ― making for better
scalability for both.
This white paper deals primarily with the first two areas of Java programming within the
PeopleTools Development Environment (listed above). But before diving into the details of
coding in Java with PeopleSoft, we’ll first explain how the PeopleSoft Internet Architecture uses
Java and the reasons for developing applications in PeopleTools (versus coding from scratch in
Java).
1. Presentation Relay Servlet—A PeopleTools Java servlet that handles all inbound and
outbound HTTP requests for PeopleSoft transactions and queries. This very thin servlet acts
as a relay between the client device and the core back-end services. It receives and serves
HTML, XML, and WML requests over HTTP and maps the data in these requests to the
Component Processor and Query Processor application services that execute under Tuxedo.
2. Integration Relay Servlet—A PeopleTools Java servlet that handles all inbound and
outbound HTTP/XML requests for the third-party system integration. This is also a very thin
servlet that acts as a relay between the external or third-party system and the core back-end
integration services. It receives and serves XML requests over HTTP and maps the data in
these requests to the integration services—Application Messaging Processor, Business
Interlinks Processor, Component Processor—that execute under Tuxedo.
3. Portal Servlet—A PeopleTools Java servlet that handles all inbound markup language and
outbound requests for the Portal. It receives and serves HTML, XML, and WML requests
over HTTP. It also manages all aspects of the PeopleSoft Portal such as search, content
management, and home page personalization.
With PeopleSoft 7 and 7.5, Java was used extensively on the client with the PeopleSoft Java
Client. The Java Client was retired with PeopleSoft 8. PeopleSoft found HTML to be a much
better client technology than Java for internet applications and that Java was best used on the
server.
The reasons for building applications in PeopleTools are the same today as they were 10 years
ago:
L Investment Protection
These reasons hold true even more so today since PeopleTools has been able to put up an
outstanding track record of technology evolution and investment protection during that 10 year
period and we’ve had thousands of customers implement enterprise systems successfully on
PeopleTools. The same cannot be said about J2EE development environments.
Investment Protection
Technology is constantly changing. PeopleTools shields you from this never ending world of
technology change. The metadata-driven PeopleTools architecture allows PeopleSoft to rapidly
evolve our technology and at the same time protects our customers' investment in their strategic
customizations. PeopleSoft is completely committed to upgrade technology, which ensures that
applications built in PeopleTools can be migrated from release to release. With PeopleTools, you
can thrive when technology changes. We constantly work with our customers to integrate new
technologies. Our ability to migrate customers from two-tier client/server, three-tier client/server,
to multi-tier Internet applications is proof of our ability to adopt new technologies and insulate
customers from radical technology change.
PeopleTools is a very declarative development platform, meaning that your developers will write a
fraction of the code with PeopleTools-based applications compared to writing applications
natively in JSP, Java, or Active Server Pages. And in the long run, this means much less code to
maintain and port to new platforms and technology.
PeopleTools allows your developers to deal with the business requirements and focus on
application design instead of focusing on the low level code. The application developers of
PeopleSoft 8 were able to deliver pure internet applications without writing a single line of
HTML, Java, or XML code. The PeopleSoft Internet Architecture leverages these leading edge
technologies when deploying and executing the business applications defined in PeopleTools.
J2EE (and it’s underlying technologies such as Servlets, EJB, and JSP) development currently has
a lot of interest and momentum in the IT world for application development. J2EE is basically a
Java coding standard, which is a very good thing compared to no standards. But the bottom line is
that is it still coding. Building applications from scratch in J2EE is a very time consuming, coding
intensive process.
Further details on developing in Java with PeopleSoft 8 can be found in the PeopleTools 8
PeopleBooks.
1. GetJavaClass
2. CreateJavaObject
3. CreateJavaArray
GetJavaClass
The GetJavaClass function finds a Java class you can manipulate in PeopleCode. This is used for
those classes that have static members, where it isn't appropriate to instantiate an object of the
class. You can only call static methods, that is, class methods, with the object created with this
function.
In Java, you access such static members of a class by using the class name:
result = java.class.name.SomeStaticMethod();
&Result = GetJavaClass("java.class.name").SomeStaticMethod();
The following is a simple PeopleCode example which uses GetJavaClass that gets a system class.
&Sys = GetJavaClass("java.lang.System");
&Sys.setProperty("java.security.policy", "C:\java\policy");
WinMessage("The security property is: " | &Sys.getProperty("java.security.policy"));
&Props = &Sys.getProperties();
&Props.put("java.security.policy", "C:\java\policy");
&Sys.setProperties(&Props);
WinMessage("The security property is: " | &Sys.getProperty("java.security.policy"));
CreateJavaObject
The CreateJavaObject function creates a Java object that can be manipulated in your
PeopleCode. You can use the CreateJavaObject function to create a Java array. If ClassName is
the name of an array class (ending with []), ConstructorParams are used to initialize the array.
If you want to initialize a Java array without knowing the number of parameters until runtime, use
the CreateJavaArray function.
The following is a simple PeopleCode program that creates a Java object from a sample program
that generates a random password.
CreateJavaArray
The CreateJavaArray function allows you to create a Java array without knowing the number or
value of the elements.
When you create an array in Java, you already know the number of elements in the array. If you
don't know the number of elements in the array, but you want to use a Java array, use the
CreateJavaArray function in PeopleCode. This will create a Java object that is a Java array, and
you can pass in the number of elements that are to be in the array.
The following PeopleCode example passes a PeopleCode array of strings (&Parms) that we to a
Java method xyz of class Abc. This example assumes that you don't know when you write the
code just how many parameters you will have.
&Parms = CreateArray();
/* Populate array how ever you want to populate it */
&Abc = GetJavaObject("com.peoplesoft.def.Abc");
/* Create the java array object. */
&JavaParms = CreateJavaArray("java.lang.String[]", &Parms.Len);
/* Populate the java array from the PeopleCode array. */
&RefArray = GetJavaClass("java.lang.reflect.Array");
For &I = 1 to &Parms.Len
&RefArray.set(&JavaParms, &I - 1, &Parms[&I]);
End-For;
/* Call the method. */
&Abc.xyz(&JavaParms);
For example, in PeopleCode you can refer to a record field using the following:
recname.fieldname
As another example, in PeopleCode you can refer to a PeopleSoft page using the following:
PAGE.pagename
For example, to get the IsChanged property would be getIsChanged. To set the value for a field
would be &MyField.setValue.
Here is an example of a Java program that uses PeopleCode objects to access the database:
nFillChars += itemLabel.length();
}
/* Do this a different way - use the SQL object to read each menu
item record. */
int nSQLChars = 0;
Record menuRec = Func.CreateRecord(new Name("RECORD", "PSMENUITEM"));
SQL menuSQL = Func.CreateSQL("%SelectAll(:1) WHERE MENUNAME = :2",
new Object[]{menuRec, menuName});
while (menuSQL.Fetch(new Object[]{menuRec})) {
String itemLabel = (String)menuRec
.GetField(new Name("FIELD", "ITEMLABEL"))
.getValue();
nSQLChars += itemLabel.length();
}
return nFillChars + 100000 * nSQLChars;
}
}
&Test = GetJavaClass("Test");
&chars = &Test.Test();
&Test = Null;
WinMessage("The character counts found are: " | &chars, 0);
This section walks through an example of how to invoke a PeopleSoft Component from Java. A
Business Expense Component is used as the example.
To expose this Component to a third party, you must first create a Component Interface definition.
This is done through the Component Interface Designer. Using drag and drop, the developer can
specify the properties and methods of the Component that he wishes to expose. Numerous
Component Interface definitions come delivered out of the box with PeopleSoft 8.
The Business Expenses Component definition is in the left frame below. The Component
Interface definition is in the right frame (the properties and methods that are exposed through this
interface).
Once the Component Interface definition is saved, you can then generate the Java classes for
invoking this interface. This is also done from the Component Interface Designer:
To create a session object, use the Session.Connect () method. The Connect method, which takes
five parameters, actually logs into a PeopleSoft session. The Connect() method connects a session
object to a PeopleSoft application server. Note that there are various options available on using an
existing connection and disconnecting and switching connections.
import PeopleSoft.ObjectAdapter.*;
import PeopleSoft.Generated.PeopleSoft.*;
import PeopleSoft.Generated.CompIntfc.*;
private ISession oSession;
private CAdapter oAdapter;
busExpense.setEmplid( getKey );
boolean result = busExpense.Get();
The following code creates a connection to the application server, gets the Component Interface,
and fetches the first item in a collection.
long j = busExpenseSecondScrollCollection.getCount();
Object [][] data = new Object[ ((int)j + 1) ][ 7 ];
for( int i = 1; i < j + 1 ; i++ )
{
busExpenseSecondScrollItem = busExpenseSecondScrollCollection.Item( i );
data[(i - 1)][0] = busExpenseSecondScrollItem.getBusinessPurpose();
data[(i - 1)][1] = busExpenseSecondScrollItem.getChargeDt();
data[(i - 1)][2] = busExpenseSecondScrollItem.getCurrencyCd();
data[(i - 1)][3] = busExpenseSecondScrollItem.getDeptid();
data[(i - 1)][4] = busExpenseSecondScrollItem.getExpenseAmt();
data[(i - 1)][5] = busExpenseSecondScrollItem.GetPropertyByName("ExpenseCd");
data[(i - 1)][6] = busExpenseSecondScrollItem.GetPropertyByName("CurrencyCd");
}return( data );
busExpenseFirstScrollItem.setEmplid( emplid );
busExpenseFirstScrollItem.setExpensePeriodDt( expensePeriodDt );
return( busExpense.Save() );
Just as before, data is edited using Item objects and using the setNameOfPropery() method of
those Items. Also, note that we needed to call the Save() method on the Component Interface to
commit the changes.
busExpenseSecondScrollCollection.DeleteItem( secondScrollIndex );
oSession.Disconnect();
The PeopleTools Component Interface Designer does not generate EJB’s when generating the
Java bindings. This was a conscious decision that was made for several reasons:
L One is that we wanted to make sure that we didn't limit the integration that we provided only
to EJB environments. There are enough developers out there writing Java servlets and other
Java applications that don't run in an EJB environment that we didn't want to lock those folks
out just to get the marketing checkbox for EJB support. It made more sense to have good
Java support that would allow all environments, EJB and non-EJB, to be able to call
PeopleSoft Components.
L The other reason is that the EJB specification is still fairly immature, especially when you
consider the various implementations of the spec. The differences between the deployment
descriptors for WebLogic, WebSphere, iPlanet, etc. are pretty large. Also, not all of the
current EJB implementations are even up to the current EJB 1.1. spec and the EJB 2.0 spec is
out for public comment right now.
As the spec matures and existing Java environments move to EJB’s, then PeopleSoft will most
likely add native EJB support. Until then, we'll be open to all Java environments.
Q: How is WebLogic’s EJB support used within the PeopleSoft Internet Architecture: server
provider, container provider, EJB provider, application developer, and deployment
developer?
PeopleSoft does not currently leverage WebLogic's EJB functionality. PIA uses WebLogic for
Java servlet and web server support.
Q: What are PeopleSoft recommendations on the EJB design approach (stateless server,
sessions-oriented, and persistent) and EJB type (stateless session, stateful session, and
entity) with WebLogic Server and the PeopleSoft Internet Architecture?
PeopleSoft has no formal recommendations at this time concerning this issue. The work that has
been done in 8.12 will allow someone to develop a stateful session bean that is implemented in
terms of a Component Interface (or set of CIs) as long as the CI is used (retrieved, created,
accessed, released) within the scope of an EJB method call.
In the PeopleTools 8.4 release of the Java binding for Component Interfaces, PeopleSoft will be
providing support for Java serialization of all CI related classes (i.e. Session, MessageCollection,
CI, CIRow, etc). This will allow developers to create stateful session beans that can support being
activated and passivated by the EJB container. This requires that non-transient data members of
the EJB be serializable - something that was not possible in 8.12 because the CI API did not
provide support for Java serialization and not enough of the CI internals was exposed (by design)
to API callers to bolt on serialization support in a reasonable manner.
Q: If calls are made to multiple Java classes from PeopleCode, are all of these done
through one JVM instance?
Yes. Each process is limited (by current JVM implementations) to one JVM instance. However,
multiple PeopleSoft Application Servers each have their own JVM instance, since they are in
separate processes.