How to invoke or run XMLAccess against a remote Portal server?

XMLAccess can be run from any host as long as a Java Runtime Environment (JRE) is installed and the Portal server can be contacted over the network. WebSphere Portal does not have to be installed to run XMLAccess. As a matter of fact, IBM Support recommends that XMLAccess not to be run on a production server, because the JAVA process which invokes XMLAccess requires memory to run, in some cases, it would use a lot, especially with a lot of updates.

Follow the steps To run XMLAccess on a remoter server:

1. Copy the files listed below from any Portal system to a remote system with a JRE.
   • /base/wp.xml.client/bin/wp.xml.client.jar
   • /base/wp.base/shared/app/wp.base.jar
   • /lib/j2ee.jar
   • /bin/xmlaccess.sh or \bin\xmlaccess.bat
2. Edit the xmlaccess batch or shell script file and adjust the paths to the jar files as appropriate.

If your Portal is upgraded it is a good idea to copy the updated versions of the files to the remote system. Related Posts:

1. How to invoke or run XMLAccess?
2. XMLAccess
3. XMLAccess Samples

XMLAccess Samples

By default, portal provides a set for standard XML sample with WPS installation, we can find them in :

 <PortalServer-root>/doc/xml-samples.  
              (or)  
 \IBM\WebSphere\PortalServer\doc\xml-samples.  

Related Posts:

1. XMLAccess
2. How to invoke or run XMLAccess?
3. How to invoke or run XMLAccess against a remote Portal server?

How to invoke or run XMLAccess?

XMLAccess command is located in the directory /bin:

 <PortalServer-root>/bin/xmlaccess.bat.  
              (or)  
 \IBM\WebSphere\PortalServer\bin\xmlaccess.bat.  

Executing XMLAccess command without any command line parameters displays a list of available parameters:

Command line arguments described:
-in	:	This is the only required parameter to specify the input XML file name;
-user	:	This is the user id to run this command. It will be queried over the console, if omitted.
-password (or -pwd)	:	This is the password of the user running the command. It will be queried over the console, if omitted.
-useEncryptedCredentials	:	Retrieve user name and password (encrypted or unencrypted) from the properties file. Update file with encrypted password.
-noUpdateProperties	:	Do not save encrypted password back to properties file.
-out	:	Specify the output XML file. If omitted, write output to the command window or terminal.
-url	:	Specify the Portal “config” URL. It's defaulted to http://localhost/wps/config
-attempts	:	Specify how many times the command will be tried. The default is 1, no retries.
-truststore	:	When HTTPS is used in -url parameter, this specify the trust certificate store. If omitted, $JAVA_HOME/lib/security/cacerts will be assumed.
-trustpwd	:	The password to open the truststore file. The default password for JKS files in WebSphere is “WebAS” and for cacerts “changeme”.
-trusttype	:	Specify the type of the truststore file. If omitted, JKS is assumed. Another often used type is PKCS12. Most of WebSphere trust and key stores are in this format with extension .p12.
-keystore	:	Specify the keystore file when client certificate is required for client authentication on server. If omitted, $JAVA_HOME/lib/security/cacerts is assumed.
-keypwd	:	The password to open the keystore files.
-keytype	:	The keystore file type. If omitted, JKS is assumed.
-credentialexport	:	This parameter enables export and import of credential secrets from or to the credential vaults. Required properties must be configured in WP VaultService.
-encryptionPassphrase	:	The passphrase used to encrypt and decrypt the password to be imported or exported.
-echo	:	Simply return input instead of processing it. This is useful sometimes. For example, when you are not sure whether a special character can be correctly accepted in the password.

Related Posts:

1. How to invoke or run XMLAccess against a remote Portal server?
2. XMLAccess
3. XMLAccess Samples

XMLAccess

XMLAccess (XML Configuration Service) is a command-line batch-processing utility for exporting & importing various portal configuration settings in an XML format. It can export specific pages, complete or partial configuration from one portal to another.

The utility takes an XML file as input and produces an XML file, which is the results of the input and can be used to transfer:

• Portlets
• Access Control List
• Portal Web application configurations (portlet applications)
• Portal skin definitions
• Portal theme definitions
• Portal portlet configurations
• Portal site map (pages, labels, & links)
• Portal URL mappings

