Live Chat
Monday - Friday 8am - 6pm EST Chat Now
Contact Us
Monday - Friday 8am - 8pm EST 1-866-716-6688 Other Contact Options

Cart () Loading...

    • Quantity:
    • Delivery:
    • Dates:
    • Location:


White Paper

How to Update IBM WebSphere Portal Using the Scripting Interface Tool

Oct. 12, 2015
G. David Wilkerson


Managing users' access to an organization's resources via portals is convenient with IBM's WebSphere Portal Scripting Interface. Compare tools available to the portal administrator and identify some use cases where IBM's Portal Scripting Interface may be the ideal choice. Review basic commands and find out how to create custom scripts.


You are wrapping things up for the day when you get an email stating that the Europe, Middle East and Africa (EMEA) development team needs new pages with some portlets configured on the QA portal. The moment you make a mental note to do this first thing in the morning, your boss sends you an instant message telling you that the Asia Pacific QA team plans to do some overnight testing. As you top off your coffee mug, you consider giving developers rights to use the XML configuration interface, but then you remember your organization's security mandates prohibit such a broad administrative scope.

By briefly comparing the portal administrator's tools we can identify some use cases where the scripting interface may be the tool of choice. Next, we'll review how to launch the tool which can help you understand and select options for its use. This puts us in position to learn a few basic commands. Finally, we will take a look at creating and testing our own custom script.

Compare Tools

The portal administrator's toolkit includes administrative portlets, the XML configuration interface, ReleaseBuilder, and the Portal Scripting Interface. IBM's administrative portlets provided for IBM WebSphere Portal are a collection of graphical user interface (GUI) tools available for a wide variety of portal administration tasks. Out of the box, access is limited to members of the portal administration group. However, access to the pages and portlets can be discretely delegated to selected users. In the following example, I've created a sample user named "Alfred User" who is granted access to a subset of the administrative interface. I have granted Alfred access to the Manage Pages portlet to carry out actions using that portlet. But, I did not give Alfred access to other portlets, such as Web Modules.

In addition to managing the tools available to our user, we are also able to manage the resources the user can create or manage. In this example I have given Alfred the role of manager for a subset of the portal's node hierarchy under a label named HR. When the user accesses the Manage Pages portlet he does not see buttons to create or delete nodes until he navigates to the HR label context.

This example is somewhat limited but serves to illustrate an important point, which is your ability to manage what tools and resources are exposed to users. As with other graphical tools, the portal administration portlets are well suited for ad hoc work but not appropriate where precise consistency is required. For example, if we create and configure a page in one environment, how do we repeat that effort in another without introducing the credible likelihood that a step may be skipped or that a setting may be improperly configured? This can be a serious limitation.

XML Configuration Interface

Another tool available to the administrator is the XML configuration interface, commonly called XMLAccess after the script used to launch the tool. Benefits of using the tool derive from a user's ability to export and import entire portal configurations or subsets thereof. The commands are defined by an XML syntax contained in a file and, as such, function much like a script. The tool allows for a task or a collection of tasks to be performed repetitively with predictable outcomes. However, unlike the portal administration portlets, it is not possible to limit the scope of work performed by users of this tool. Access to the tool is granted, by default, to portal administrators. Users of the tool must have a manager role on the virtual resource XML_ACCESS and the security administrator role on the virtual resource PORTAL. Continuing with the previous example, I have granted a user the required roles on two virtual resources: PORTAL and XML_ACCESS. Using a sample script, modCreateTestPage.xml, I launched the XML configuration interface.

Total Pages: