IBM WebSphere Portal Script beans

The portal scripting component adds so-called Script beans to the wsadmin tool. These are objects with methods that work on the portal data. Portal objects are not represented by Jython or Jacl objects. There is no Jython or Jacl object that represents a particular page or an individual portlet. Rather, there is a fixed number of Script beans that provide access to specific areas of the portal data.

The available beans are:

• Portal
• Content
• Layout
• Portlet
• Look
• Access
• PacList
• Application
• ArchivedApplication
• ApplicationCategory
• TemplateCategory
• Publish

Working with IBM WebSphere Portal Scripting

Change into the directory where your Portal Scripting Interface is installed: cd /opt/WebSphere/PortalServer/bin

wpscript.bat -port port_number -user user_id -password password

Description of the basic parameters used with the wpscript.bat
Parameter	Description
-lang	Specifies the language of the script file, command, or an interactive shell. Specify one of the following values for the -lang parameter: jacl jython This parameter is optional and has no default value. This option overrides language determinations that are based on script file names, profile script file names, or the com.ibm.ws.scripting.defaultLang property. Important: If you do not specify the script language in the command line or as a parameter, and the wsadmin tool cannot determine the script language, an error occurs. If you do not specify the script language as the value for -lang, the wsadmin tool determines the script language as follows: If you specify the -f script_file_name argument, the wsadmin tool determines the language from the name of the target script file. If you specify the -profile profile_script_name argument, the wsadmin tool determines the language from the name of the profile script.
-conntype	The type of connection that should be established between scripting. Valid connection types include: SOAP RMI NONE The default value is SOAP. This parameter is optional. Use the -conntype NONE option to run in local mode. The result is that the scripting client is not connected to a running server. If the connection type NONE is selected, the scripting beans are inactive and cannot be used for administration, with the exception of the help command.
-port	The connection port number. This parameter is optional. The port number depends on values chosen during installation. You can verify the value that is set for the WasSoapPort property in the wkplc.properties file found in the appropriate directory given here: AIXHP-UXLinuxSolaris: wp_profile_root/ConfigEngine IBM i: wp_profile_root/ConfigEngine Windows: wp_profile_root\ConfigEngine If you are running wpscript on a server that is part of a cell managed by a deployment manager, the port_number can vary depending on what ports are in use on the system when the deployment manager is created. To verify the value, check the setting for SOAP_CONNECTOR_ADDRESS in serverindex.xml located in the appropriate directory given here: AIXHP-UXLinuxSolaris: dmgr_profile_root/config/cells/cell_name/nodes/node_name IBM i: dmgr_profile_root/config/cells/cell_name/nodes/node_name Windows: dmgr_profile_root\config\cells\cell_name\nodes\node_name
-user	The user ID under which you establish the connection. This parameter can be mandatory, depending on your security configuration.
-password	The password for the user ID under which you establish the connection.

Run the following command to login

Portal.login("user_ID", "password")

IBM WebSphere Portal Scripting

Portal scripting interface that enhances the possibilities for automated solution deployment and administration of the portal. The Portal Scripting Interface allows you to create scripts that portal administrators can use to perform administrative tasks from a command line.

The Portal Scripting Interface allows portal solution development teams to write scripts that are later executed by operation teams for solution deployment. These scripts have the same functionality as the portal administration user interface. This allows you to implement automated configuration management for various kinds of configuration changes.

Scripts can help you split the administrative workload between solution development and solution operation teams. Even if the solution development teams cannot work interactively with the productions system, they can apply the same administrative actions through the use of scripts. At the same time, the use of scripts enhances availability and quality of the solution as developers can write and test the scripts without interfering with the production system. Scripts provide repeatability and avoid user errors that are likely in manual administration procedures.

Advantage of Portal scripting over XML access

• Different development teams can work on related portal updates without interfering with each other's work.
• Different administrative teams can perform the tasks of developing a solution, and deploying and operating that solution for production. These teams can be within the same organization (for example in the same enterprise), or in independent companies, such as independent solution centers for the operation. In a typical scenario, the solution development team may have in-depth knowledge about the software solution internals, the operation is focused on the external characteristics of the solution. The operation solution team can receive the solution from the development team as a black box that can be operated without much knowledge of the solution internals. This allows enterprises to use automated solution deployment and distributed staging processes.

In this regard the portal scripting interface goes beyond the XML configuration interface that has been provided by WebSphere Portal for several releases now. The XML configuration interface does not allow for easy separation of distributed portal administration.

You can use the portal scripting interface for staging and integration of new releases A new release can be developed and tested on a test system and can then be integrated into the production system while the system is running.

Interactive portal administrative tasks do not require a Web browser.

Scheduler task through XML Access

In xml, task tag is used for Scheduling the cleanup of portal resources and the administration of federated tags. Cleanup refers to the deletion of portal pages and all page-dependent resources that are marked for deletion. Specify one or more tasks to be run immediately or at specified intervals. The scheduling interval parameters dayOfMonth and dayOfWeek are optional and are mutually exclusive. Each scheduling interval parameter requires a value for the parameter startTime. If you want to run a task daily, use only the parameter startTime.

Name of task	Description
com.ibm.portal.datastore.task.ResourceCleanup	This task cleans up portal resources. If you specify this task without a scheduling interval parameter, portal resource cleanup is done immediately when you run the XML script.
com.ibm.portal.cp.SynchronizationTask	This task synchronizes collaborative data, including tag categorization information that is provided by Web Content Manager tagging. If you specify this task without a scheduling interval parameter, the portal does a resource cleanup immediately when you run the XML script.
com.ibm.portal.services.RefreshIWidgetDefinitionsTask	This task refreshes iWidget definitions that are stored in WebSphere® Portal. Refreshing iWidget definitions refers to reloading the iWidget definition XML files and updating the corresponding iWidget Wrapper portlet clones. Tip: To call this task directly, run the following portal configuration task: refresh-iwidget-definitions.
com.ibm.portal.cmis.TransientSlotCleanupTask	This task removes temporary credential vault slots that were created by the federated documents wizard and were not used for at least 3 hours.
com.ibm.wps.cp.tagging.federation.taskhandler.FederationTaskHandler	This task retrieves tags and related data from federated tagging providers. IBM® Connections is an example of a federated tagging provider.
com.ibm.wps.cp.tagging.federation.taskhandler.FederationDeleteTaskHandler	This task removes federated tags and related data from WebSphere Portal. It is recommended to start the task when federation of tasks is no longer required.

dayOfMonth

If you want the task to run monthly, specify a number from 1 to 31. If the number you specify is higher than the last day of the month, the cleanup is done on the last day of the month. For example, specifying a value of 31 sets the task to run on January 31, the last day of February, March 31, April 30, and so on.

dayOfWeek

If you want the task to run weekly, specify a number from 1 to 7, where 1 is equivalent to Monday and 7 is equivalent to Sunday.

startTime

If you specified a scheduling interval of dayOfMonth or dayOfWeek, you must specify the time of day at which you want the task to start. Use the format HH:MM to specify a value from 0:00 to 23:59. You do not need to include leading zeros, for example 4:45. To run the task daily, use this parameter only; do not use the parameters dayOfMonth or dayOfWeek.

<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

            xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">

            <portal action="locate">

<!-- Runs once, starts immediately -->

                        <task action="create" name="com.ibm.portal.datastore.task.ResourceCleanup"/>

<!-- Runs daily at 12:30

                        <task action="create" name="com.ibm.portal.datastore.task.ResourceCleanup">

                                    <startTime>12:30</startTime>

                        </task>

-->

<!-- Runs monthly, at the latest time possible

                        <task action="create"  name="com.ibm.portal.datastore.task.ResourceCleanup">

                                    <dayOfMonth>31</dayOfMonth>

                                    <startTime>23:59</startTime>

                        </task>

-->

<!-- Runs weekly, on early Friday morning

                        <task action="create"  name="com.ibm.portal.datastore.task.ResourceCleanup">

                                    <dayOfWeek>5</dayOfWeek>

                                    <startTime>7:00</startTime>

                        </task>

-->

            </portal>

</request>

Exporting and transferring parts of a portal configuration

You can import the XML file into another portal to create a copy of the page, this importation requires that the referenced resources (such as the portlet and the content parents) also exist on the target portal and can be found by an identifying attribute. In that case, the page and all contained resources take their object IDs with them so that they have the same object IDs on the source and target system - the resources retain their identity. You can avoid that by using the ID generating mode. For more information, see the XML reference documentation. When you use the ID generating mode, the object IDs in the input are not taken literally, but during the import process the resources obtain new object IDs when they are created on the target system. You apply ID generating mode by adding the following attribute to the main request tag:

<request . . . create-oids="true" . . . >