Related Posts:

1. How to invoke or run XMLAccess?
2. How to invoke or run XMLAccess against a remote Portal server?
3. XMLAccess Samples

Portlet Lifecycle

A portlet is managed through a well defined life cycle that defines how it is loaded, instantiated and initialized, how it handles requests from clients, and how it is taken out of service. This life cycle of a portlet is expressed through the init, render, processAction, and destroy methods of the Portlet interface.

Method signature: init(PortletConfig config) render(RenderRequest request, RenderResponse response) processAction(ActionRequest request, ActionResponse response) processEvent(EventRequest request, EventResponse response) serveResource(ResourceRequest request, ResourceResponse response) destroy()

The init(PortletConfig config) is called once, immediately after a new portlet instance is created. It can be used to perform startup tasks and is akin to a servlets init method. PortletConfig represents read-only configuration data, specified in a portlet's descriptor file, portlet.xml(more on this file later). For example, PortletConfig provides access to initialization parameters. The render(RenderRequest request, RenderResponse response) method follows processAction in the chain of lifecycle methods. Render generates the markup that will be made accessible to the portal user. RenderRequest and RenderResponse methods, also subinterfaces of PortletRequest and PortletResponse, are available during the rendering of a portlet. The way in which the render method generates output may depend on the portlet's current state. The processAction(ActionRequest request, ActionResponse response) method is called in response to a user action such as clicking a hyperlink or submitting a form. In this method, a portlet may invoke business logic components, such as JavaBeans, to accomplish its goal. The ActionRequest and ActionResponse Interfaces are subinterfaces of PortletRequest and PortalRequest. In processAction, a portlet may modify its own state as well as persistent information about a portlet. In addition to this your portlet can decide to implement EventPortlet interface which says that portlet can be target of event (Target of inter portlet communication). The EventPortlet interface defines processEvent(EventRequest request, EventResponse response) method that you should override to implement the logic that should be executed when portlet receives event. This is useful if you want to use inter portlet communication If your portlet wants to support Ajax access then you can also implement ResourceServingPortlet interface, that defines serveResource(ResourceRequest request, ResourceResponse response) method. Once you define this method you can create a resource URL from your portlet using resourceURL tag and make request to the URL to get the fragment of portlet. This helps you avoid creating a Servlet in same application as that of the portelt just to support Ajax The destroy() method is the last lifecycle method, called just before a portlet is garbage collected and provides a last chance to free up portlet resources.

Portlet Container

The Portlet Container is an extension of the servlet container. As such, a portlet container can be built on top of an existing servlet container or it may implement all the functionality of a servlet container. Regardless of how a portlet container is implemented, its runtime environment is assumed to support at least Servlet Specification 2.4.

A portlet container receives requests from the portal to execute requests on the portlets hosted by it. If you are familiar with servlet, you can easily understand portlet by correlate lifecycle methods of portlet and servlet.

The portlet lifecycle methods such as init(), render(), processAction(), processEvent(), serveResource() and destroy() are managed by Portlet Container. Portlet container is responsible for :

• Loading class of portlet.
• Creating and maintaining the portlet instance.
• Initializing the Portlet.
• Submitting user request to portlet instance.
• Destroying portlet instance when it is undeployed.
• Provides persistent storage for portlet preferences.

What is a Portal?

The idea of a Portal is to collect information from different sources and create a single point of access to information - a library of categorized and personalized content. A portal also provides other valuable functions such as security, search, and workflow.

A Portal is a web application focused on:

Creating dynamic website	:	User oriented and extreamly dynamic fragments.
Page-centric approach	:	Each page hosts presentation layer apps Portlets Apps (wrapping using bridge framework) Gadgets (based on XML and JavaScript)
Aggregation of contents	:	Aggregation is the process of integrating content from different sources within a Webpage.
Enterprise Services	:	Authentication Authorization Personalization Export/Import APIs for integrations Single sign-on

Portal Architecture Explained:

The portal Web application processes the client request. Retrieves the portlets on the user's current page. Calls the portlet container to retrieve each portlet's content. The portlet container provides the runtime environment for the portlets and calls the portlets via the Portlet API. The portlet container is called from the portal via the Portlet Invoker API. The container retrieves information about the portal using the Portlet Provider SPI (Service Provider Interface).