Novell Portal Services Integration with a Directory
Articles and Tips: tip
Research Engineer
Novell, Inc.
jfischer@novell.com
01 Aug 2003
This tip is a portion of the DeveloperNet University course "Novell Portal Services Overview and Gadget Development" found at http://developer.novell.com/education/tutorials/portal/.
Novell Portal Services (NPS) requires a directory to function properly. The directory is the underlying integration point for NPS; the directory maintains and stores most of the following:
Configuration
Access Control
Relationships
In addition to these items, user information (name, password, privileges, and preferences) is stored in the directory. NPS leverages the directory to authenticate and build a personalized "page" of data for the user.
Who you are in the directory matters! All assignments for what can be viewed in the portal are based on directory assignments:
User
Groups
Containers
Attributes
Gadgets
Gadgets are the basic building blocks of NPS. Gadgets are applications that reside within the portal framework and serve to interact with other (external) resources such as directories, databases and web pages. Gadgets communicate to any back-end system to gather data for the user. NPS provides single sign-on functionality to these back-end systems. A Gadget is represented in the LDAP directory as a gadget object. NPS offers a wide variety of gadgets with the product, including those listed in the following table:
|
Collaboration
|
System
|
Application
|
|
Exchange GroupWise Mail GroupWise Calendar POP3/IMAP NNTP |
Authentication HTML iFrame PortalStats Portal Admin- istration Registration RSS Shortcut User Admin XML Remote |
Applet Citrix News Phonebook Stock NetworkFileGadget |
Novell provides an array of Gadget Development Tools. The exteNd Directory Gadget Developer Kit provides tools to develop, test, and deploy gadgets. Check out the offerings at Novell's Developer Site at http://developer.novell.com/ndk/npssdk.htm.
The exteNd Directory Gadget Developer Kit includes documentation, extensive sample code, and the SDK libraries.
Interfacing Content to Gadgets
There are several ways of bringing content into the portal. Some of which include:
HTML --Any URL generating HTML can be linked into the portal (HTML, ASP, JSP, scripting, and so on).
XML --Any URL streaming XML data can be formatted with a style sheet at the portal and included.
Java --Any backend service that can be accessed via a Java API can be presented in the portal.
Gadget Development Basics
With a basic understanding of HTML, CSS, XML, DTD, and XSL, we are ready to dive into a study of Gadget Development Basics. This section will be followed by a more advanced Gadget Development discussion. In this part of the course, we will cover the following topics:
What Is a Gadget?
Gadget Architecture and Lifecycle
Calling Gadgets
Sending Data
Configuration
Available Settings
NPS utilizes the following technologies:
Java (including "server-side" concepts)
HTTP
XML
Knowledge in these areas is required for successful NPS gadget development. However, the following two technologies are good to know, but are optional:
HTML
JavaScript, CSS, and so on
What Is a Gadget?
A gadget is an NPS application that is used to interface with a resource. A gadget consists of Java code and XSL stylesheet(s). It sits inside the NPS framework and outputs XML. It may receive user input from a browser. It may also interface with one or more external data sources such as applications, databases, and Web sites.
How a Gadget Works
When a user first brings up a portal page in the browser, the portal creates a new instance of each gadget on that page and assigns it a unique ID. The gadget instance maintains state information about the user's session and continues to exist until the servlet engine drops the session. The portal then calls the init(String[] args) method of each gadget.
Creating a Gadget. This course is designed to give you the basics for Gadget creation on any of the platforms supported by the GDK. However, when you download the GDK, detailed documentation is provided for using the following IDEs:
Borland JBuilder 4/5/6/7
Of course the JDK command-line environment will also work.
When you create a Gadget, you can either implement a GadgetInstance or extend the BaseGadgetInstance. For example:
public class MyGadget extends
com.novell.nps.gadgetManager.BaseGadget
Instance
{
//...
}
Gadget Lifecycle. When implementing a Gadget, there are several important methods to implement. Three of these are:
public void init()
public void getData() throws GadgetInstanceException
public void processRequest()
Let's look at each of these in a little more detail,
init() This method performs instance initialization for the gadget.
getData() This method can override to return an XML page to the output stream. It is also the default method to return data. It is always called unless there is a state change, which we will talk about later in the course.
processRequest() Many gadgets need to receive and respond to user input such as forms or request parameters embedded in the URL query string. The portal distinguishes the requests that need processing by the presence of the GI_ID parameter in the URL or as a hidden field in a POSTed form. The portal then uses the specified gadget instance ID to identify the target GadgetInstance object and calls its processRequest method to allow it to process the request.
Normally, the call to processRequest is followed by a call to getData in order to get the updated display, which is presumably updated to reflect the request just processed. Sometimes, however, a gadget needs complete control over the HTTP response that is sent back to the browser. For example, the gadget might need to send a redirect or a download file. This can be achieved by setting the parameter CUSTOM_CON-TENT_TYPE=yes in the request URL. Setting this parameter causes the portal to call another version of processRequest that takes HttpServletResponse as an additional argument and requires the gadget to generate the entire response. It also prevents the portal from calling getData.
A gadget often needs to process several different kinds of requests, and needs a separate method for each request rather than funneling everything through processRequest. The portal supports this arrangement through "actions." The gadget instance needs to have a separate handler method with the signature void onXXXAction(HttpServletRequest) that throws in a GadgetInstanceException, where XXX is the name of the action.
The GadgetInstance object must implement the addActionListener method to allow it--and possibly others--to register for the actions they want to handle. Each listener must have the appropriate onXXXAction method. The GadgetInstance object must also implement the handleAction method, which is called by the portal instead of the processRequest method.
The handleAction method calls the onXXXAction method of each registered listener for action XXX. Fortunately, if you extend BaseGadgetInstance, these methods are implemented for you and all you have to do is write the onXXXAction methods and invoke addActionListener to add your gadget instance as a listener for each action.
An action is specified in the request using the NPAction=XXX parameter, where XXX is the name of the action. If the NPAction parameter is not present, the getAction method is called to allow the gadget to specify the action. If no action is specified, the portal calls the processRequest method; otherwise, it calls the handleAction method, which in turn calls the onXXXAction method for each registered listener (normally only the gadget instance itself).
The processRequest is followed by a call to getData. However, there is an exception: parameter CUSTOM_CONTENT_TYPE=yes passed in the request URL. This also allows some processing to take place before getData() is called. It is also a good place to have State changes (setState()) as a result of data in the request header.
Calling Gadgets. Each gadget is called by the GadgetManager and the XML output from the gadget is itself "wrapped" with XML from the GadgetMaseter. This "wrapping" tags on the GI_ID to the XML output from the Gadget. Here is an example:
<Gadget title= "MyGadget"id="3"...> ... XML output from gadget ... <Gadget>
Gadgets can take advantage of this wrapping to access the GI_ID in their stylesheet (main.xsl). For example, if we are one level deep in the DOM tree of the gadget XML, then the corresponding XSL document can access the GI_ID attribute by traversing two levels up the tree:
<xsl:value-of select=../../@id/>
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.