IBM Connections 4: Administer Forums, Home Page, Metrics, Profiles, Wikis

IBM Connections 4 Part 3: Administering Forums, Home Page, Metrics, Profiles, Wikis

IBM Connections 4 Part 3: Administering Forums, Home Page, Metrics, Profiles, Wikis

Administer Forums

Use the wsadmin client to administer Forums by specifying properties in a configuration file or running administrative commands.

You edit the forum-config.xml file to control how and when various Forums operations take place. You use the administrative commands to perform tasks that manipulate Forums content. Changes to the configuration file require node synchronization and a restart of the Forums server before they take effect. Changes made using administrative commands take effect immediately.


Related

  • Manage users

  • Configure the active content filter for Activities, Communities, and Bookmarks

    Run Forums administrative commands

    Jython scripts are used to administer the Forums application. These scripts allow the administrator to view Forums data and perform administrative tasks for Forums.

    To run administrative commands, you must use the IBM WebSphere® Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. Administrative commands interact with the Forums application and its resources through scripts. These scripts use the AdminControl object available in the IBM WebSphere Application Server wsadmin tool to interact with the Forums server. Each script uses managed Java. beans (MBeans) to perform administrative tasks.

    If an error occurs when you are executing the MBean commands, you can examine the SystemOut.log file to determine what went wrong.

    Unlike with configuration properties, when you use administrative commands you do not have to check out any files or restart the server. The commands are executed and take effect immediately.

    To run Forums administrative commands.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. See Forums administrative commands for a complete list of editable administrative commands for the Forums application.


    Related tasks

  • Start the wsadmin client


    Forums administrative commands

    Use the commands listed to perform administrative tasks for Forums. No file checkout or server restart is needed when using these commands.

    The following sections define the commands that you can use when working with Forums. Each section describes the commands for a specific service. The commands are listed in alphabetical order.


    ForumsConfigService commands

    ForumsConfigService.checkOutConfig("working_directory", "cell_name")

    Checks out the Forums configuration files.

    This command takes the following parameters:

    <working_directory>

    Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

    <cell_name>

    Name of the IBM WebSphere Application Server cell hosting the IBM Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:

    print AdminControl.getCell()
    For example:

    • AIX/Linux:

      ForumsConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    • Microsoft®

      Windows:

      ForumsConfigService.checkOutConfig("c:/temp","foo01Cell01")

    ForumsConfigService.checkInConfig()

    Checks in the Forums configuration files. Run from the wsadmin command processor.

    ForumsConfigService.showConfig()

    Determine which property needs to be updated manually from the checkout command. The default Forums configuration properties are as follows:

    • activeContentFilter.enabled = true

    • discussThis = false

    • discussThis.targetBookmarklet = http://{server}/connections/bookmarklet

    • objectStore.allowUpload = true

    • task.TrashAutoPurgeJob.enabled = true

    • task.TrashAutoPurgeJob.interval = 0 0 2 ? * SUN

    • task.TrashAutoPurgeJob.trashRetentionInDays = 90


    ForumsMemberService commands

    ForumsMemberService.previewSyncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"[, .multiLine. : ["true" | "false"] ] [, .verbose. : ["false" | "true"] }] )

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.previewSyncMemberExtIdByEmail("emailAddr" [, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.previewSyncMemberExtIdByEmail("emailAddr" [, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.getMemberExtIdByEmail("email")

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.getMemberExtIdByLogin("login")

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.inactivateMemberByEmail("email")

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.inactivateMemberByExtId("externalID")

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.syncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"] } )

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.syncMemberByExtId("currentExternalId"[, {"newExtId" : "id-string" [, "allowExtIdSwap" : ["true" | "false"] ] } ] )

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.syncMemberExtIdByEmail("email" [, { "allowInactivate" : ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.

    ForumsMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate": ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.


    ForumsScheduler commands

    ForumsScheduler.getTaskDetails(String taskName)

    Returns information about the scheduled task specified by taskName. Forums currently has a single managed task . TrashAutoPurgeJob.

    The values returned are server time, next scheduled run time, status (SCHEDULED, RUNNING, SUSPENDED), and task name. When the task has been paused, then the status parameter shows as SUSPENDED instead of SCHEDULED. SUSPENDED means that the task is not scheduled to run.

    For example:

    ForumsScheduler.getTaskDetails("TrashAutoPurgeJob")
    The resulting output looks similar to the following:

    {currentServerTime=Wed Feb 03 14:21:47 EST 2010, nextFireTime=Sun Feb 07 02:00:00 EST 2010, status=SCHEDULED, taskName=TrashAutoPurgeJob}

    ForumsScheduler.pauseSchedulingTask(String taskName)

    Temporarily pauses the specified task and stops it from running.

    When you pause a scheduled task, the task remains in the suspended state even after you stop and restart Forums or the IBM WebSphere Application Server. You need to run the ForumsScheduler.resumeSchedulingTask(String taskName) command to get the task running again.

    If the task is currently running, it continues to run but is not scheduled to run again. If the task is already suspended, this command has no effect.

    For example:

    ForumsScheduler.pauseSchedulingTask("TrashAutoPurgeJob")
    When a task is paused, a status message similar to the following is written to the SystemOut.log file:

    [2/3/10 14:28:10:782 EST] 0000002f ForumsNotific I   CLFWY0134I: Forums scheduled task 'TrashAutoPurgeJob' fired event 'TaskNotificationInfo.SUSPENDED'

    ForumsScheduler.resumeSchedulingTask(String taskName)

    If the task is suspended, puts the task in the scheduled state. If the task is not suspended, this command has no effect.

    When a task is resumed, it does not run immediately; it runs at the time when it is next scheduled to run.

    For example:

    ForumsScheduler.resumeSchedulingTask("TrashAutoPurgeJob")
    Resuming a paused task causes the following status message to be written to the SystemOut.log file:

    [2/3/10 14:28:25:407 EST] 00000051 ForumsNotific I   CLFWY0134I: Forums scheduled task 'TrashAutoPurgeJob' fired event 'TaskNotificationInfo.RESUMED'


    ForumsService commands

    ForumsService.deleteForums(java.util.Vector forums)

    Moves the specified forums to the Trash view. Forums in the Trash view can be restored as long as they are restored before the trash is emptied. The command returns a java.util.Vector, where each object in the vector is a java.util.Hashtable that describes a forum that could not be deleted. A returned empty vector indicates complete success.

    ForumsService.exportSyncedResourceInfo(java.lang.String filePath, java.lang.String eventType)

    Writes a report that lists all the community forums and identifies their associated communities. The file is saved to the directory path that you specify.

    You can use this command to restore backed-up data. See Comparing remote application data with the Communities database for more information.

    Parameters:

    filePath

    A string that specifies the full directory path in which to store the file that is returned by the command. Include the file name in the file path and use forward slashes. For example, C:/temp/forum_output.xml.

    eventType

    Identifies the type of synchronization events to report about. The only supported value for this parameter is community. Specify this value as a singular community and in lower case.
    For example:

    ForumsService.exportSyncedResourceInfo("C:/temp/forum_output.xml","community")

    ForumsService.fetchForums()

    Lists forums by forumID, for example:

    {forumID=7d53c588-4b34-4497-8556-6f253519891f}

    ForumsService.fetchForumsByName(java.lang.String forumName)

    Retrieves the forum with the specified name, for example:

    ForumsService.fetchForumsByName("My Forum")

    ForumsService.filterInput(VectorinputVector, java.lang.String toMatch, java.lang.String attrName)

    Filters a source vector of forums to return a new vector containing a map pair that matches the specified filter criteria.

    This command take the following parameters:

    inputVector

    The source vector that contains the map collection.

    toMatch

    Java regular expression pattern representing match criteria. This pattern is used to search the attrName (specified in next parameter) of the forums or entries. The pattern must match the full name and is case sensitive. You can use the following keys:

    • Period (.) matches any character.

    • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.

    • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.

    • [chars] matches any one character within the square brackets ([]). For example, [Gg] matches either an upper or lower case G.

    • [A-Z] matches a range of characters.

    attrName

    The key to be filtered in the map. Possible values include name and forumID. The default value is name.

    ForumsService.reCountAllForums()

    Recalculate total number of forums in your organization.

    This command does not take any parameters.

    ForumsService.reCountForums(Vector forums)

    Recalculate number of specified forums in your organization, where you specify the forums to recalculate as a vector variable that represents multiple forums.

    For example:

    ForumsService.reCountForums(myforums)


    ForumsTopicsService commands

    ForumsTopicsService.fetchTopics()

    Gets a list of all forum topics, except those that have been moved to the trash.

    Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

    ForumsTopicsService.fetchTopicsByDate(String type, String begindate, String enddate)

    Gets a list of forum topics that were created or modified in a specified date range. The maximum number of topics in the returned list is 50. To obtain all the topics that match the criteria if the number is greater than 50, call this method in a loop, providing the UUID of the 50th topic from the previous list as the lastUUID parameter.

    Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

    This command takes the following parameters:

    type

    Specifies the date type of interest. The following values are valid:

    • created

    • modified

    begindate

    Start timestamp of the date range, specified in a yyyy.mm.dd format.

    enddate

    Finish timestamp of the date range, specified in a yyyy.mm.dd format.

    For example:

    ForumsTopicsService.fetchTopicsByDate("created","2010.05.21","2010.05.22")

    ForumsTopicsService.fetchTopicsByDate("modified","2010.05.21","2010.05.22")

    ForumsTopicsService.fetchTopicsCreatedByMember(String extId, String type)

    Gets a list of forum topics created by the specified member, except those that are in the trash.

    Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

    This command takes the following parameters:

    extId

    The external ID of the specified member whose topics you want to retrieve.

    type

    The type of external ID specified. The following values are valid:

    • uuid

    • email

    For example:

    ForumsTopicsService.fetchTopicsCreatedByMember("778CE573-78A5-2ECF-8525-7346003DB078","uuid")

    ForumsTopicsService.fetchTopicsCreatedByMember("ajones10@example.com","email")

    ForumsTopicsService.fetchTopicById(String topicuuid)

    Gets the forum topic identified by the specified universal identifier.

    Returns a java.util.Hashtable object that describes the forum topic.

    This command takes the following parameter:

    topicuuid

    The unique identifier of the forum topic.

    For example:

    ForumsTopicsService.fetchTopicById("15279c53-7bb2-43dd-96ad-2eee2c7f10f8")

    ForumsTopicsService.deleteTopics(Vector forumtopics)

    Moves the specified forum topics to the trash. Forum topics in the Trash view can be restored as long as they are restored before the trash is emptied.

    Returns a java.util.Vector. Each object in the vector is a java.util.Hashtable that describes a forum topic that could not be deleted. A returned empty vector indicates complete success.

    This command takes the following parameter:

    forumtopics

    Vector of hash tables describing the forum topics to be deleted.

    For example:

    ForumsTopicsService.deleteTopics(janetstopics)

    ForumsService.reCountForumById(java.lang.String uuid)

    Recalculate number of topics in a specific forum, where you specify the forum by its UUID.

    For example:

    ForumsService.reCountForumById("778CE573-78A5-2ECF-8525-7346003DB078")

    ForumsTopicsService.reCountTopics(Vector topics)

    Recalculate number of specified topics in your organization,

    ...where you specify the topics to recalculate as a vector variable that represents multiple topics.

    For example:

    ForumsTopicsService.reCountTopics(mytopics)


    ForumsTrashService commands

    ForumsTrashService.fetchForumsTrash()

    Retrieves a list of the deleted forums currently in the trash

    ForumsTrashService.fetchTopicsTrash()

    Retrieves a list of the deleted forum topics currently in the trash.

    ForumsTrashService.fetchForumsTrashByDate(String modifySince)

    Retrieves a list of the forums that were deleted on a specific date.

    This command takes the following parameter:

    modifySince

    A string that specifies the date when the forum was deleted in yyyy.MM.dd format.

    ForumsTrashService.filterForumsByName(VectorinputVector, java.lang.String toMatch)

    Filters a source vector of forums to return a new vector containing a map pair that matches the specified name filter criteria.

    This command take the following parameters:

    inputVector

    The source vector that contains the map collection.

    toMatch

    Java regular expression pattern representing match criteria. This pattern is used to search the name of the forums. The pattern must match the full name and is case sensitive. You can use the following keys:

    • Period (.) matches any character.

    • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.

    • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.

    • [chars] matches any one character within the square brackets ([]). For example, [Gg] matches either an upper or lower case G.

    • [A-Z] matches a range of characters.

    ForumsTrashService.purgeForumsTrash(vector hashtable)

    Purges the specified forums from the trash, where you specify the forums to delete using the hashtable parameter.

    For example:

    ForumsTrashService.purgeForumsTrash(forumtrash)

    ForumsTrashService.purgeTopicsTrash(vector hashtable)

    Purges the specified forum topics from the trash, where you specify the topics to delete using the hashtable parameter.

    For example:

    ForumsTrashService.purgeTopicsTrash(topictrash)

    ForumsTrashService.undeleteForumsTrash(vector hashtable)

    Restores a deleted forum or forums, where you specify the forum or forums to restore using the hashtable parameter.

    For example:

    ForumsTrashService.undeleteForumsTrash(forumsTrash)

    ForumsTrashService.undeleteTopicTrash(vector hashtable)

    Restores a deleted forum topic or topics, where you specify the topic or topics to restore using the hashtable parameter.

    For example:

    ForumsTrashService.undeleteTopicTrash(topictrash)


    Related

  • Synchronize user data using administrative commands

  • Run administrative commands
  • Compare remote application data with the Communities database
  • Synchronize remote application data with the Communities database

    Change Forums configuration property values

    Configuration settings control how and when various Forums operations take place. You can edit the settings to change the ways that forums behave.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. Configure Forums using scripts accessed with the wsadmin client. These scripts use the AdminConfig object available in the WebSphere Application Server wsadmin client to interact with the Forums configuration file. Changes to Forums configuration settings require node synchronization and a restart of the Forums server before they take effect.

    To change Forums configuration settings, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Forums Jython script interpreter.

      1. Use the following command to access the Forums configuration files:

        execfile("forumsAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Check out the Forums configuration files :

        ForumsConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX® and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        ForumsConfigService.checkOutConfig("/opt/my_temp_dir", "ForumServerNode01Cell")

    3. Optional: To view a list of the valid Forums configuration settings and their current values, use the following command:

      ForumsConfigService.showConfig()

    4. To change a Forums configuration setting, use the following command:

      ForumsConfigService.updateConfig("property", "value")

      ...where property is one of the editable Forums configuration properties and value is the new value with which you want to set that property. See Forums configuration properties for a complete list of editable properties.

      For example:

      ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.trashRetentionInDays", "120")

    5. Optional: After updating the Forums properties with new values, use the ForumsConfigService.showConfig() command to display the list of properties and their updated values. These are the values that will be checked in with the ForumsConfigService.checkInConfig() command.

    6. Optional: Repeat step 3 for each property setting to change.


    What to do next

    You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See Applying property changes for details.


    Related tasks

  • Start the wsadmin client
  • Enable forum topic posting in different deployments


    Forums configuration properties

    Configuration settings control various configurable applications within Forums and also help in the optimization of server performance. They require a Forums application or server restart to take effect.

    You can check out and modify the following configuration settings in the forum-config.xml file. The properties are listed in alphabetical order.

    activeContentFilter.enabled

    When enabled, this property prevents the addition of active content (JavaScript) in any text input field.

    This property takes a Boolean value: true or false.

    Disabling this filter introduces vulnerability to cross-site scripting (XSS) and other type of malicious attacks. See Securing applications from malicious attack for additional information.

    For example:

    ForumsConfigService.updateConfig("activeContentFilter.enabled","true")

    discussThis.enabled

    Users in IBM Connections can click Bookmark or Discuss This on any IBM Connections page to install a Discuss This button in their browser tool bar. When they click the button, the content of the current web or IBM Connections page is added to a forum topic. The user can then choose a forum they have access to, and add the topic to that forum.

    The discussThis configuration property allows you to enable a similar Discuss This button on every forum topic page. The button allows users to post the topic as a new topic in a forum in a different IBM Connections deployment which you specify in the discussThis.internalHost element.

    For example, you might have two IBM Connections deployments in your enterprise, A and B. You want users in deployment A forums to be able to post topics to deployment B forums. You would check out the forums-config.xml document in deployment A, and specify the server address where you can access the forums application in B. When a user opens a forum page in deployment A and clicks the Discuss This link, they can select the target forum on deployment B from the pop-up dialog. If the user is not logged into deployment B, they are prompted to log in before they can post the new topic.

    In order for the Discuss This link to display in the topic page, the user must be a member of the group that the discussThis-user J2EE role on deployment A is mapped to (the default is Everyone). See Enabling forum topic posting in different deployments for detailed steps for configuring the button.

    This property takes a Boolean value: true or false. It is enabled (set to true) by default.

    discussThis.targetBookmarklet

    Specifies the server address where you can access the forums application in a different IBM Connections deployment. This is required to enable the Discuss This feature described in the discussThis.enabled property previously listed. See Enabling forum topic posting in different deployments for detailed steps for configuring the button.

    This property takes a server address, such as: http://servername.enterprise.com:9081

    objectStore.allowUpload

    Enables or disables the uploading of file attachments to forums.

    This property takes a Boolean value: true or false.

    For example:

    ForumsConfigService.updateConfig("objectStore.allowUpload","false")

    task.TrashAutoPurgeJob.enabled

    Enables or disables the forum purge trash task.

    This property accepts the following values: true or false.

    For example:

    ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.enabled", "true")

    task.TrashAutoPurgeJob.trashRetentionInDays

    Specifies the number of days that deleted content remains in the database as being soft-deleted. The value must be set to 1 or greater. If the value is less than 1, the trash is not purged by this job. The default value is 90.

    For example:

    ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.trashRetentionInDays", "120")

    task.TrashAutoPurgeJob.interval

    Specifies the interval at which the forum purge trash task runs.

    When you change the interval property, the new schedule is registered the next time that Forums is started on any server in the Forums cluster (if there is one).

    For example:

    ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.interval", "0 0/15 * * * ?")


    Related tasks

  • Apply property changes in Forums
  • IBM Connections configuration property values


    Apply property changes in Forums

    After you have edited the Forums configuration properties, check the changed configuration file in, and restart the servers to apply the changes.

    See Forums configuration properties for information about the properties that you can edit.

    1. Check in the changed configuration property keys using the following wsadmin client command:

      ForumsConfigService.checkInConfig()

      The checkin must be done in the same wsadmin session as the checkout.

    2. Update the value of the version stamp configuration property in LotusConnections-config.xml to force users' browsers to pick up this change. See Required post-customization step for more details.

    3. To exit the wsadmin client, type exit at the prompt.

    4. Use the IBM WebSphere Application Server Integrated Solutions Console to stop and restart the server hosting the Forums application.


    Related tasks

  • Apply common configuration property changes
  • Required post-customization step

  • Forums configuration properties

    Retrieve forum content

    You can use administrative commands to retrieve lists of forums and forum topics. You can also narrow down a list of forums to retrieve a specific subset of forums on which you want to perform an operation.


    Get a list of forums

    Use administrative commands to retrieve lists of forums that you can subsequently manipulate programmatically.

    To run administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands to retrieve the forums in your organization:

      ForumsService.fetchForums()

      Lists forums by forumID, for example:

      {forumID=7d53c588-4b34-4497-8556-6f253519891f}

      ForumsService.fetchForumsByName(java.lang.String forumName)

      Retrieves the forum with the specified name, for example:

      ForumsService.fetchForumsByName("My Forum")


    Related tasks

  • Start the wsadmin client
  • Filter lists of forums


    Get a list of forum topics

    Use administrative commands to retrieve forum topics by date, by creator, and by topic UUID. You do not need to check the Forums configuration file in and out, or restart the Forums server when using these commands.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    To retrieve forum content.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands as needed.

      ForumsTopicsService.fetchTopics()

      Gets a list of all forum topics, except those that have been moved to the trash.

      Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

      ForumsTopicsService.fetchTopicsByDate(String type, String begindate, String enddate)

      Gets a list of forum topics that were created or modified in a specified date range. The maximum number of topics in the returned list is 50. To obtain all the topics that match the criteria if the number is greater than 50, call this method in a loop, providing the UUID of the 50th topic from the previous list as the lastUUID parameter.

      Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

      This command takes the following parameters:

      type

      Specifies the date type of interest. The following values are valid:

      • created

      • modified

      begindate

      Start timestamp of the date range, specified in a yyyy.mm.dd format.

      enddate

      Finish timestamp of the date range, specified in a yyyy.mm.dd format.

      For example:

      ForumsTopicsService.fetchTopicsByDate("created","2010.05.21","2010.05.22")

      ForumsTopicsService.fetchTopicsByDate("modified","2010.05.21","2010.05.22")

      ForumsTopicsService.fetchTopicsCreatedByMember(String extId, String type)

      Gets a list of forum topics created by the specified member, except those that are in the trash.

      Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one forum topic.

      This command takes the following parameters:

      extId

      The external ID of the specified member whose topics you want to retrieve.

      type

      The type of external ID specified. The following values are valid:

      • uuid

      • email

      For example:

      ForumsTopicsService.fetchTopicsCreatedByMember("778CE573-78A5-2ECF-8525-7346003DB078","uuid")

      ForumsTopicsService.fetchTopicsCreatedByMember("ajones10@example.com","email")

      ForumsTopicsService.fetchTopicById(String topicuuid)

      Gets the forum topic identified by the specified universal identifier.

      Returns a java.util.Hashtable object that describes the forum topic.

      This command takes the following parameter:

      topicuuid

      The unique identifier of the forum topic.

      For example:

      ForumsTopicsService.fetchTopicById("15279c53-7bb2-43dd-96ad-2eee2c7f10f8")


    Related tasks

  • Start the wsadmin client


    Filter lists of forums

    Use the ForumsService.filterInput or ForumsTrashService.filterForumsByName command to retrieve a subset of forums on which you want to perform an operation.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. When you retrieve a set of forums using one of the fetch commands, you can filter the list of forums to find a forum with a specific name or ID.

    1. When you use a fetch command to retrieve a set of forums, use a variable to store the returned data.
      For example, the following code stores the objects returned from the fetchForumsTrash() command in the alltrash variable:

      alltrash=ForumsTrashService.fetchForumsTrash()
      The objects are formatted as a java.util.Vector of hash tables that represent deleted forums in the Trash view.

    2. Use the following commands to narrow down the list of results that you stored in the variable:

      ForumsService.filterInput(VectorinputVector, java.lang.String toMatch, java.lang.String attrName)

      Filters a source vector of forums to return a new vector containing a map pair that matches the specified filter criteria.

      This command take the following parameters:

      inputVector

      The source vector that contains the map collection.

      toMatch

      Java regular expression pattern representing match criteria. This pattern is used to search the attrName (specified in next parameter) of the forums or entries. The pattern must match the full name and is case sensitive. You can use the following keys:

      • Period (.) matches any character.

      • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.

      • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.

      • [chars] matches any one character within the square brackets ([]). For example, [Gg] matches either an upper or lower case G.

      • [A-Z] matches a range of characters.

      attrName

      The key to be filtered in the map. Possible values include name and forumID. The default value is name.

      ForumsTrashService.filterForumsByName(VectorinputVector, java.lang.String toMatch)

      Filters a source vector of forums to return a new vector containing a map pair that matches the specified name filter criteria.

      This command take the following parameters:

      inputVector

      The source vector that contains the map collection.

      toMatch

      Java regular expression pattern representing match criteria. This pattern is used to search the name of the forums. The pattern must match the full name and is case sensitive. You can use the following keys:

      • Period (.) matches any character.

      • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.

      • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.

      • [chars] matches any one character within the square brackets ([]). For example, [Gg] matches either an upper or lower case G.

      • [A-Z] matches a range of characters.

      For example, the alltrash vector saved in step 1 has two maps as follows, each of which has one value pair, (key = "name", value=""):

      alltrash={name=forum-1, name=forum-2}
      The following command filters the alltrash vector to get only those maps for which the value of the name key is forum-1. The maps are stored in a vector named vii. Note that the default value of the third parameter is name.

      vii=ForumsService.filterInput(alltrash, "forum-1")
      or

      vii=ForumsTrashService.filterForumsByName(alltrash,"forum-1")
      The command returns the following vector:

      vii={name=forum-1}

      As another example, let.s say to filter the results of the following source vector by forumID.

      inputVector=ForumsService.fetchForums()

      ...where the inputVector vector has two maps, each of which has one value pair, (key = "forumID", value=""):

      inputVector={forumID=00000-0001, forumID=00000-0002}
      The following command returns only the forum with the ID, 00000-0001:

      vii = ForumsService.filterInput(inputVector,"00000-0001","forumID")
      The command returns the following vector:

      vii={forumID=00000-0001}

    3. Pass the variable containing the subset of resources that you want to operate on into the command that you are using.
      For example, to restore the collected subset of forums stored in the vii variable, you might use the following command:

      ForumsTrashService.undeleteForumsTrash(vii)


    Related tasks

  • Start the wsadmin client
  • Get a list of forums
  • Restore deleted forum content
  • Purging specific forum content from the trash

    Rectifying the count of forums and forum topics

    If a transaction involving the Forums application fails, the total count of forums and forum topics that display in the Forums user interface might not be consistent. You can use administrative commands to manually recalculate the count of forums and forum topics in your organization and ensure that the figures are up-to-date.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. You do not need to check the Forums configuration file in and out, or restart the Forums server when using these commands.

    To recalculate the number of forums and forum topics, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands as needed.

      ForumsService.reCountAllForums()

      Recalculate total number of forums in your organization.

      This command does not take any parameters.

      ForumsService.reCountForums(Vector forums)

      Recalculate number of specified forums in your organization,

      ...where you specify the forums to recalculate as a vector variable that represents multiple forums.

      For example:

      ForumsService.reCountForums(myforums)

      ForumsService.reCountForumById(java.lang.String uuid)

      Recalculate number of topics in a specific forum, where you specify the forum by its UUID.

      For example:

      ForumsService.reCountForumById("778CE573-78A5-2ECF-8525-7346003DB078")

      ForumsTopicsService.reCountTopics(Vector topics)

      Recalculate number of specified topics in your organization,

      ...where you specify the topics to recalculate as a vector variable that represents multiple topics.

      For example:

      ForumsTopicsService.reCountTopics(mytopics)

    4. Use the following command to filter a vector result:

      Vector vii=ForumsService.filterInput(VectorinputVector,java.lang.String toMatch,java.lang.String attrName)
      This command returns a new vector that contains a map pair to match the filter criteria.

      The command takes the following parameters:

      inputVector

      The source vector that contains the map collection.

      toMatch

      The value pattern that you are using to narrow down your results.

      attrName

      The key to be filtered in the map.
      For example, you might get a vector of forums using the following command:

      inputVector=ForumsService.fetchForums()
      The inputVector vector contains two maps as follows:

      inputVector = {name=forum-1,name=forum-2}
      Each map has one value pair:

      (key = "name", value="")

      In this example, you want to filter the vector to retrieve the maps in which the value of the name key is forum-1 so you run the following command:

      Vector vii=ForumsService.filterInput(inputVector,"forum-1","name")
      The vii vector variable now contains a single forum with a name key of forum-1:

      vii = {name=forum-1}


    Related tasks

  • Start the wsadmin client

    Moderate forums

    When moderation is enabled for Forums, a designated moderator can review posts before they are published to a forum and manage posts after they are added to a forum. Forums moderation is supported for community forums and stand-alone forums.

    If premoderation is enabled for your deployment, when users create or reply to forum posts, the content that they add does not display until it is approved by a moderator. If postmoderation is enabled, the moderator can review content that has been flagged as inappropriate and the reason given for flagging it, and determine whether the content should be removed or the flag dismissed.

    As administrator, you can control who has permission to moderate forum content using two scopes:

    Global moderation

    You can assign people the J2EE global-moderator role for Forums using the IBM WebSphere Application Server Integrated Solutions Console. For more information about assigning roles, see Roles.

    Users who have been assigned the global-moderator role can see an additional Moderation link in the application menu bar when they are logged in to IBM Connections. This link is only visible to global moderators. Clicking the link provides access to a global moderation interface where moderators can review and manage posts from stand-alone forums and community forums.

    For more information about moderating forum content from the global moderation interface, see Moderation overview.

    Community forum moderation

    Community forums can be moderated by community owners if owner moderation for Communities is enabled in the contentreview-config.xml file. For more information about how to configure owner-moderation settings, see Managing content moderation and flagged content.

    When owner moderation is enabled for Communities, community owners can review and manage the content of their community forums directly from the community by logging in to IBM Connections and selecting Moderate Community from the Community Actions menu. Community owners can only review content from their own community forums.

    For more information about moderating content in community forums, see Moderating community content.

    In addition to the global moderation interface and community moderation interface, the public Forums moderation API can be leveraged by third-party developers to moderate stand-alone and community forum content. For more information, see Moderating forum content programmatically.


    Related

  • Moderation overview
  • Moderate forum content programmatically
  • Moderate the content in a community

  • Manage content moderation and flagged content
  • Moderate content before it is published
  • Moderate published content that is flagged

  • Roles

    Manage forum trash

    Use administrative commands and edit configuration property settings to move forum content to the trash, empty the trash, restore forums and forum topics from the trash, and perform other trash management tasks for Forums.


    Move forums to the trash

    Use administrative commands to move one or more forums to the Trash view.

    To run administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. To move forums to the trash, first generate a variable containing the forums to delete, and then delete the forums associated with that variable as follows.

      1. Create a variable that contains the forum or forums to delete. You can get a list of forums in hash table format using one of the fetchForums() commands. See Get a list of forums for more information about the commands.

        For example:

        variable=ForumsService.fetchForumsByName(java.lang.String forumName)

      2. Enter the following command to delete the forum or forums:

        ForumsService.deleteForums(java.util.Vector forums)

        ...where you specify the forum or forums to delete as the forums parameter. This parameter maps to the variable that you created in the previous step.

        For example, if a person leaves the organization and you want to delete a forum owned by them, you use the following commands to generate a variable containing the forum and then delete the forum associated with that variable.

        obsoleteForum=ForumsService.fetchForumsByName("Joes Forum")
        wsadmin>ForumsService.deleteForums(obsoleteForum)


    Related tasks

  • Start the wsadmin client
  • Get a list of forums
  • Purging forum trash on a schedule
  • Purging specific forum content from the trash
  • Restore deleted forum content


    Delete topics from forums

    Use administrative commands to remove unwanted or inappropriate topics from the Forums application.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. When you remove topics from a forum, the topics are soft-deleted. To remove forum topics from the database completely, you need to purge the forum trash. For more information about purging the trash, see Purging forum trash on a schedule.

    To delete forum topics.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. If you have not yet created a variable that contains the forum topics to delete, create one now. You can get a list of forum topics in hash table format by using one of the ForumsTopicsService fetch commands. For more information about these commands and how to use them, see Get a list of forum topics.

      When an employee leaves the organization, for example, and you want to delete all of the forum topics that they created, you can use the following command to identify the forum topics to delete:

      ForumsTopicsService.fetchTopicsCreatedByMember(String extId, String type)
      For example:

      janetstopics=ForumsTopicsService.fetchTopicsCreatedByMember("ajones10@example.com","email")

      You can also fetch the topics using the employee's member uuid. For example:

      janetstopics=ForumsTopicsService.fetchTopicsCreatedByMember("778CE573-78A5-2ECF-8525-7346003DB078","uuid")

    4. Use the following command to delete forum topics:

      ForumsTopicsService.deleteTopics(Vector forumtopics)

      Moves the specified forum topics to the trash. Forum topics in the Trash view can be restored as long as they are restored before the trash is emptied.

      Returns a java.util.Vector. Each object in the vector is a java.util.Hashtable that describes a forum topic that could not be deleted. A returned empty vector indicates complete success.

      This command takes the following parameter:

      forumtopics

      Vector of hash tables describing the forum topics to be deleted.

      For example:

      ForumsTopicsService.deleteTopics(janetstopics)


    Related tasks

  • Start the wsadmin client
  • Purging forum trash on a schedule
  • Purging specific forum content from the trash
  • Restore deleted forum content


    Restore deleted forum content

    Use the ForumsTrashService commands to restore deleted forum content from the trash with immediate effect. You do not need to check the Forums configuration file out or restart the server when using these commands.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. If you change your mind about deleting content from the Forums application, you can restore forum content from the trash. After a forum or forum topic is deleted, the deleted content can be preserved if it is restored.

    To restore forum content that has been deleted, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Do one of the following.

      • To get a list of the deleted forums currently in the trash, enter the following command:

        ForumsTrashService.fetchForumsTrash()

      • To get a list of the deleted forum topics currently in the trash, enter the following command:

        ForumsTrashService.fetchTopicsTrash()

      • To get a list of forums that were deleted on a specific date, enter the following command:

        ForumsTrashService.fetchForumsTrashByDate(String modifySince)

        ...where modifySince is a string that specifies the date when the forum was deleted in yyyy.MM.dd format.

        For example:

        vari = ForumsTrashService.fetchForumsTrashByDate("2011.04.11")
        This command retrieves all the forums that were deleted on the 11th of April, 2011 and uses a variable called vari to store the returned data.

    4. Optional: Identify the forums or forum topics to restore from the returned list. Use the following command to filter the forums by name:

      ForumsTrashService.filterForumsByName(VectorinputVector, java.lang.String toMatch)

      Filters a source vector of forums to return a new vector containing a map pair that matches the specified name filter criteria.

      This command take the following parameters:

      inputVector

      The source vector that contains the map collection.

      toMatch

      Java regular expression pattern representing match criteria. This pattern is used to search the name of the forums. The pattern must match the full name and is case sensitive. You can use the following keys:

      • Period (.) matches any character.

      • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.

      • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.

      • [chars] matches any one character within the square brackets ([]). For example, [Gg] matches either an upper or lower case G.

      • [A-Z] matches a range of characters.

    5. To restore deleted content, use the following commands.

      ForumsTrashService.undeleteForumsTrash(vector hashtable)

      Restores a deleted forum or forums, where you specify the forum or forums to restore using the hashtable parameter.

      For example:

      ForumsTrashService.undeleteForumsTrash(forumsTrash)

      ForumsTrashService.undeleteTopicTrash(vector hashtable)

      Restores a deleted forum topic or topics, where you specify the topic or topics to restore using the hashtable parameter.

      For example:

      ForumsTrashService.undeleteTopicTrash(topictrash)


    Example

    To identify the forums to restore from the trash, first generate a variable containing a list of forums, and then filter that list by forum name to narrow down the list of forums to restore as follows:

    1. Create a variable that contains a list of forums in the trash. You can get a list of forums in hash table format using one of the fetchForums commands, ForumsTrashService.fetchForumsTrash() or ForumsTrashService.fetchForumsTrashByDate(String modifySince).

      For example:

      april4Trash = ForumsTrashService.fetchForumsTrashByDate("2011.04.11")

    2. Filter the list of forums returned by the previous command to find the forum or forums to restore.

      For example, to find a forum with the name Forum1:

      myForums = ForumsTrashService.filterForumsByName(april4Trash,"Forum1")
      Alternatively, you can filter the list of forums to find forums that have a name that begins with "Forum" and then store them in the myForums variable:

      myForums = ForumsTrashService.filterForumsByName(april4Trash,"Forum.*")

    3. Restore the forum or forums from the trash by passing the variable containing the subset of forums returned in the previous step to the undeleteForumsTrash command.

      For example:

      ForumsTrashService.undeleteForumsTrash(myForums)


    Related tasks

  • Start the wsadmin client
  • Move forums to the trash
  • Delete topics from forums
  • Filter lists of forums


    Purging forum trash on a schedule

    Edit settings in the forum-config.xml file to configure the Forums trash purge schedule. You can define the interval at which the task runs by configuring the interval property, which uses a Cron schedule.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details. The trash purge job is scheduled to run periodically to permanently remove content deleted from a forum from the trash. Forums uses the WebSphere Application Server scheduling service for purging trash from Forums. For more information about the scheduler, see Scheduling tasks.

    To configure the TrashAutoPurgeJob task, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Forums Jython script interpreter.

      1. Use the following command to access the Forums configuration files:

        execfile("forumsAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Check out the Forums configuration files :

        ForumsConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        ForumsConfigService.checkOutConfig("/opt/my_temp_dir", "ForumServerNode01Cell")

    3. To view the current configuration settings, use the following command:

      ForumsConfigService.showConfig()

      After updating any of the configuration settings, you can use this command again to display your updates.

    4. To change configuration settings for Forums, use the following command:

      ForumsConfigService.updateConfig("property", "value")

      where:

      • property is one of the editable Forums configuration properties.

      • value is the new value with which you want to set that property.
      The following table displays information about the TrashAutoPurgeJob property and the type of data that you can enter for it.

      Table 1. TrashAutoPurgeJob properties

      Property Description
      task.TrashAutoPurgeJob.enabled Enables or disables the forum purge trash task.

      This property accepts the following values: true or false.

      For example:

      ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.enabled", "true")
      task.TrashAutoPurgeJob.trashRetentionInDays Specifies the number of days that deleted content remains in the database as being soft-deleted. The value must be set to 1 or greater. If the value is less than 1, the trash is not purged by this job. The default value is 90.

      For example:

      ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.trashRetentionInDays", "120")
      task.TrashAutoPurgeJob.interval Specifies the interval at which the forum purge trash task runs.

      When you change the interval property, the new schedule is registered the next time that Forums is started on any server in the Forums cluster (if there is one).

      For example:

      ForumsConfigService.updateConfig("task.TrashAutoPurgeJob.interval", "0 0/15 * * * ?")

    5. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Forums for information about how to save and apply your changes.


    Related

  • Schedule tasks

  • Start the wsadmin client
  • Manage Forums scheduled tasks
  • Apply property changes in Forums
  • Move forums to the trash
  • Delete topics from forums


    Purging specific forum content from the trash

    Use administrative commands to permanently delete a specific forum or forum topic by removing it from the trash. You do not need to check the Forums configuration file out or restart the server when using these commands.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    To purge specific forum content from the trash, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. To get a list of the deleted forum content currently in the trash, use the following commands.

      ForumsTrashService.fetchForumsTrash()

      Retrieves a list of the deleted forums currently in the trash

      ForumsTrashService.fetchTopicsTrash()

      Retrieves a list of the deleted forum topics currently in the trash.

      ForumsTrashService.fetchForumsTrashByDate(String modifySince)

      Retrieves a list of the forums that were deleted on a specific date.

      This command takes the following parameter:

      modifySince

      A string that specifies the date when the forum was deleted in yyyy.MM.dd format.

    4. Identify the forum or forum topic to purge from the trash. See Filtering lists of forums for more information about how to narrow down a list of forums.

    5. To delete a specific forum or forum topic from the trash permanently, use the following commands.

      ForumsTrashService.purgeForumsTrash(vector hashtable)

      Purges the specified forums from the trash, where you specify the forums to delete using the hashtable parameter.

      For example:

      ForumsTrashService.purgeForumsTrash(forumtrash)

      ForumsTrashService.purgeTopicsTrash(vector hashtable)

      Purges the specified forum topics from the trash, where you specify the topics to delete using the hashtable parameter.

      For example:

      ForumsTrashService.purgeTopicsTrash(topictrash)


    Related tasks

  • Start the wsadmin client
  • Move forums to the trash
  • Delete topics from forums
  • Filter lists of forums

    Manage Forums scheduled tasks

    Use the ForumsScheduler administrative commands to manage the tasks scheduled for forums.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. Forums uses the IBM WebSphere Application Server scheduling service for performing regular managed tasks. For more information about how the scheduler works, see Scheduling tasks.

    Forums has one managed task, the TrashAutoPurgeJob task, which removes deleted data from the Forums database. For more information about the TrashAutoPurgeJob task, see Purging forum trash. You can use the ForumsScheduler commands to pause and resume the TrashAutoPurgeJob task, and to retrieve information about the task. The scheduling information is contained in the forum-config.xml file. The SystemOut.log file also contains information about whether the scheduler is running and whether any scheduled tasks have started.

    To manage scheduled tasks for Forums, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Forums Jython script interpreter :

      execfile("forumsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands to administer the Forums scheduler service.

      ForumsScheduler.getTaskDetails(String taskName)

      Returns information about the scheduled task specified by taskName. Forums currently has a single managed task . TrashAutoPurgeJob.

      The values returned are server time, next scheduled run time, status (SCHEDULED, RUNNING, SUSPENDED), and task name. When the task has been paused, then the status parameter shows as SUSPENDED instead of SCHEDULED. SUSPENDED means that the task is not scheduled to run.

      For example:

      ForumsScheduler.getTaskDetails("TrashAutoPurgeJob")
      The resulting output looks similar to the following:

      {currentServerTime=Wed Feb 03 14:21:47 EST 2010, nextFireTime=Sun Feb 07 02:00:00 EST 2010, status=SCHEDULED, taskName=TrashAutoPurgeJob}

      ForumsScheduler.pauseSchedulingTask(String taskName)

      Temporarily pauses the specified task and stops it from running.

      When you pause a scheduled task, the task remains in the suspended state even after you stop and restart Forums or the IBM WebSphere Application Server. You need to run the ForumsScheduler.resumeSchedulingTask(String taskName) command to get the task running again.

      If the task is currently running, it continues to run but is not scheduled to run again. If the task is already suspended, this command has no effect.

      For example:

      ForumsScheduler.pauseSchedulingTask("TrashAutoPurgeJob")
      When a task is paused, a status message similar to the following is written to the SystemOut.log file:

      [2/3/10 14:28:10:782 EST] 0000002f ForumsNotific I   CLFWY0134I: Forums scheduled task 'TrashAutoPurgeJob' fired event 'TaskNotificationInfo.SUSPENDED'

      ForumsScheduler.resumeSchedulingTask(String taskName)

      If the task is suspended, puts the task in the scheduled state. If the task is not suspended, this command has no effect.

      When a task is resumed, it does not run immediately; it runs at the time when it is next scheduled to run.

      For example:

      ForumsScheduler.resumeSchedulingTask("TrashAutoPurgeJob")
      Resuming a paused task causes the following status message to be written to the SystemOut.log file:

      [2/3/10 14:28:25:407 EST] 00000051 ForumsNotific I   CLFWY0134I: Forums scheduled task 'TrashAutoPurgeJob' fired event 'TaskNotificationInfo.RESUMED'


    Related

  • Schedule tasks

  • Start the wsadmin client
  • Purging forum trash on a schedule

    Manage file attachments in Forums

    You can manage space on the Forums server by limiting the number of attachments that users can upload to a forum post. You can also edit configuration property settings in the forum-config.xml file to prevent your users from uploading file attachments.


    Set the maximum number of attachments

    Edit configuration property settings to configure the maximum number of files that can be uploaded to a single forum post.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. You can control space on the server by editing settings in the forum-config.xml file to limit the number of attachments that users can upload to a forum post.

    To configure the maximum number of attachments that can be uploaded to a single post.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Forums Jython script interpreter.

      1. Use the following command to access the Forums configuration files:

        execfile("forumsAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Check out the Forums configuration files :

        ForumsConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        ForumsConfigService.checkOutConfig("/opt/my_temp_dir", "ForumServerNode01Cell")

    3. Open the forum-config.xml file using a text editor.

    4. Edit the <max-number-attachment-per-post> element in the <objectStore> section of the file to set the maximum number of attachments that can be uploaded per post.

      For example, to set the maximum number of attachments per post to 6, you edit the file as follows:

      <objectStore>
      ...
         <max-number-attachment-per-post>6</max-number-attachment-per-post>
      ...
      </objectStore>

    5. Save your changes and close the forum-config.xml file.

    6. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Forums for information about how to save and apply your changes.


    Related tasks

  • Start the wsadmin client
  • Apply property changes in Forums


    Disable attachments

    Edit configuration property settings to prevent users from uploading file attachments to forums.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. By default, users can upload file attachments to forum topics, however you can disable this functionality by configuring a setting in the forum-config.xml file. If users have already uploaded file attachments to the Forums application and you subsequently disable this capability, the attachments are no longer visible in the user interface. The user interface options for adding and working with attachments are also hidden.

    To disable the upload of file attachments in Forums, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Forums Jython script interpreter.

      1. Use the following command to access the Forums configuration files:

        execfile("forumsAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Check out the Forums configuration files :

        ForumsConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        ForumsConfigService.checkOutConfig("/opt/my_temp_dir", "ForumServerNode01Cell")

    3. Open the forum-config.xml file using a text editor.

    4. Change the value specified for the <allow-upload> property from true to false as follows:

      <allow-upload>false</allow-upload>

    5. Save your changes and close the forum-config.xml file.

    6. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes for information about how to save and apply your changes.


    Related tasks

  • Start the wsadmin client
  • Apply property changes in Forums

    Enable forum topic posting in different deployments

    Enable users to take forum topics in one IBM Connections deployment, and post them to a different IBM Connections deployment.

    Users in IBM Connections can click Bookmark or Discuss This on any IBM Connections page to install a Discuss This button in their browser tool bar. When they click the button, the content of the current web or IBM Connections page is added to a forum topic. The user can then choose a forum they have access to, and add the topic to that forum.

    The discussThis configuration property allows you to enable a similar Discuss This button on every forum topic page. The button allows users to post the topic as a new topic in a forum in a different IBM Connections deployment which you specify in the discussThis.targetBookmarklet element.

    For example, you might have two IBM Connections deployments in your enterprise, A and B. You want users in deployment A forums to be able to post topics to deployment B forums. You would check out the forums-config.xml document in deployment A, and specify the server address where you can access the forums application in B. When a user opens a forum page in deployment A and clicks the Discuss This link, they can select the target forum on deployment B from the pop-up dialog. If the user is not logged into deployment B, they are prompted to log in before they can post the new topic. In order for the Discuss This link to display in the topic page, the user must be a member of the group that the discussThis-user J2EE role on deployment A is mapped to (the default is Everyone).

    1. On the Forums server in IBM Connections deployment A, check out forums-config.xml. See Changing Forums configuration property values.

    2. Run the following command in the wsadmin client to enable the feature:

      ForumsConfigService.updateConfig("discussThis", "true")

    3. Run the following command in the wsadmin client to specify the server address where you can access the forums application in deployment B:

      ForumsConfigService.updateConfig("discussThis.targetBookmarklet", "http://forums_appserver.enterprise.com:9081/connections/bookmarklet")

    4. Check in forums-config.xml.

    5. Restart the Forums application.


    Related tasks

  • Change Forums configuration property values

  • Roles

    Restrict forum topic editing to creators

    You can restrict the editing of forum topics or replies to their creators. Only someone who created the topic or reply can edit it.

    To restrict forum topic editing to creators check out LotusConnections-config.xml, open it in an editor and add some elements, and then check it back in. Then you must use a similar process to check out the forum-policy.xml file, open it in an editor and delete rows containing edit_all_post, and then check it back in.

    1. Start the wsadmin client :

      1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:

        app_server_root\profiles\dm_profile_root\bin

        ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on

        Windows:

        C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin

        You must run the following command to start the wsadmin client from this specific directory because the Jython files for the product are stored here. If you try to start the client from a different directory, then the execfile() command that you subsequently call to initialize the administration environment for an IBM Connections component does not work correctly.

      2. Enter the following command to start the wsadmin client:

        • AIX or Linux:

          ./wsadmin.sh -lang jython -user admin_user_id -password admin_password -port SOAP_CONNECTOR_ADDRESS Port

        • Microsoft

          Windows:

          wsadmin -lang jython -user admin_user_id -password admin_password -port SOAP_CONNECTOR_ADDRESS Port

        where:

        • admin_user_id is the user name of a person in the Administrator role on the IBM WebSphere Application Server.

        • admin_password is the password of the WebSphere Application Server administrator.

        • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. The default value of the SOAP port is 8879. If you are using the default port value, you do not need to specify this parameter. If you are not using the default and you do not know the port number, you can look up its value in the WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:

          1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.

          2. In the Additional properties section expand Ports, and then look for the SOAP_CONNECTOR_ADDRESS port entry to find the port number.

        For example:

        • AIX or Linux:

          ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879

        • Microsoft

          Windows:

          wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879

    2. Use the wsadmin client to access and check out the IBM Connections configuration files:

      1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

      2. Enter the following command to check out the IBM Connections configuration files:

        LCConfigService.checkOutConfig("working_directory","cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
        For example:

        • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")

        • Microsoft

          Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")

    3. Open LotusConnections-config.xml in an editor, and then add the following content:

      <properties>
      <genericProperty name="forceContentEditOnlyByCreator">true</genericProperty>
      </properties>

    4. Open LotusConnections-config.xml in a web browser to make sure you did not introduce any errors. XML files that are well formed display in a web browser; if there are errors, the web browser reports that an error was encountered. Fix an errors before proceeding.

    5. Check the configuration files back in during the same wsadmin session in which you checked them out.

      1. Update the value of the version stamp configuration property to force users' browsers to pick up this change. Enter the following command to increment the value of the versionStamp property: LCConfigService.updateConfig("versionStamp","gmt_timestamp") where gmt_timestamp is the GMT time. You can specify an empty string for the time stamp or provide a GMT value string. When you specify an empty string, the client calculates the current GMT time and updates the version stamp with that value. If you choose to provide the time, specify it using the following format: yyyyMMdd.HHmmss and specify the time in GMT. It is best to provide an empty string and let the client format the time stamp. For example: LCConfigService.updateConfig("versionStamp",""). See Required post-customization step for more details.

      2. To check in the changed configuration property files, use the following command:

        LCConfigService.checkInConfig()

      3. After making updates, type the following command to deploy the changes:

        synchAllNodes()

      4. Do not exit the wsadmin client.

    6. In the wsadmin client, check out the forum-policy.xml file following steps in the topic Editing configuration files.

    7. Open the forum-policy.xml file in an editor and delete any row containing edit_all_post.

    8. Check in the forum-policy.xml file following steps in the topic Editing configuration files.

    9. Stop and restart all of the IBM Connections application servers.


    Related tasks

  • Edit configuration files
  • Required post-customization step

    Administer the Home page

    You can administer site-wide settings for the Home page from the Home page administration user interface or using the wsadmin client.

    Home page administration information is contained in the widget catalog, which resides in the HOMEPAGE database. The catalog defines the widgets that have been deployed in the Home page. It also specifies whether the widgets are enabled or disabled, and sets out any prerequisites that the widgets have on IBM Connections applications. The catalog is administered using the Administration view in the Home page user interface. For more information about administering the widget catalog, see Administering the Home page from the user interface.

    You can also perform a number of administrative tasks for the Home page from the wsadmin client, for example, synchronizing member IDs between the Home page and the LDAP directory.


    Related

  • Manage users

    Administer the Home page from the user interface

    You can make site-wide changes to the Home page application directly from the Home page user interface.

    Users with the Home page administrator role have access to an additional Administration view on their Home page. When you are assigned this role, you can see an Administration option in the navigation sidebar, under the My Page option. Select this option to access a simple, form-based user interface that allows you to perform key tasks.

    From the Administration view you can:

    The Home page caches the XML descriptors of widgets in memory on startup. You can refresh the version of the XML descriptor cached in memory for a particular widget by selecting the widget from the Enabled widgets list in the Administration view and clicking Refresh cache. When you refresh the cache, the Home page fetches the latest version of the XML descriptor for the selected widget and updates the memory cache. This option is typically only used for third-party widgets at development time.

    Changes made using the administration user interface occur in real time and are immediately reflected in the Home page user interface.


    Administer Home page widgets

    You can extend the functionality of the Home page application by adding custom widgets and extend IBM Connections by adding OpenSocial gadgets. To make the widgets and gadgets available for use, you can add them from the Administration view and then enable them for use.

    The widgets that you add to the Home page can be based on the iWidget specification, which uses technology based on JavaScript, XML, HTML, and CSS, or the OpenSocial gadget specification. The widget files are stored on an HTTP server.

    The gadgets that you add to IBM Connections need to be based on the OpenSocial gadget specification, which enables you to surface gadgets in an OpenSocial container that can interact with an OAuth 2.0 protected service

    The widget files can be bundled as EAR applications and deployed on IBM WebSphere Application Server. They can also be hosted in LAMP, .NET, and other environments.

    You can add two types of third-party widget to the Home page:

    Opened by default

    This type of widget displays by default, but can be removed or hidden. It can also be moved to a different location. For example, the To Do List widget that displays in the Updates view is opened by default.

    Optional

    This type of widget is available for users to add to their Home page if they select it from the widget catalog. Optional widgets can be added, removed, hidden, or moved by Home page users.
    Any widget can be used as a default or optional widget.

    Third-party widgets can be added to the side column in the Updates view and to any column in the My Page view.


    Configure widgets for the Home page

    You can add widgets to the widget catalog to meet the needs of your users. Ensure that the widgets that you add to the catalog are from trusted sources. The widget catalog allows you to administer OpenSocial gadgets for the entire IBM Connections system including Embedded Experiences and Share Dialog gadgets as well as gadgets and iWidgets that are specific to the Home page.

    To add widgets via the Home page, you must be logged in as an administrator. If you do not see an Administration option display under the My Page option in the navigation sidebar on the Home page, this means that you are not configured as an administrator of the Home page application. See Configuring the Home page administrator for more details.

    If you wish to add gadgets deployed externally, such as iGoogle gadgets, you must configure locked domains. Locking domains isolates semi-trusted gadgets and prevents them from accessing SSO tokens or via DOM access to the parent page of the gadget iFrame that can be used to forward sensitive data to external sites. For more information on locked domains, refer to Enable locked domains.

    To add a widget to the widget catalog, complete the following steps:

    1. Open the Administration view.

    2. Click Add another widget to display the Add new widget form.

    3. Specify whether you are adding a widget that is based on the iWidget specification or the OpenSocial gadget specification. To allow users to be able to integrate applications such as Facebook, Twitter, and LinkedIn into their IBM Connections client experience, select OpenSocial gadget. Selecting OpenSocial gadget opens the Gadget settings with Activity stream or Share dialog subform, on which you need to specify the following additional options:

      1. For Security, select either a Trusted or a Restricted security type. Make your selection based on the following considerations:

        • Trusted gadgets can access a wider selection of container APIs and they can interact with IBM Connections data. Even though a gadget is marked as "trusted", its data access is still isolated from SSO data when used in combination with locked domains.

        • Select Use SSO token for trusted enterprise gadgets. Selecting this feature disables all of the security provided by locked domains for this particular gadget.

        • In general, gadgets should be written to utilize OAuth unless they are speaking to a "legacy" system that has not been OAuth enabled. For 4.0, all of the Connections APIs are now OAuth enabled. Currently SSO is not a standard OpenSocial feature, but specific to the Common Rendering Engine (CRE). Some IBM Containers, such as Notes® Social Edition, do not support the SSO feature at all at the time of this writing.

        • Restricted gadgets are limited in terms of the OpenSocial features. For example, they are not able to popup model dialogs. In general, you should always scope gadget feature access as narrowly as possible. Use this setting if the gadget does not require the additional page API features provided to trusted gadgets.

        You should not put any external (restricted) gadgets into IBM Connections if you have not configured locked domains.

      2. For UI integration points select

        ...where the gadget should be inserted in the user interface:Show in Share dialog or Show for Activity stream events or both.

        Your gadget will display after the IBM Connections gadgets in the Share dialog.

      3. Select the Server access via proxy preference as follows:

        • Only outside the intranet prevents the gadget from accessing your intranet servers. Unless specifically configured, the system will deem a server as part of the intranet if it is part of the WebSphere SSO domain. If this scoping is too narrow, it can be expanded via additional configuration settings.

        • All servers allows the gadget to access URLs in your intranet as well as outside it.

        • Custom rule defined for this gadget in the proxy-policy.dynamic file enforces settings defined in the policy file. For more information refer to Configuring per-host proxy access rules for OpenSocial gadgets.

      4. In the Service Mappings section, create a new mapping between an OAuth client, such as Facebook or Twitter, and its associated service, or edit or remove an existing mapping.

        OAuth clients must be pre-configured via wsadmin commands. This setting just manages the association of the clients with individual gadgets.

        1. Click Add Mapping to create a new mapping between an OAuth service and an OAuth client. In the fields that display, select an OAuth Client name and enter the associated Service Name.

        2. Select an existing mapping in the map list and then click Edit Mapping to update the mapping.

        3. Select an existing mapping in the map list and then click Delete Mapping to remove that mapping from the list.
        For more information about OAuth tokens, refer to Configure OAuth for custom gadgets.

    4. Enter a name for the widget in the Widget Title field.

    5. Enter a short description of the widget in the Description field.

    6. Enter the web address for the XML widget descriptor in the URL Address field. This address must be an absolute web address.

    7. Enter the widget location in the Secure URL Address field. This address must be an absolute web address.

    8. Enter the web address for an icon to associate with the widget in the Icon URL field. This image is used to represent the widget when it is docked in the widget palette.

    9. Enter the location of an icon to display for the widget in the Icon Secure URL field. This icon displays when the widget is docked in the content palette.

    10. Select Use IBM Connections specific tags to indicate if the widget deployment descriptor uses specific IBM Connections tags to represent the URLs of the IBM Connections applications.

    11. To display the widget in the My Page view, select Display in the My Page view. You must display the widget in the My Page view or the Updates view, or both.

    12. To display the widget in the Updates view, select Display in the Updates view. You must display the widget in the My Page view or the Updates view, or both.

    13. To display the widget when users open the Home page for the first time, select Opened by default. The widget will not display for existing users, but it will be available from the widget palette so that they can add it whenever they want.

    14. To enable multiple instances of the widget to be used, select Multiple widgets. Each widget instance has its own properties, which can be useful. For example, if you are using a widget that displays bookmarks for a specific tag, you might want to enable multiple instances of the widget so that you can follow different tags in each widget.

      This setting is only applicable for iWidgets. Only one instance of an OpenSocial gadget may be loaded at a time.

    15. If there are specific IBM Connections applications that must be included in your deployment for the widget to function correctly, select the required applications in the Prerequisites area.

      When an IBM Connections application is selected as a prerequisite but that application is not installed, the widget does not display on the Home page. For gadgets that declare dependencies this way, they will act as though they are "disabled" for the purposes of whitelisting if all of their dependencies are not met.

    16. Click Save.


    What to do next

    If you are adding widgets that are hosted on third-party servers, then you might need to update your proxy configuration. For more information on configuring the Ajax proxy, see Configuring the AJAX proxy for a specific application.


    Enable Home page widgets

    You need to enable widgets before they can display on the Home page or elsewhere in IBM Connections. The Home page administration user interface lists the current status of widgets in the widgets catalog, and allows you to enable and disable widgets as needed. All changes made in the user interface, including enabling and disabling widgets, take immediate effect without the need for application restart.

    To change a widget's status to enabled, complete the following steps.

    1. Open the Administration view.

    2. In the Disabled widgets area, select the widget to enable and click Enable.


    Disable Home page widgets

    You can disable widgets from displaying on the Home page or elsewhere in IBM Connections when you no longer want them to be available to your users. Set a widget's status to disabled means that it no longer displays on the Home page. The Home page administration user interface lists the current status of widgets in the widget catalog, and allows the administrator to enable and disable widgets as needed. All changes made in the user interface, including enabling and disabling widgets, take immediate effect without the need for application restart.

    To change a widget's status to disabled, complete the following steps.

    1. Open the Administration view.

    2. In the Enabled widgets area, select the widget to disable and click Disable.


    Edit Home page widgets

    Edit a widget to change its name, description, or deployment descriptor. You can edit a widget to update the icon associated with the widget when it is docked, specify whether the widget deployment descriptor uses particular IBM Connections tags to represent the URLs of IBM Connections applications, and select IBM Connections applications as prerequisites for the widget.

    For system widgets that are installed as part of IBM Connections, you can only change the name of the widget.

    To edit a widget.

    1. Open the Administration view.

    2. Select the widget to edit and click Edit.

    3. Make the necessary changes in the Edit widget form and then click Save.


    Remove Home page widgets

    If a third-party widget is no longer used or needed, you can remove it from the widget catalog. You cannot remove IBM Connections widgets from the catalog, you can only disable them.

    To remove a third-party widget from the widget catalog, complete the following steps.

    1. Open the Administration page.

    2. Select the widget to remove, and then click Remove.


    Enable and disable the My Page view

    You can control whether the My Page view is available to your users by enabling or disabling it from the Administration view. When you install IBM Connections, the My Page view is disabled by default. If you have migrated from a previous version of the product, the view is enabled by default. You can override the default setting from the Administration view.

    To enable or disable the My Page view, complete the following steps:

    1. Open the Administration view.

    2. Select Enabled or Disabled from the The Widget page is currently list, and then click Save.

    Administer the Home page using the wsadmin client

    Although most of the Home page administration tasks are performed using the Home page user interface, there are some administrative functions that you must perform using the wsadmin client.

    For example, you can use wsadmin commands to access the configuration files for the Get Started wizard and force the Get Started view to be the default view for Home page users.


    Related

  • Synchronize user data using administrative commands

  • Start the wsadmin client
  • Customize the Get Started view

  • Administer Blogs using the wsadmin Client


    Home page administrative commands

    Use the commands listed to perform administrative tasks for the Home page application.

    The following sections define the commands that you can use when working with the Home page. Each section describes the commands for a specific service. The commands are listed in alphabetical order.


    HomepageCellConfig commands

    HomepageCellConfig.checkInGetstartedConfig("working_directory", "cell_name")

    Checks in the configuration files for the Get Started wizard

    ...where the working_directory and cell_name parameters contain the same values you specified for the checkout location. See the description for the HomepageCellConfig.checkOutGetstartedConfig command for more information.

    HomepageCellConfig.checkOutGetstartedConfig("working_directory","cell_name")

    Checks out the configuration files for the Get Started wizard where:

    • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

      AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

    • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

      print AdminControl.getCell()
    For example:

    • AIX/Linux:

      HomepageCellConfig.checkOutGetstartedConfig("/opt/act/temp","foo01Cell01")

    • Microsoft

      Windows:

      HomepageCellConfig.checkOutGetstartedConfig("c:/act/temp","foo01Cell01")


    HomepagePersonService commands

    HomepagePersonService.resetWelcomeFlagAllMembers()

    Forces the Get Started view to be the default Home page view for all users.

    HomepagePersonService.resetWelcomeFlagMemberByEmail(String email)

    Forces the Get Started view to be the default Home page view for the user specified by email address.

    For example:

    HomepagePersonService.resetWelcomeFlagMemberByEmail("jsmith@example.com")

    HomepagePersonService.resetWelcomeFlagMemberByLoginName(String loginName)

    Forces the Get Started view to be the default Home page view for the user specified by login name.

    For example:

    HomepagePersonService.resetWelcomeFlagMemberByLoginName("Joe Smith")

    HomepagePersonService.resetWelcomeFlagBatchMembersByEmail(String fileName)

    Forces the Get Started view to be the default Home page view for the users listed in the specified text file. Define the people by adding one person's email per line.

    For example:

    HomepagePersonService.resetWelcomeFlagBatchMembersByEmail("/opt/Homepage/emails.txt")

    HomepagePersonService.resetWelcomeFlagBatchMembersByLoginName(String fileName)

    Forces the Get Started view to be the default Home page view for the users listed in the specified text file. Define the people by adding one person's login name per line.

    For example:

    HomepagePersonService.resetWelcomeFlagBatchMembersByLoginName("/opt/Homepage/logins.txt")


    Related

  • Synchronize user data using administrative commands

  • Forcing the Get Started view to be the default Home page view
  • Customize the Get Started view


    Forcing the Get Started view to be the default Home page view

    Use an administrative command, you can force the Get Started view to be the default view for all users or a subset of users.

    To use administrative commands, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. When you first open the Home page, the Get Started view is displayed by default. Users can select a check box in the Get Started view to prevent it from being displayed each time they log in. However, you can use an administrative command to force it to be the default view for all users or for a subset of users. You might want to set this view as the default if, for example, you added an important enterprise-wide message to the page that you want people to read.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Home page Jython script interpreter.

      1. Use the following command to access the Home page configuration files.

        execfile("homepageAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use one of the following commands to force the Get Started view to be displayed for the specified users:

      HomepagePersonService.resetWelcomeFlagAllMembers()

      Forces the Get Started view to be the default Home page view for all users.

      HomepagePersonService.resetWelcomeFlagMemberByEmail(String email)

      Forces the Get Started view to be the default Home page view for the user specified by email address.

      For example:

      HomepagePersonService.resetWelcomeFlagMemberByEmail("jsmith@example.com")

      HomepagePersonService.resetWelcomeFlagMemberByLoginName(String loginName)

      Forces the Get Started view to be the default Home page view for the user specified by login name.

      For example:

      HomepagePersonService.resetWelcomeFlagMemberByLoginName("Joe Smith")

      HomepagePersonService.resetWelcomeFlagBatchMembersByEmail(String fileName)

      Forces the Get Started view to be the default Home page view for the users listed in the specified text file. Define the people by adding one person's email per line.

      For example:

      HomepagePersonService.resetWelcomeFlagBatchMembersByEmail("/opt/Homepage/emails.txt")

      HomepagePersonService.resetWelcomeFlagBatchMembersByLoginName(String fileName)

      Forces the Get Started view to be the default Home page view for the users listed in the specified text file. Define the people by adding one person's login name per line.

      For example:

      HomepagePersonService.resetWelcomeFlagBatchMembersByLoginName("/opt/Homepage/logins.txt")


    Related tasks

  • Customize the Get Started view

  • Home page administrative commands

    Administer Metrics

    Administer metrics in IBM Connections by modifying configuration settings, backing up data, and running commands to perform maintenance tasks.


    About this task

    IBM Connections provides vital metrics about your deployment. Metrics are presented simply, using charts that provide clear business value to users, executives, and administrators. IBM Connections metrics are supported by IBM Cognos® Business Intelligence, which you install as part of the Connections deployment. IBM Connections application events, such as reading or creating objects, generate metrics that are stored in a database, which synchronizes with a Cognos PowerCube to store data so it can be accessed along different dimensions. When a Connections user runs a Metrics report, the Cognos server sends the data to the IBM Connections metrics interface.

    Authorized users can work with the charts interactively, filtering data by parameters such as geography and time period, and drilling down into data points for more detail. The Connections administrator can customize reports using a suite of Cognos tools. Refer to the Cognos documentation for detailed information on customizing reports as well as administering the PowerCube as well as the Cognos server.

    What are metrics?

    The new Metrics application in IBM Connections provides a comprehensive set of quantitative (measures) and qualitative (descriptions) metrics that help measure the business value of IBM Connections in your organization. Connections uses IBM Cognos Business Intelligence to collect and maintain metrics, and to generate reports that users can view directly in Connections. Metrics reports can be presented as tables or charts that you refine by selecting options such as the time period to report on, a particular application to focus on, and how to group users in the results.

    Statistics related to the Search application are not collected or reported by the Metrics application. For information on search statistics, see Viewing and collecting Search metrics.

    Connections provides metrics on two levels, global and community. Global metrics report on overall usage (all users across all applications); for example, the total number of people who logged into Connections last week. Global metrics are updated on a daily basis; refreshes are typically scheduled during off-peak hours to avoid degrading system performance for users.

    Community metrics report on a particular community; for example, the number of people who logged into the Sales community last week. Community metrics are generated on demand and are then cached until a new report is requested. Requests are place into a queue and are processed in order. After submitting a request to update metrics, the community owner can work in other areas and return when the report is ready for viewing.

    The Connections administrator has implicit access to all metrics reports. Community owners can view metrics for their own community, but cannot view global metrics. Additional users who require the information can be authorized to view global metrics; for example, a high-level manager might require access to metrics for business purposes even if he or she does not manage a community.

    The Metrics application comprises the following components.

    Event tracker

    The event tracker records user actions in Connections; for example, an event is created every time a Connections user reads a blog entry, creates a "To do" item in an activity, updates a wiki page, or follows a community. These events are then used to calculate various metrics based on their timing and frequency.

    Database

    Event data is stored in database tables and includes information about each event, such as the user who performed an action, the data that was acted upon, the date the event occurred, and the Connections application that was affected. Connections requires two DBs for managing metrics data: the Cognos Content Store database contains data needed for managing the Cognos Business Intelligence components that provide the metrics collection and reporting tools, and the Metrics database contains the raw event-related data.

    PowerCube

    Cognos Business Intelligence uses a cube to store metrics information for analysis. A cube is a data structure in which data is stored across multiple categories, or dimensions. The Metrics PowerCube is generated by the Cognos Transformer application. The PowerCube uses OLAP (online analytical processing) techniques for quickly analyzing a measure across multiple dimensions; for example to count user logins across multiple Connections applications during a specified period of time. Pre-aggregating the data for each measure across the available dimensions enables the PowerCube to respond quickly to queries so that reports can be produced in a timely manner.

    The PowerCube is based on the metrics model, which is a business-oriented representation of the information from the metrics cube datasource that includes the dimensional metadata and measures. The metrics cube datasource is a Cognos package that defines the queries that retrieve data from the PowerCube.

    Reports

    A report is a summary of the data provided by the PowerCube in response to a particular query. Reports can be scheduled to run automatically at specified times, and are presented to the user as tables, charts, or other types of graphs. When you deploy IBM Connections, a predefined set of reports is immediately available for use. You can additionally create custom reports to suit your organization.s needs.

    Reports are designed with three standard filters that categorize data in the displays:

    • The applications filter groups data for a specific application scope, either across Connections or within a particular community; for example to view only blogs owned by the Customer Support community.

    • The time range filter groups allows a report to focus on a particular period of time by including only data for one of the following predefined intervals:

      1. Last 7 days

      2. Last 4 weeks

      3. Last quarter

      4. Last 12 months

      5. All years

    • The user attribute filter groups data about people based on predefined user profile attributes (geography, department, and role). For information on customizing the user attribute filter for your organization.s reports, see Map Metrics report dimensions to user profile attributes.

    User interface

    Connections provides a user interface for displaying reports. When viewing reports, authorized users can apply filters to collect and categorize data, drill down on data points to see more detail, and save a copy of the report.

    The Metrics event-tracking component captures events from IBM Connections, such as viewing a blog entry, replying to a forum topic, uploading a file, or updating wiki page. Events are stored in the raw Metrics database. A scheduled job runs the Cognos Transformer application to retrieve data from the raw Metrics database and generate the PowerCube. When a user accesses the Metrics user interface in IBM Connections, the Cognos Business Intelligence application generates metrics reports by querying the PowerCube.

    Manage the Metrics environment

    You can manage the Metrics environment by modifying configuration settings and running administrative commands that determine how Metrics data is collected and reported.

    Manage the metrics environment by using the wsadmin client to specify settings in a configuration file or to run administrative commands.

    The configuration file contains settings that control when and how Metrics operations are performed. When you make configuration changes, you use scripts to check out the Metrics configuration file, modify settings, and then check the file back in. A server restart is required for your changes to take effect.

    Administrative commands perform tasks that manipulate Metrics content, change member access levels and synchronize member IDs, and manage scheduled tasks in Metrics.


    Manage the scheduled tasks for Metrics

    Use administrative commands to manage scheduled tasks in Metrics.

    To run administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Metrics uses the IBM WebSphere Application Server scheduling service for performing regular managed tasks. For more information about how the scheduler works, see Schedule tasks.

    To manage a task:

    1. Start the Metrics Jython script interpreter.

      1. Access the Metrics configuration file:

        execfile("metricsAdmin.py")

        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node.

        If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    2. Use the following commands to administer the Metrics scheduler service.

      • MetricsSchedulerService.getTaskDetails(java.lang.String taskName)

        Returns information about the scheduled task specified by taskName. Specify one of the following jobs:

        • "ReportGenerator"

        • "MetricsDBCleanup"

        • "DataSynchronization"

        The values returned are server time, next scheduled run time, status (SCHEDULED, RUNNING, SUSPENDED), and task name. When the task has been paused, then the status parameter shows as SUSPENDED instead of SCHEDULED. SUSPENDED means that the task is not scheduled to run.

        For example:

        MetricsSchedulerService.getTaskDetails("ReportGenerator")

        returns output similar to the following:

        {currentServerTime=Fri Jan 22 14:13:52 EST 2010, nextFireTime=
        Fri Jan 22 14:21:00 EST 2010, status=SCHEDULED, taskName=ReportGenerator}

      • MetricsSchedulerService.pauseSchedulingTask(java.lang.String taskName)

        Temporarily pauses the specified task and stops it from running.

        When you pause a scheduled task, the task remains in the suspended state even after you stop and restart Metrics or the IBM WebSphere Application Server. You must run the MetricsScheduler.resumeSchedulingTask(String taskName) command to get the task running again.

        If the task is currently running, it continues to run but is not scheduled to run again. If the task is already suspended, this command has no effect.

        For example:

        MetricsSchedulerService.pauseSchedulingTask("ReportGenerator")

        returns output similar to the following:

        ReportGenerator paused

      • MetricsSchedulerService.resumeSchedulingTask(java.lang.String taskName)

        If the task is suspended, puts the task in the scheduled state. If the task is not suspended, this command has no effect.

        When a task is resumed, it does not run immediately; it runs at the time when it is next scheduled to run.

        For example:

        MetricsSchedulerService.resumeSchedulingTask("ReportGenerator")

        returns output similar to the following:

        ReportGenerator resumed


    Manage Metrics configurations

    You can modify configuration settings to control how the Metrics application behaves. You can also use the configuration information to map user profile attributes to report dimensions.


    Modify configuration properties

    Configuration settings control how and when various Metrics operations take place. You can edit the settings to change the way the Metrics application behaves by modifying configuration properties.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool.

    Configure Metrics using scripts accessed with the wsadmin client. These scripts use the AdminConfig object, available in the WebSphere Application Server wsadmin client, to modify the Metrics configuration file. Changes to Metrics configuration settings require node synchronization and a restart of the Metrics server before they take effect.

    To edit Metrics configuration properties, complete the following steps:

    1. Start the wsadmin client.

    2. Start the Metrics Jython script interpreter.

      1. Access the Metrics configuration file:

        execfile("metricsAdmin.py")

        If you are asked to select a server, you can select any server.

      2. Check out the Metrics configuration files :

        MetricsConfigService.checkOutConfig("working_directory", "cell_name")

        where

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

          For example:

          MetricsConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view a list of the valid Metrics configuration settings and their current values, use the following command: MetricsConfigService.showConfig()

      Here is some sample output from the MetricsConfigService.showConfig() command:

      Metrics configuration properties:
             cognos.namespace = IBMConnections
             cognos.secsPerRequest = 1200
             communitiesMetricsDateRange.all.enabled = true
             communitiesMetricsDateRange.last12months.enabled = true
             communitiesMetricsDateRange.last4weeks.enabled = true
             communitiesMetricsDateRange.last7days.enabled = false
             communitiesMetricsDateRange.lastquarter.enabled = true
             db.dialect = DB2

      Only properties in metrics-config.xml are printed by the MetricsConfigService.showConfig() command. Configurations of custom reports are not listed.

    4. Modify configuration properties using the appropriate method:

      • Some Metrics configuration properties can be edited using the wsadmin client:

        MetricsConfigService.updateConfig("property", "value")

        where property is one of the editable Metrics configuration properties and value is the new value with which you want to set that property. For example:

        MetricsConfigService.updateConfig("communitiesMetricsDateRange.last7days.enabled", "false")

      • Properties that are not listed as being editable with the wsadmin client can be edited directly in the configuration file: open the file in a text editor, and then make your changes.

    5. Check in the changed configuration property keys using the following wsadmin client command: MetricsConfigService.checkInConfig()

    6. Update the value of the version stamp configuration property in LotusConnections-config.xml to force browsers to pick up this change.

      See Required post-customization step for more details.

    7. Exit the wsadmin client by running the exit command.

    8. Restart the server to apply your changes.


    What to do next

    After updating the Metrics properties with new values, you can use the MetricsConfigService.showConfig() command to display the list of properties and their updated values.


    Metrics configuration properties

    Configuration properties control how and when various Metrics operations occur and help optimize performance.

    You can modify the following configuration properties in the metrics-config.xml file. After making changes to the file, restart the server to implement the changes.

    Restriction: Note the following restrictions on the values allowed in the file:

    • All configuration properties, except those with multiple values, are required.

    • .enabled properties must have boolean values of either true or false.

    • Number values must be integers.

    communitiesMetricsDateRanges group

    Five configuration properties that specify the scope of date ranges against which community metrics static reports should be generated. Generating reports for all 5 date ranges can be time consuming. You can reduce report generation time by disabling one or more date ranges. A disabled date range is not displayed in the community metrics application. The 5 date ranges properties specify the last 7 days, last 4 weeks, last quarter, last 12 months, and all years.

    • communitiesMetricsDateRange.last7days.enabled

    • communitiesMetricsDateRange.last4weeks.enabled

    • communitiesMetricsDateRange.lastquarter.enabled

    • communitiesMetricsDateRange.last12months.enabled

    • communitiesMetricsDateRange.all.enabled

    scheduledTasks group

    Properties for the three scheduler tasks used by Metrics. Each task has two properties, "enabled" and "interval". "enabled" determines whether the task is run or not. If the value is false, the task is still registered, but does not run. "interval" specifies the task schedule. To get more information on how to configure the scheduler tasks, See Manage the scheduler.

    • scheduledTasks.ReportGenerator.enabled

    • scheduledTasks.ReportGenerator.interval

    • scheduledTasks.MetricsDBCleanup.enabled

    • scheduledTasks.MetricsDBCleanup.interval

    • scheduledTasks.DataSynchronization.enabled

    • scheduledTasks.DataSynchronization.interval

    db.dialect

    Reflects the current database type, typically specified during installation.

    Valid values include DB2, Oracle, or SQL Server.

    UserAttributesMappings group

    Contains three configuration properties that define the mapping relationship between the user attribute filters used in Metrics and user properties in Profiles.

    • userAttributesMappings.attribute1

    • userAttributesMappings.attribute2

    • userAttributesMappings.attribute3
    Metrics supports up to three report dimensions that are based on user attributes defined in Profiles. By default, the three dimensions are Geography, Department, and Role. You can redefine them by mapping the preceding attributes to other available attributes in Profiles. For more information, see Map user profile attributes to report dimensions.

    eventLifetimeInMonths

    Number of months from the date a metrics event is created until it is removed from the database. Metrics events are periodically removed from the database. You can change this value based on your database's capacity.

    The value must be greater than 0.

    privacy.displayReportWithUserName

    User names are not displayed in all reports if this configuration is set to "false".

    By default, the value is "true". Valid values are "true" and "false".

    cognos.namespace

    Specifies the authentication namespace ID configured during IBM Cognos Business Intelligence installation. The authentication namespace defines a group of properties that allows Cognos to access an LDAP for user authentication.

    Must be the same as what you defined in the Cognos configuration. Otherwise, you might have authentication issues when accessing Metrics.

    cognos.secsPerRequest

    Specifies the estimated time to generate a whole set of reports for a community. This value is used when Metrics calculates the estimated finish time of Community Metrics report generation. Be default, the value is 1200, which is measured on a normal two-CPU server. You can change this value based on the capacity of your server.

    The value must be in seconds and must be greater than 0.


    Map user profile attributes to report dimensions

    Edit Metrics configuration files to map various user profile attributes to Metrics report dimensions.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool.

    Metrics reports support up to three different dimensions. The dimensions are based on user profile attributes, such as "com.ibm.snx_profiles.base.title", which specifies the user role. By default, the three attributes are:

    com.ibm.snx_profiles.base.countryCode

    Mapped to the "Geography" dimension in Metrics reports

    com.ibm.snx_profiles.base.orgId

    Mapped to the "Department" dimension in Metrics reports

    com.ibm.snx_profiles.base.title

    Mapped to the "Role" dimension in Metrics reports

    To get the full list of Profiles attributes through the administration ATOM API provided by Profiles, refer to Retrieve the Profiles Administration API service document in the IBM Social Business wiki.

    The following Profiles attributes contain codes instead of real values:

    • com.ibm.snx_profiles.base.deptNumber

    • com.ibm.snx_profiles.base.countryCode

    • com.ibm.snx_profiles.base.orgId

    • com.ibm.snx_profiles.base.employeeTypeCode

    • com.ibm.snx_profiles.base.workLocationCode

    If any of these attributes are used, Metrics shows real values in the reports.

    To manage a task, complete the following steps:

    1. Start the Metrics Jython script interpreter.

      1. Access the Metrics configuration file:

        execfile("metricsAdmin.py")

        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node.

    2. Use the following command to check out the Metrics configuration file metrics.xml:

      MetricsConfigService.checkOutConfig("working_directory", "cell_name")

    3. Modify metrics-config.xml directly or use MetricsConfigService.updateConfig() to update the Profiles attributes mappings.

    4. Use the following command to check in the Metrics configuration file metrics.xml:

      MetricsConfigService.checkInConfig()

    5. Define names for customized attributes with customized product strings. Set new values for the following properties in Metrics properties file com.ibm.connections.metrics.ui.strings.ui_xx.properties,

      ...where xx is the language identifier in metrics.ear/lc.metrics.ui.jar:

      • METRICS.FILTER.DIMENSION.OPTIONS.ATTRIBUTE1

      • METRICS.FILTER.DIMENSION.OPTIONS.ATTRIBUTE2

      • METRICS.FILTER.DIMENSION.OPTIONS.ATTRIBUTE3

      See Customize product strings for more details.

    6. Save all changes and restart the server on which Metrics is deployed.


    Run Metrics administrative commands

    Use administrative commands from the wsadmin command line to directly interact with Metrics.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Administrative commands interact with the Metrics application and its resources through scripts. These scripts use the AdminControl object available in the IBM WebSphere Application Server wsadmin tool to interact with the Metrics server. Each script uses managed Java beans (MBeans) to get and set server administration properties. You do not need to check out files before running administrative commands, and you do not need to restart the server for the commands to take effect.

    See Metrics administrative commands for a complete list of other administrative commands for the Metrics application.

    To run Metrics administrative commands, complete the following steps:

    1. Start the wsadmin client.

    2. Start the Metrics Jython script interpreter.

    3. Access the Metrics configuration file: execfile("metricsAdmin.py") If an error occurs when you are executing the commands, examine the SystemOut.log file to determine the error.


    Metrics administrative commands

    You can manage the Metrics services by using the wsadmin client to perform administrative commands that allow you to check files in and out and modify settings. Administrative commands do not require a server restart to take effect.

    You must use the wsadmin client to run administrative commands. For information, see Starting the wsadmin client.

    Each section describes the commands for a specific service.


    MetricsConfigService

    • MetricsConfigService.checkOutConfig("working_directory", "cell_name")

      Checks Metrics configuration files out to a temporary directory. Run from the wsadmin command processor.

      working_directory

      Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

      cell_name

      Name of the WebSphere Application Server cell hosting the application. If you do not know the cell name, type the following command in the wsadmin command processor:

      print AdminControl.getCell()

      For example:

      • IBM AIX or Linux: MetricsConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

      • Microsoft

        Windows: MetricsConfigService.checkOutConfig("c:/temp","foo01Cell01")

    • MetricsConfigService.showConfig()

      Displays the current configuration settings. You must check out the configuration files with MetricsConfigService.checkOutConfig() before running MetricsConfigService.showConfig().

    • MetricsConfigService.updateConfig("quick_config_property", "new_value")

      Updates configuration properties.

      quick_config_property

      Property in the metrics-config.xml configuration file expressed as a quick config command. For example, the quick config value for following property:

      <databaseCleanup>
          <eventLifetimeInMonths>12</eventLifetimeInMonths>
      </databaseCleanup>
      is eventLifetimeInMonths. See Metrics configuration properties for configuration properties and descriptions.

      new_value

      The new value for the property. Property values can be restricted, for example, to either true or false. e Metrics configuration properties for configuration properties and descriptions.

      For example, to set the scheduledTasks.ReportGenerator.enabled property to false, use the following command:

      MetricsConfigService.updateConfig("scheduledTasks.ReportGenerator.enabled", "false")

    • MetricsConfigService.checkInConfig()

      Checks in Metrics configuration files. Run from the wsadmin command processor.


    MetricsMemberService

    • MetricsMemberService.syncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"] } )

    • MetricsMemberService.syncMemberByExtId("currentExternalId"[, {"newExtId" : "id-string" [, "allowExtIdSwap" : ["true" | "false"] ] } ] )

    • MetricsMemberService.inactivateMemberByEmail("email")

    • MetricsMemberService.inactivateMemberByExtId("externalID")

    • MetricsMemberService.getMemberExtIdByEmail("email")

    • MetricsMemberService.getMemberExtIdByLogin("login")

    • MetricsMemberService.syncBatchMemberExtIdsByEmail("emailFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    • MetricsMemberService.syncBatchMemberExtIdsByLogin("loginFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    • MetricsMemberService.syncMemberExtIdByEmail("email" [, { "allowInactivate" : ["true" | "false"] } ])

    • MetricsMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate": ["true" | "false"] } ])

    See Synchronize user data using administrative commands for details.


    MetricsUsersService

    MetricsUsersService.reloadUsersAttributes()

    Synchronize user information with Profiles immediately.

    User synchronization runs periodically by the "DataSynchronization" scheduler task to get detailed information of users captured in Metrics raw data.

    By default, user synchronization runs daily. Use MetricsUsersService.reloadUsersAttributes() if you want to run synchronization ahead of the scheduled time.


    MetricsSchedulerService

    • MetricsSchedulerService.pauseSchedulingTask(string taskName) 

      Suspends scheduling of a task. This has no effect on currently running tasks. Paused tasks remain paused until you explicitly resume them, even if the server is stopped and restarted.

      taskName

      A string value containing one of the following:

      • ReportGenerator

      • MetricsDBCleanup

      • DataSynchronization
      For example: MetricsSchedulerService.pauseSchedulingTask("ReportGenerator")

    • MetricsSchedulerService.resumeSchedulingTask(string taskName) 

      Resumes the start of a paused task.

      taskName

      A string value containing one of the following:

      • ReportGenerator

      • MetricsDBCleanup

      • DataSynchronization
      For example: MetricsSchedulerService.resumeSchedulingTask("ReportGenerator")

    • MetricsSchedulerService.forceTaskExecution(string taskName string executeSynchronously) 

      Runs a task.

      Property settings in the metrics-config.xml configuration properties file specify whether tasks are enabled to run automatically, and how often. This command allows you to run tasks manually, for example, if you disabled a task but want to run it at specified times.

      taskName

      A string value containing one of the following:

      • ReportGenerator

      • MetricsDBCleanup

      • DataSynchronization

      executeSynchronously

      Takes the string values true or false. Specifying this value is optional, and the default value is false. If this value is false, then the task executes asynchronously, meaning that if the taskId is valid, the command returns immediately and execution continues in the background. If this value is true, the command does not return until the task completes. For example: MetricsSchedulerService.forceTaskExecution("ReportGenerator")

    • MetricsSchedulerService.getTaskDetails(string taskName)

      Displays the status of a task and returns a detailed status message.

      taskName

      A string value containing one of the following:

      • ReportGenerator

      • MetricsDBCleanup

      • DataSynchronization
      For example: MetricsSchedulerService.getTaskDetails("ReportGenerator")

    Update the Cognos server with fix packs

    Apply available fix packs to the Cognos Business Intelligence server to provide important product corrections.

    You should check with IBM Fix Central periodically in case additional fix packs were made available after this documentation was published. Download the latest fix pack and apply it to the Cognos server. Fix packs are cumulative; when you install the latest fix pack, it includes updates from all previous fix packs.

    For additional information on updating Cognos Business Intelligence with fix packs, see Install Fix Packs in the Cognos information center.

    1. Stop IBM WebSphere Application Server and verify that all Cognos services have stopped before proceeding to the next step.

      After stopping the server, wait at least 1 full minute to ensure that all Cognos processes have stopped:

      • IBM AIX or Linux: cgsServer.sh and CAM_LPSvr processes

      • Microsoft

        Windows: cgsLauncher.exe and CAM_LPSvr processes

    2. Download fix packs for Cognos Business Intelligence from IBM Fix Central.

      1. Review the fix pack prerequisites and make sure your deployment satisfies all requirements.

      2. Download the appropriate compressed tar file for your operating system using the links in the "Download Package" section.

        Some browsers might change a downloaded file.s type from .tar.gz to a file type not recognized by the operating system. To correct this, change the file type back to .tar.gz after the download is complete. Using Download Director will prevent inadvertent renaming of files at download.

    3. Expand the downloaded fix pack.

      AIX or Linux

      1. Open command prompt or terminal window.

      2. Change to the directory where you have downloaded the fix pack.

      3. Run the following command to expand the package using either GNU Zip (gzip) or GNU Tar (tar):

        gunzip fix_pack_file_name.tar.gz | tar xvf . 

      Windows

      1. Open a command prompt.

      2. Change to the directory where you have downloaded the fix pack.

      3. Expand the package using your file compress and decompress utility (if you are using WinZip, select the option "Use folder names" to retain the package.s folder structure).

    4. Apply the fix pack:

      AIX or Linux:

      1. Change to the directory where you expanded the fix pack.

      2. Now change to the following subdirectory:

        • AIX: /aix64h

        • Linux: /linuxi38664h

        • zLinux: /zlinux64h

      3. Run the following command: ./issetup

        If you do not use XWindow, run an unattended installation as explained in Set Up an Unattended Installation Using a File From an Installation on Another Computer in the Cognos information center.

      4. Follow the instructions in the installation wizard, install the fix pack in the same location as your existing IBM Cognos components.

        This installation location is the path specified for the cognos.biserver.install.path property in the cognos-setup.properties file.

      Windows:

      1. Change to the directory where you expanded the fix pack.

      2. Now change to the \win64h subdirectory.

      3. Run the following command: issetup.exe

      4. Follow the instructions in the installation wizard, install the fix pack in the same location as your existing IBM Cognos components.

        This installation location is the path specified for the cognos.biserver.install.path property in the cognos-setup.properties file.

    5. Generate a new Cognos BI Server EAR file with the fix pack:

      1. Locate the cognos-setup-update.sh|bat script in the directory where you expanded the CognosConfig.zip or CognosConfig.tar when you installed Cognos Business Intelligence components as part of the pre-install task.

      2. Edit the cognos-setup.properties file and verify that it contains the appropriate values for each property.

        All passwords were removed from this file the last time it was used, so you must either add the passwords again, or pass them in from the command line when you run the cognos-setup-update.sh|bat script.

      3. Run the cognos-setup-update.sh|bat script.

    6. Apply the new EAR file to the Cognos server by running an update in the WebSphere Integrated Solutions Console:

      1. On the server where Cognos BI Server is installed, start WebSphere Application Server.

      2. Log in to the Integrated Solutions Console as the WebSphere administrator.

      3. Click Servers > Enterprise Applications.

      4. In the list of applications, select the Cognos where you generated the new EAR file, and click the Update button in the table.

      5. Browse to the newly built EAR file residing in the Cognos_BI_Server_install_path directory, and click Next.

      6. Complete the remaining screens by accepting the default values and clicking Next.

      7. Click Finish to complete the update.

    7. Enable anonymous access to the Cognos server:

      When you initially configured the Cognos server after installation, you disabled anonymous access to the server while Configure support for LDAP authentication for Cognos Business Intelligence; however the script that updates the configuration requires that anonymous access be enabled. There are two ways to enable anonymous access. You can run the Cognos Configuration tool or, if your Cognos server runs on AIX or Linux and does not provide a graphical user interface, you can enable anonymous access manually.

      Enable anonymous access with the Cognos Configuration tool:

      1. Navigate to the /bin directory within the Cognos BI Server installation directory:

        For example:

        • AIX or Linux: /opt/IBM/Cognos64/bin/

        • Windows: C:\Program Files\IBM\Cognos\bin

      2. Start the Cognos Configuration tool by running the following command:

        • AIX or Linux: ./cogconfig.sh

        • Windows: cogconfig.bat

      3. Expand Local Configuration > Security > Authentication > Cognos and set Allow anonymous access? to True.

      4. Exit the Cognos Configuration tool, making sure to select No at the following prompt: The service 'IBM Cognos' is not running on the local computer. Before you can use it your computer must start the service. Do you want to start this service before exiting?

      5. Restart WebSphere Application Server.

      Enable anonymous access manually:

      1. Navigate to the /configuration directory within the Cognos BI Server installation directory:

        For example:

        • AIX or Linux: /opt/IBM/Cognos64/bin/

        • Windows: C:\Program Files\IBM\Cognos\bin

      2. Open the working copy of the cogstartup.xml file for editing.

      3. Within the <crn:instance name="Cognos" class="Cognos"> section, change the allowAnon parameter:

        From:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> false </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> true </crn:value>
        </crn:parameter>

      4. Save and close the file.

      5. Restart WebSphere Application Server.

    8. Run the cognos-configure.sh|bat script to configure the Cognos server and set up database connections, just as you did when you originally deployed the Cognos server.

      Output from this operation is stored in the /CognosSetup/cognos-configure.log file.

      If you encounter an error when running the cognos-configure.sh|bat script, correct the error and run the script again before proceeding to the next step.

    9. After the configuration has been updated, disable anonymous access once more:

      Disable anonymous access with the Cognos Configuration tool:

      1. Navigate to the /bin directory of the Cognos BI Server installation directory.

        For example:

        • AIX or Linux: /opt/IBM/Cognos64/bin/

        • Windows: C:\Program Files\IBM\Cognos\bin

      2. Start the Cognos Configuration tool by running the following command:

        • AIX or Linux: ./cogconfig.sh

        • Windows: cogconfig.bat

      3. Expand Local Configuration > Security > Authentication > Cognos and set Allow anonymous access? to False.

      4. Exit the Cognos Configuration tool, making sure to select No at the following prompt: The service 'IBM Cognos' is not running on the local computer. Before you can use it your computer must start the service. Do you want to start this service before exiting?

      5. Restart WebSphere Application Server.

      6. Start the Cognos server.

      Disable anonymous access manually:

      1. Navigate to the /configuration directory within the Cognos BI Server installation directory:

        For example:

        • AIX or Linux: /opt/IBM/Cognos64/bin/

        • Windows: C:\Program Files\IBM\Cognos\bin

      2. Open the working copy of the cogstartup.xml file for editing.

      3. Within the <crn:instance name="Cognos" class="Cognos"> section, change the allowAnon parameter:

        From:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> true </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> false </crn:value>
        </crn:parameter>

      4. Save and close the file.

      5. Restart WebSphere Application Server.

      6. Start the Cognos server.

    Back up and restore Metrics data

    You can back up the PowerCube.s data on a monthly basis, or you can back up the entire Metrics database history. It is easier to back up a single month.s worth of PowerCube data than to back up the entire Metrics database history, but backing up the database allows you to rebuild the entire PowerCube if needed.


    Back up and restore sub-PowerCubes

    Each month, one sub-PowerCube is generated containing data for the past month. These sub-PowerCubes are stored on the disk as files that you can use for backing up and restoring a month.s worth of data in the PowerCube.

    Back up a sub-PowerCube only preserves one month.s data at a time. Rebuilding a PowerCube requires a full restore from the raw Metrics database. For information on restoring an entire PowerCube, see Restore the entire Metrics database and PowerCube or Restore the Metrics database and PowerCube incrementally.

    1. To back up a month.s worth of PowerCube data, copy the previous month.s sub-PowerCube file to a different server:

      Back up the most recent sub-PowerCube that contains data for an entire month; do not back up the current month.s data because it is incomplete.

      1. On the server hosting the IBM Cognos Transformer component, navigate to the Powercube_save_path/MetricsTrxCube directory, which is where sub-PowerCube files for each month are stored.

        The Powercube_save_path is the value of the cognos.cube.path property specified in the cognos-setup.properties file.

      2. Copy the sub-PowerCube for the previous month to the backup location.

    2. To restore a PowerCube, copy the backed-up version of the sub-PowerCube back to the original server:

      1. On the server storing the backup files, navigate to the location of the saved PowerCube file and copy the most recent month.s backup file.

      2. On the server hosting the IBM Cognos Transformer component, copy the retrieved file to the Powercube_save_path/MetricsTrxCube directory.

      3. Either wait for the scheduled cube refresh job to run, or run it manually.

        After the cube refresh job finishes, the changes are updated to the Cognos server.


    Back up the Metrics database

    The Metrics database contains the raw data that is used to generate the PowerCube. Back up the Metrics database on a regular basis ensures that you can rebuild the PowerCube in the event of a failure.

    The backup schedule for the Metrics database is based on how long the raw metrics data is stored there. For example, if you specify the metrics-config.xml file.s databaseCleanup.eventLifetimeInMonths value as 6, then raw metrics data older than 6 months is purged, so you must back up the Metrics database at least every 6 months to prevent data loss.

    To back up the Metrics database, complete the following steps:

    1. Select a backup schedule method to back up the Metrics database every month, quarter, or year, depending on the database size and your business needs.

    2. On the database server, back up the database as explained in the database product documentation.


    Restore the entire Metrics database and PowerCube

    The Metrics database contains the raw data that is used to generate the PowerCube. Back up the Metrics database on a regular basis ensures that you can rebuild the PowerCube in the event of a failure.

    If you plan to restore the PowerCube on a staging server before copying to your product server, begin by installing Cognos Business Intelligence on the staging server. Best practice is to install and configure the staging server just like the production server; at a minimum the staging server requires the customized version of Cognos Business Intelligence installed on the production server, and access to the LDAP directory where the Cognos administrator account resides.

    When you restore the Metrics database, you must rebuild the PowerCube to make sure it contains all of the same data. You can restore the entire Metrics database in a single operation, and then rebuild the entire PowerCube in another single operation. If the Metrics database is large and your space for restoring the database and rebuilding the PowerCube is limited, you can complete the process incrementally by restoring subsets of data and rebuilding the PowerCube to add each additional set of data. For more information, see Restore the Metrics database and PowerCube incrementally. To minimize the impact on your users, restore the PowerCube to a staging server and then copy the completed PowerCube to the production server where IBM Cognos Transformer is installed.

    If the database is large, it can take a long time to restore it and rebuild the PowerCube.

    To restore the Metrics database and rebuild the PowerCube, complete the following steps:

    1. Restore the entire Metrics database by following the instructions in the database product documentation.

    2. On the staging server, copy the Transformer_install_path/metricsmodel directory and its contents from the production server where IBM Cognos Transformer is installed.

      This is the directory containing saved PowerCube model files that specify how the PowerCube is built; it is the cognos.transformer.install.path property specified in the cognos-setup.properties file.

    3. On the staging server, rebuild the PowerCube from the restored Metrics database:

      1. Navigate to the Transformer_install_path/metricsmodel directory.

        The Transformer_install_path is the value of the cognos.transformer.install.path property specified in the cognos-setup.properties file.

      2. Run the build-all.sh|bat script.

    4. Move the rebuilt PowerCube to the production server by copying the following directories and their contents from the staging server to the production server:

      • Powercube_save_path

        Powercube_save_path is the directory containing saved PowerCube files; it is the cognos.cube.path property specified in the cognos-setup.properties file.

      • Transformer_install_path/metricsmodel

        Transformer_install_path is the value of the cognos.transformer.install.path property specified in the cognos-setup.properties file.


    Restore the Metrics database and PowerCube incrementally

    The Metrics database contains the raw data that is used to generate the PowerCube. Whenever you restore the Metrics database from the backup copy, you must rebuild the PowerCube to ensure it contains the full set of data. If you have limited disk space, you can restore both the database and the PowerCube in increments.

    If you plan to restore the PowerCube on a staging server before copying to your product server, begin by installing Cognos Business Intelligence on the staging server. Best practice is to install and configure the staging server just like the production server; at a minimum the staging server requires the customized version of Cognos Business Intelligence installed on the production server, and access to the LDAP directory where the Cognos administrator account resides.

    If the Metrics database is large and your space for restoring the database and rebuilding the PowerCube is limited, you can complete the process incrementally by restoring subsets of data and rebuilding the PowerCube to add each additional set of data; then you will delete the restored data to prepare the database for the next increment. When the PowerCube is completely rebuilt, you must perform one final restore on the Metrics database to replace the data you deleted between stages.

    If you have the space and prefer to rebuild the entire PowerCube in a single operation, see Rebuilding the entire Metrics database and PowerCube.

    If the database is large, it can take a long time to restore it and rebuild the PowerCube. To minimize the impact on your users, restore the PowerCube to a staging server and then copy the completed PowerCube to the production server

    ...where IBM Cognos Transformer is installed.

    1. Prepare the staging server where you will rebuild the PowerCube:

      1. Copy the Transformer_install_path/metricsmodel directory and its contents from the production server where IBM Cognos Transformer is installed.

        This is the directory containing saved PowerCube model files that specify how the PowerCube is built; it is the cognos.transformer.install.path property specified in the cognos-setup.properties file.

      2. Create an incremental version of the script that builds the PowerCube:

        1. Navigate to the Powercube_save_path/metricsmodel directory.

        2. Copy the build-all.sh|bat script to a new file called incremental-build-all.sh|bat in the same directory.

        3. Edit the incremental-build-all.sh|bat file and delete the following statements to avoid accidentally deleting incremental additions to the PowerCube:

          AIX or Linux:

          echo delete all existing cube files...
          
          rm -rf [POWERCUBE_SAVE_PATH]/*

          Windows:

          echo delete all existing cube files...
          
          del /F /Q "[POWERCUBE_SAVE_PATH]"
          
          for /D %%i in ("[POWERCUBE_SAVE_PATH]") do RD /S /Q "%%i"

        4. Save and close the file.

    2. On the database server, restore the first increment of data to the Metrics database as explained it the database product documentation.

      For best results, restore data in full-month increments (multiple months are acceptable provided you restore the complete set of data for each month). Restoring data for full months ensures prevents you from duplicating data by restoring it twice.

      For example, suppose you restore backup data for 1-May-2012 through 12-May-2012 but omit the remainder of the data for that month. In the next stage, you will have to take extra care to restore only the remaining data for that month (13-May-2012 through 31-May-2012); if you want to restore the entire month in the second stage you will have to first delete the partial month that you already restored. Restoring only full-month increments avoids this problem.

      If the final set of data comprises an incomplete month, you will not risk duplicating it in another stage so there is no need to worry about it representing less than a full month.

      If you restored a partial month.s data, you can delete those records from the appropriate database tables based on the specified timestamp column for each table. Table 1 lists the database tables and corresponding timestamp columns where yo will need to delete records. For example, in the F_TRX_EVENT database table, check the data in the EVENT_TS column and delete the records where the date falls within the time period to delete.

      Table 2. Tables to reference when deleting records for partial months from a database

      Table name in database Timestamp column
      F_TRX_EVENT EVENT_TS
      F_USER_EVENT_COUNT UPDATE_TS
      F_ITEM_EVENT_COUNT UPDATE_TS

    3. On the staging server, rebuild the first increment of restored data in the PowerCube:

      1. Navigate to the Powercube_save_path/metricsmodel directory.

      2. Run the build-all.sh|bat script to rebuild the PowerCube from the first set of restored Metrics data.

        If there is already a PowerCube stored in the directory, the build-all.sh|bat script deletes it before building the new one. When building the PowerCube incrementally, you only run this version of the script once because you do not want to delete the incremental copies of the PowerCube.

    4. Complete the following steps for each subsequent increment of data to be restored:

      1. On the database server, delete the previously restored data from the Metrics database to prevent accidental duplication.

      2. On the database server, restore the next increment of data to the Metrics database by following the instructions in the database product documentation.

      3. On the staging server, rebuild the new increment of restored data to the PowerCube by running the incremental-build-all.sh|bat script.

      Repeat this process until the PowerCube has been completely rebuilt.

    5. Move the rebuilt PowerCube to the production server by copying the Powercube_save_path directory and its contents from the staging server:

      Powercube_save_path is the directory containing saved PowerCube files; it is the cognos.cube.path property specified in the cognos-setup.properties file.

    6. Delete the data from the Metrics database that was previously restored, to prevent duplication the next time you restore the database on the staging server.

    Administer Profiles

    Profiles provides two types of administrative capabilities: configuration settings and administrative commands. You change configuration settings and execute administrative commands by running scripts from the wsadmin command line.

    Jython Scripts run from a wsadmin command line are used to configure and to administer Profiles. These scripts use the AdminConfig object available in IBM WebSphere Application Server Admin (wsadmin) to interact with the configuration repository.

    You can update the Profiles environment in two ways:

    Configuration settings

    Modify these settings to control various configurable applications within Profiles. When you make configuration changes, you use scripts to check out the Profiles configuration file, profiles-config.xml, make changes, and then check the file back in. A server restart is required for your changes to take effect.

    Administrative commands

    Use these commands to control various aspects of the Profiles environment. Administrative commands do not require a server restart to take effect.


    Related

  • Customize Profiles
  • Manage users
  • Customize the Profiles business card

  • Integrate the Profiles business card

    Run Profiles administrative commands

    Scripts are used to administer the Profiles application. These scripts use the AdminConfig object available in IBM WebSphere Application Server wsadmin client to interact with the Profiles server.

    To run administrative commands, you must use the wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    You cannot use administrative tools to add or remove a profile from your LDAP directory system. You must use that directory's native tools to create and delete profiles. The scripts used to administer Profiles give an administrator (who otherwise would not have access to edit a user's profile data), the ability to edit various fields in a user's profile. For example, one use of the capability is to remove unwanted or inappropriate content.

    Unlike with configuration properties, when you use administrative commands to change server administration properties, you do not have to check out any files nor restart the server. Your changes take effect immediately.

    To run administrative commands, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. See Profiles administrative commands for a complete list of administrative commands for the Profiles application.


    Profiles administrative commands

    Use the commands listed to perform administrative tasks for Profiles. No file checkout or server restart is needed when using these commands.

    The following sections define the commands that you can use when working with Profiles. Each section describes the commands for a specific service. The commands are listed in alphabetical order.


    ProfilesConfigService commands

    ProfilesConfigService.checkOutConfig("working_directory", "cell_name")

    Checks all Profiles configuration files out to a temporary directory.

    This command takes the following parameters:

    • working_directory. Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

    • cell_name. Name of the IBM WebSphere Application Server cell hosting the IBM Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:

      print AdminControl.getCell()
      For example:

      • AIX/Linux:

        ProfilesConfigService.checkOutConfig("/opt/my_temp_dir", "ServerNode01Cell")

      • Microsoft

        Windows:

        ProfilesConfigService.checkOutConfig("c:/temp","foo01Cell01")

    ProfilesConfigService.showConfig()

    Displays the current configuration settings. You must check out the configuration files with ProfilesConfigService.checkOutConfig before running ProfilesConfigService.showConfig.

    ProfilesConfigService.updateConfig("property", "value")

    Updates configuration properties.

    This command takes the following parameters:

    • property. One of the configuration properties that can be edited for Profiles. See Profiles configuration properties for a full list of Profiles configuration properties and their descriptions.

    • value. The new value with which you want to set the specified property. Acceptable values for properties can be restricted, for example, to either true or false. See Profiles configuration properties for configuration properties and descriptions.

    ProfilesConfigService.checkInConfig()

    Checks in Profiles configuration files. Run from the wsadmin command processor.

    ProfilesConfigService.checkOutPolicyConfig("working_directory", "cell_name")

    Checks profiles-policy.xml and profiles-policy.xsd files out to a temporary directory.

    This command takes the following parameters:

    • working_directory. Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

    • cell_name. Name of the WebSphere Application Server cell hosting the IBM Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:

      print AdminControl.getCell()
      For example:

      • AIX/Linux:

        ProfilesConfigService.checkOutPolicyConfig("/opt/my_temp_dir", "ServerNode01Cell")

      • Microsoft

        Windows:

        ProfilesConfigService.checkOutPolicyConfig("c:/temp","foo01Cell01")

    ProfilesConfigService.checkInPolicyConfig()

    Checks in the Profiles policy configuration files. Run from the wsadmin command processor.

    ProfilesConfigService.findDistinctProfileTypeReferences()

    Lists the profile types that are present in the Profiles database.

    ProfilesConfigService.findUndefinedProfileTypeReferences()

    Lists the profile types that are present in the Profiles database that do not appear in the profiles-types.xml configuration file.


    ProfilesService commands

    ProfilesService.deletePhoto(String user_email_addr)

    Deletes image files associated with a user's email address. This command can be used only if the user has uploaded a photo to their profile. This command removes the photo.

    For example:

    ProfilesService.deletePhoto("john_doe@company.com")

    ProfilesService.disableFullReportsToCache()

    Disables the full report-to chain cache capability. This command does not take any arguments.

    ProfilesService.enableFullReportsToCache(startDelay, interval, schedTime)

    Enables the full report-to chain cache with the specified start delay in minutes, refresh interval in minutes, and scheduled refresh time in HH:MM format.

    This cache is used to populate the full report-to chain view available in a user's profile. The cache contains the specified number of top employees in the organizational pyramid; it is not intended to store an entry for each profile. It stores the profiles of those people at the top of the chain who are included in many full report-to chain views.

    For example:

    ProfilesService.enableFullReportsToCache(5, 15, "23:00")

    ProfilesService.purgeEventLogs()

    Deletes all event log entries in the EVENTLOG table. This command does not take any arguments.

    ProfilesService.purgeEventLogsByDates(string startDate, string endDate)

    Deletes event log entries created between the specified start date and end date.

    This command takes the following parameters:

    startDate

    A string that specifies the start date for the period in MM/DD/YYYY format.

    endDate

    A string that specifies the end date for the period in MM/DD/YYYY format.

    For example:

    ProfilesService.purgeEventLogsByDates("06/21/2009", "06/26/2009")
    This command deletes all the event log entries that were created on or after June 21st, 2009 and before June 26th, 2009 from the EVENTLOG table.

    ProfilesService.purgeEventLogsByEventNameAndDates(eventName, string startDate, string endDate)

    Deletes event log entries with the specified event name that were created between given start date and end date.

    This command takes the following parameters:

    eventName

    The type of event to remove from the EVENTLOG table. The following names are some examples of valid event names:

    • profiles.created

    • profiles.removed

    • profiles.updated

    • profiles.person.photo.updated

    • profiles.person.audio.updated

    • profiles.colleague.created

    • profiles.colleague.added

    • profiles.connection.rejected

    • profiles.person.tagged

    • profiles.person.selftagged

    • profiles.tag.removed

    • profiles.link.added

    • profiles.link.removed

    • profiles.status.updated

    • profiles.wallpost.created

    • profiles.wallpost.removed

    • profiles.wall.comment.added
    For a complete list of valid event names for Profiles event log cleaning administrative tasks, refer to the following web page:
    http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Events_Reference

    startDate

    A string that specifies the start date for the period in MM/DD/YYYY format.

    endDate

    A string that specifies the end date for the period in MM/DD/YYYY format.

    For example:

    ProfilesService.purgeEventLogsByEventNameAndDates(profiles.colleague.created, "06/21/2009", "06/26/2009")
    This command deletes all the profiles.colleague.created event log entries that were created on or after June 21st, 2009 and before June 26th, 2009 from the EVENTLOG table.

    ProfilesService.reloadFullReportsToCache()

    Forces a reload of the full report-to chain cache from the Profiles database. This command does not take any arguments.

    If the full report-to cache is disabled, it cannot be reloaded. This command fails when the cache is disabled.

    ProfilesService.updateDescription(String user_email_addr, String new_content_for_description_field)

    Replaces the existing description text associated with a user's email address with alternate description text enclosed by double quotes.

    Description text is information contained on the About Me tab of a user's profile.

    For example:

    ProfilesService.updateDescription("ann_jones@company.com","This is new text that will be entered into the About Me tab for Ann.")

    Rich text cannot be entered with this command.

    ProfilesService.updateExperience(String user_email_addr, String new_content_for_experience_field)

    Replaces the existing experience text associated with a user's email address with alternate text enclosed by double quotes.

    Experience is the information contained in the Background area of a user's profile.

    For example:

    ProfilesService.updateExperience("ann_jones@company.com","This is new text that will be entered into the Background field for Ann.")

    Rich text cannot be entered with this command.

    Commands for managing user data

    ProfilesService.activateUserByUserId(String user_external_id, updated_properties_list)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.inactivateUser(String user_email_addr)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.inactivateUserByUserId(String userID)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.publishUserData(String user_email_addr)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.publishUserDataByUserId(String userID)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.swapUserAccessByUserId("user_to_activate","user_to_inactivate")

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.updateUser(String user_email_addr, updated_properties_list)

    See Managing user data using Profiles administrative commands for details.

    ProfilesService.updateUserByUserId(String userID, updated_properties_list)

    See Managing user data using Profiles administrative commands for details.


    Related

  • Synchronize user data using administrative commands

  • Run administrative commands
  • Synchronize remote application data with the Communities database
  • Manage user data using Profiles administrative commands

  • Profiles configuration properties
  • Administer application content

    Change Profiles configuration property values

    Configuration settings control how and when various Profiles operations take place. You can edit the settings to change the ways that profiles behave.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. Configure Profiles using scripts accessed with the wsadmin client. These scripts use the AdminConfig object available in the IBM WebSphere Application Server wsadmin client to interact with the Profiles configuration file. Changes to configuration settings require node synchronization and a restart of the Profiles server before they take effect.

    There are no Profiles application administrative tools for adding or removing a user's profile. If you want to add or remove a profile for a person, add or remove that person's entry from the corporate LDAP directory system. Use that directory's native tools to create and delete user entries. When you perform standard synchronization tasks on the Profiles database, the profiles are updated. If you add a new user to the LDAP directory, a profile is created for that user. If you remove a user entry from the LDAP directory, that user's profile is removed. See Synchronizing user data between Profiles and the LDAP directory for more details.

    To change Profiles configuration settings, complete the following steps:

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. To change a Profiles configuration setting, use the following command:

      ProfilesConfigService.updateConfig("property", "value")

      ...where:

      • property is one of the editable Profiles configuration properties.

      • value is the new value with which you want to set that property.
      For example, the following code disables the display of organizational information.

      ProfilesConfigService.updateConfig("organizationalStructure.enabled","false")
      See Profiles configuration properties for a complete list of editable properties.

    4. Optional: Repeat the previous step once for each property setting you want to change.


    What to do next

    You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See Applying property changes for details.


    Related tasks

  • Synchronize user data between Profiles and the LDAP directory
  • Apply property changes in Profiles
  • Configure Profiles events


    Profiles configuration properties

    Configuration settings control various configurable applications within Profiles. They require a Profiles application or server restart to take effect.

    You can check out and modify the following configuration settings in the profiles-config.xml file.

    Some configuration settings, such as the settings for the board and tagging features, were moved from the profiles-config.xml file to profiles-policy.xml file. For more information about the settings that you can configure in profiles-policy.xml file, see Configuring features by profile type.

    activeContentFilter.enabled

    Enables/disables filtering for active content of text entered into the About me and Background text input fields.

    This property takes a Boolean value: true or false. The value must be formatted in lowercase.

    fullReportsToChainCache.ceouid

    The corporate directory user ID of the person who displays at the top of the organizational structure.

    fullReportsToChainCache.enabled

    Enables or disables the full reports-to chain cache.

    This property takes a Boolean value: true or false. The value must be formatted in lowercase.

    fullReportsToChainCache.refreshInterval

    Time in minutes between cache reload operations.

    This property takes an integer value.

    fullReportsToChainCache.refreshTime

    HH:MM. Determines the time of day in 24-hour time format that Profiles performs the first scheduled reloading of the cache.

    fullReportsToChainCache.size

    The number of employee entries that should be loaded into the cache.

    This property takes an integer value.

    fullReportsToChainCache.startDelay

    Time in minutes that Profiles should wait after starting loading the cache for the first time.

    This property takes an integer value.

    organizationalStructure.enabled

    Indicates if the organizational structure information (report-to chain, people managed, same manager) should display.

    This property takes a Boolean value: true or false. The value must be formatted in lowercase.

    nameOrdering.enabled

    When this property is set to true, names must be entered as (FirstName LastName) or (LastName, FirstName). By default, it is set to false.

    When only a single word is entered, that word is treated as the LastName value during search.

    This property takes a Boolean value.

    scheduledTasks.DbCleanupTasks

    Specifies the frequency at which the database cleanup tasks runs. This task removes event log entries, or draft profiles updates older than the specified number of days.

    eventLogTrashRetentionInDays: Specifies the number of days to keep system events in the EMPINST.EVENTLOG table.

    draftTrashRetentionInDays: Specifies the number of days to keep draft profile updates.

    eventLogMaxBulkPurge: Specifies the maximum number of events to purge in a query.

    scheduledTasks.ProcessLifeCycleEventsTasks

    Specifies the frequency at which lifecycle events are published. This event ensures that lifecycle events are propagated.

    platformCommandBatrchSize: Specifies the maximum number of events attempted to process in each event run.

    scheduledTasks.ProcessTDIEventsTasks

    Specifies the frequency at which audit events triggered by a TDI synch are processed.

    platformCommandBatrchSize: Specifies the maximum number of events attempted to process in each event run.

    scheduledTasks.StatsCollectorTask

    Specifies the frequency at which Profiles statistics are calculated and written to disk.

    filePath: Specifies the directory in which to place the file.

    fileName: Specifies the file name.

    scheduledTasks.RefreshSystemObjectsTask

    This task is obsolete.

    search.maxRowsToReturn

    Determines the maximum number of rows returned by a search operation.

    This property takes an integer value.

    search.pageSize

    Determines the number of returned rows to place on a results page.

    This property takes an integer value.


    Related

  • Configure advanced settings in Profiles
  • Configure features by profile type

  • Start the wsadmin client
  • Apply common configuration property changes
  • IBM Connections configuration property values
  • Apply property changes in Profiles

  • Profiles administrative commands


    Apply property changes in Profiles

    After you have edited Profiles configuration properties, check the changed configuration file in, and restart the server to apply your changes.

    See Profiles configuration properties for information about the properties that you can edit for Profiles.

    1. Check in the changed configuration property keys using the following wsadmin client command:

      ProfilesConfigService.checkInConfig()

    2. Update the value of the version stamp configuration property in LotusConnections-config.xml to force users' browsers to pick up this change. See Required post-customization step for more details.

    3. To exit the wsadmin client, type exit at the prompt.

    4. Use the IBM WebSphere Application Server Integrated Solutions Console to stop and restart the server hosting the Profiles application.


    Related tasks

  • Apply common configuration property changes
  • Required post-customization step

  • Profiles configuration properties

    Tivoli Directory Integrator commands

    The following IBM Tivoli® Directory Integrator commands are available for managing profile data and performing user data synchronization tasks.

    For related information, see Developing custom Tivoli Directory Integrator assembly lines for Profiles.
    Use these commands to manage and work with profile data. The commands are listed in alphabetical order.

    Table 3. Tivoli Directory Integrator commands

    Command Description
    IBM AIX and Linux:
    clearLock.sh

    Microsoft

    Windows:
    clearLock.bat

    Deletes the lock file that is generated by the sync_all_dns task.

    For more information, see Synchronizing LDAP directory changes with Profiles.

    AIX and Linux:
    delete_or_inactivate_employees.sh

    Microsoft

    Windows:
    delete_or_inactivate_employees.bat

    Deletes or inactivates users in the Profiles database.

    For more information, see Delete or inactivate users in the Profiles database.

    AIX and Linux:
    dump_photos_to_files.sh

    Microsoft

    Windows:
    dump_photos_to_files.bat

    Reads existing photo files from the Profiles database and stores them on disk. Used in conjunction with the load_photos_from_files command.

    For more information, see Populating Profiles with photos.

    AIX and Linux:
    dump_pronounce_to_files.sh

    Microsoft

    Windows:
    dump_pronounce_to_files.bat

    Reads existing pronunciation files from the Profiles database and stores them on disk. Used in conjunction with the load_pronounce_from_files command.

    For more information, see Uploading pronunciation files.

    AIX and Linux:
    fixup_tdi_adapters.sh

    Microsoft

    Windows:
    fixup_tdi_adapters.bat

    Adds a reference to the profiles property store to your adapter files when you are defining a custom assembly line to contain the logic used for the delete operation.

    For more information, see Customize the logic used for the delete operation.

    AIX and Linux: load_photos_from_files.sh

    Microsoft

    Windows: load_photos_from_files.bat

    Reads stored photo files from disk and populates the Profiles database with them. Used in conjunction with the dump_photos_to_files command.

    For more information, see Populating Profiles with photos.

    AIX and Linux:
    load_pronounce_from_files.sh

    Microsoft

    Windows:
    load_pronounce_from_files.bat

    Reads stored pronunciation files from disk and populates the Profiles database with them. Used in conjunction with the dump_pronounce_to_files command.

    For more information, see Uploading pronunciation files.

    AIX and Linux:
    process_draft_updates.sh

    Microsoft

    Windows:
    process_draft_updates.bat

    Synchronizes changes from the Profiles database back to the LDAP directory. The script initializes a daemon process that monitors the Profiles database for updates, formats each update as a DSML request, and the transmits it to a configured DSML server.

    For more information, see Synchronizing user data between Profiles and the LDAP directory.

    AIX and Linux:
    process_ad_changes.sh

    Microsoft

    Windows:
    process_ad_changes.bat

    Processes changes made to a Microsoft Active Directory LDAP directory and propagates the changes to the corresponding records in the Profiles database repository.

    For more information, see Synchronizing IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes.

    AIX and Linux:
    process_tds_changes.sh

    Microsoft

    Windows:
    process_tds_changes.bat

    Processes changes made to an IBM Tivoli Directory Server LDAP directory and propagates the changes to the corresponding records in the Profiles database repository.

    For more information, see Synchronizing IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes.

    AIX and Linux:
    reset_draft_iterator_state.sh

    Microsoft

    Windows:
    reset_draft_iterator_state.bat

    Deletes the value of a database change record number tracked in a persistent field by the process_draft_update task.

    For more information, see Synchronizing user data between Profiles and the LDAP directory.

    AIX and Linux:
    set_draft_iterator_count.sh

    Microsoft

    Windows:
    set_draft_iterator_count.bat

    Resets the value of a database change record number tracked in a persistent field by the process_draft_update task.

    For more information, see Synchronizing user data between Profiles and the LDAP directory.

    AIX and Linux:
    sync_all_dns.sh

    Microsoft

    Windows:
    sync_all_dns.bat

    Synchronizes LDAP directory changes with the Profiles database.

    For more information, see Synchronizing LDAP directory changes with Profiles.

    AIX and Linux:
    update_employees_from_file.sh

    Microsoft

    Windows:
    update_employees_from_file.bat

    Replaces the globally unique identifiers in the Profiles database with the correct values from the LDAP directory.

    For more information, see Updating Profiles when changing LDAP directory.


    Related

  • Developing custom Tivoli Directory Integrator assembly lines for Profiles
  • Manage user data using Tivoli Directory Integrator scripts
  • Developing custom Tivoli Directory Integrator assembly lines for Profiles

  • Populate the Profiles database
  • Synchronize source changes such as LDAP with Profiles
  • Update Profiles when changing LDAP directory
  • Delete or inactivate users in the Profiles database
  • Populate Profiles with photos
  • Uploading pronunciation files
  • Customize the logic used for the delete operation
  • Synchronize user data between Profiles and the LDAP directory
  • Synchronize IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes

    Add supplemental content to Profiles

    You can use IBM Tivoli Directory Integrator assembly-line commands to add photo files and pronunciation files for your users to the Profiles database.

    When xWindows is not installed on your system, the load_pronunciation_from_files and load_photo_from_files commands might not work. In this scenario, change the default value of the headless_tdi_scripts setting in the profile_tdi.properties file from false to true as follows:

    headless_tdi_scripts=true

    Related information is available in the IBM Tivoli Directory Integrator solutions for IBM Connections real-world scenarios wiki article.


    Related

  • Developing custom Tivoli Directory Integrator assembly lines for Profiles
  • Manage user data using Tivoli Directory Integrator scripts

  • Add source data to the Profiles database


    Uploading pronunciation files

    Profiles users can add a recording of how their name is pronounced to enhance their profile. As administrator, you can use IBM Tivoli Directory Integrator assembly-line commands to populate the profiles database repository with pronunciation files for your users. You can use the dump_pronounce_to_files and load_pronounce_from_file assembly-line commands to populate the profiles database with pronunciation files. These commands are useful when you are moving the profiles database, allowing you to save the pronunciation information from the existing database on disk, repopulate the new database from the LDAP, and then load the pronunciation files back into the new database.

    To populate a new profiles database with pronunciation files.

    1. Use the dump_pronounce_to_files.bat or dump_pronounce_to_files.sh command to read the existing pronunciation files from the Profiles database and store them on disk:

      The following table shows the properties that are used by this command and their default values. These properties can be found in the profiles_tdi.properties file.

      Property Description
      dump_pronounce_directory

      The directory where the extracted files are stored.

      The default value is ./dump_pronounce.

      dump_pronounce_file

      The list of people whose pronunciation files were collected.

      The default value is collect_pronounce.in.

      load_pronounce_simple_file

      The list of people whose pronunciation files were collected.

      The default value is collect_pronounce.in.

      If you want to load only a subset of files from a location, you edit this file.

      When dumping multiple pronunciation files, there must be a period separator between each entry. If the separator is omitted, an error is generated when you use the load command to import the files into the profiles database.

    2. To populate the new database with the pronunciation files that you saved in the previous step, use the load_pronounce_from_files.bat or load_pronounce_from_files.sh command to read the files from disk and populate the profiles database with them

      The table in step 1 shows the properties that relate to this command.


    Example

    Here is an example of an entry from the collect_pronounce.in file:

    file:/C:/install_directory/TDISOL/TDI/./dump_pronounce/pron1197046202619_9.dat 
    uid:FAdams
    .
    The characters following uid: correspond to the PROF_UID in the profiles database.

    Note the required period separator between each entry.

    For example:

    file:/C:/install_directory/TDISOL/TDI/./dump_pronounce/pron1197046202619_9.dat 
    uid:FAdams
    .
    file:/C:/install_directory/TDISOL/TDI/./dump_pronounce/pron6198046102314_6.dat 
    uid:TAmado
    .


    Related tasks

  • Enable the use of pronunciation files in an HTTPS environment
  • Use the PronunciationConnector


    Populate Profiles with photos

    You can use IBM Tivoli Directory Integrator assembly-line commands to populate the profiles database repository with photo files for your users. You can use the dump_photos_to_files and load_photos_from_file assembly-line commands to populate the profiles database with photo files. These commands are useful when you are moving the profiles database, allowing you to save the photos from the existing database on disk, repopulate the new database from the LDAP, and then load the photo files back into the new database.

    To populate a new profiles database with photos, complete the following steps.

    1. Use the dump_photos_to_files.bat or dump_photos_to_files.sh command to read the existing photos from the profiles database and store them on disk:

      The following table shows the properties that are used by this command, and their default values. These properties can be found in the profiles_tdi.properties file.

      Property Description
      dump_photos_directory

      The directory where the extracted files are stored. The default value is /dump_photos.

      dump_photos_file

      The list of people whose photos were collected. The default value is collect_photos.in.

      load_photos_simple_file

      The list of people whose photos were collected. The default value is collect_photos.in. If you want to load only a subset of files from a location, edit this file.

      When dumping multiple photo files, there must be a period separator between each entry. If the separator is omitted, an error is generated when you use the load command to import the files into the profiles database.

    2. To populate the new database with the photo files that you saved in the previous step, use the load_photos_from_files.bat or load_photos_from_files.sh command to read the files from disk and populate the Profiles database with them:

      1. The table in step 1 shows the properties that relate to this command.

      2. Although in IBM Connections 2.0, the Profiles application can crop the photo uploaded by a user, the photo size limit in the underlying database is 15 KB. When Profiles is used with IBM Tivoli Access Manager enabled, the Tivoli Access Manager can only load files conforming to this size limit.


    Example

    Here is an example of an entry from the collect_photos.in file:

    photo:file:/C:/install_directory/TDISOL/TDI/./dump_photos/img1197046202619_9.dat 
    uid:FAdams
    .
    The characters following uid: correspond to the PROF_UID in the profiles database.

    Note the required period separator between each entry.

    For example:

    photo:file:/C:/install_directory/TDISOL/TDI/./dump_photos/img1197046202619_9.dat 
    uid:FAdams
    .
    photo:file:/C:/install_directory/TDISOL/TDI/./dump_photos/img1197146402316_7.dat 
    uid:TAmado
    .


    Related tasks

  • Use the PhotoConnector

    Developing custom Tivoli Directory Integrator assembly lines for Profiles

    You can use IBM Tivoli Directory Integrator (TDI) connectors to develop custom assembly-line scripts when you need to provide a specific type of function.

    For example, if you do not want to populate Profiles with photos or pronunciation files using the standard method covered in Add supplemental content to Profiles, you might want to use the Photo connector or Pronunciation connector as an alternative.

    Tivoli Directory Integrator connectors are components that are used to access and update information sources. Connectors allow you to build your assembly lines without having to handle the technical details of working with different data stores, systems, services, or transports. Each type of connector suppresses implementation details and specifically handles the details of data source access. For more information about programming TDI connectors, see the TDI Reference Guide.

    IBM Connections provides the following connectors:

    Related information is available in the IBM Tivoli Directory Integrator solutions for IBM Connections real-world scenarios wiki article.

    The only supported methods for writing data or modifying data in the Profiles database are the following:

    Writing directly to the Profiles database, including using Tivoli Directory Integrator database connectors to do so, is not supported and can lead to data loss and application malfunction.


    Related

  • Manage user data using Tivoli Directory Integrator scripts
  • Add supplemental content to Profiles
  • Manage user data using Tivoli Directory Integrator scripts

  • Populate the Profiles database

  • Tivoli Directory Integrator commands
  • Tivoli Directory Integrator commands


    Set up your development environment

    Use the Tivoli Directory Integrator Configuration Editor to create custom IBM Tivoli Directory Integrator scripts. Set up the development environment so that the editor can access a separate set of the IBM Connections Profiles Tivoli Directory Integrator connector source files than those used by the installed product. When you install IBM Connections, a set of Tivoli Directory Integrator (TDI) components are installed on your system. These components are used by the population wizard and other TDI tasks, such as the synchronization tasks, to populate and update the IBM Connections user directory. They are stored in a compressed file referred to as the TDI solution directory (tdisol.zip or tdisol.tar).

    The solution directory includes a set of connectors, which are standard TDI components that you can use to build your own TDI assembly lines when the assembly lines in the solution directory do not suit your needs. Your custom assembly lines can:

    This section describes how to set up a development environment in which you can write your own assembly lines using the Profiles TDI connectors provided in the IBM Connections installation package.

    To set up your development environment, complete the following steps.

    1. Create a directory in which to store the TDI connector source files.

      Since you might create multiple iterations of the code you are developing, use a directory naming system that will help you keep track of each iteration. For example, you could add a subdirectory named version, where version is the version number and date of the copy of the tdisol.zip file that you will extract into the directory. Alternatively, you could name the directory after the assembly line you will be creating, such as custdel if you are working on custom delete processing logic. For example: C:\TDIProject\20120530 or c:\tdiprojects\40\custdel.

    2. Extract the files from the TDI solution directory (tdisol.zip or tdisol.tar) into the directory you created in the previous step. You can find the solution directory in the following location:

      C:\IBM\IBMConnections\TDISOL This action adds a tdi subdirectory to the directory path. For example: C:\TDIProject\20120530\TDI or c:\tdiprojects\40\custdel\tdi.

    3. When you start the Configuration Editor, specify the location of the Profiles TDI solution directory using the -s command-line option as follows:

      tdi_install_dir/ibmditk -s your_TDI_directory

      ...where:

      • tdi_install_dir is the name of the directory where you installed Tivoli Directory Integrator.

      • your_TDI_directory is the subdirectory that you created in the previous step.
      For example:

      C:\Program Files\IBM\TDI\V7.0/ibmditk -s C:\TDIProject\20120530\TDI

      The workspace used for development must reference a TDI solution directory that contains all the Profiles TDI artifacts. It is not sufficient to create a new TDI solution directory or use one that does not contain these artifacts. If you attempt to use a Profiles TDI component, such as one of the connectors, and they do not appear in the connector list, then you do not have your workspace and solution configured correctly.

    4. When you start the Tivoli Directory Integrator Configuration Editor, you are asked to specify a workspace. This is a working directory in which to store things related to your development project. When prompted, specify the same file path that you are using for the connector files, but replace TDI with workspace.

      For example: C:\TDIProject\20120530\workspace or c:\tdiprojects\40\custdel\workspace The editor creates the workspace subdirectory if it does not already exist.


    Results

    You now have a Tivoli Directory Integrator solution environment that you can use to edit the Profiles Tivoli Directory Integrator connectors.


    What to do next

    Refer to connector-specific documentation for details about each connector. Scripts created in this environment can be executed from the Configuration Editor in the same way that you would execute standard Tivoli Directory Integrator assembly lines.


    Related tasks

  • Use the ProfileConnector
  • Use the PhotoConnector
  • Use the PronunciationConnector
  • Use the CodesConnector
  • Customize the logic used for the delete operation
  • Create an iterator connector
  • Create a lookup connector


    Use a custom source repository connector

    By creating custom source repository connectors, you can integrate data from non-LDAP sources when you are populating Profiles with user data.

    To integrate a custom source repository, create custom versions of the following two assembly lines and package them as IBM Tivoli Directory Integrator adapters:

    Iterator connector

    This adapter iterates sequentially through all the users in your user directory. It is used by a number of iterative Tivoli Directory Integrator scripts. For example, it is used to retrieve the full information for initial data population using the collect_dns script and during data synchronization using the sync_all_dns script.

    Lookup connector

    This adapter looks up individual users in your user directory. It is used by the populate_from_dns_file script.
    For more information about using adapters, see the Tivoli Directory Integrator product documentation
    http://www.ibm.com/developerworks/tivoli/library/t-tdiadapters/index.html.

    After packaging your assembly lines, you can use them in your TDI solution by copying the file you published, such as the adapter.xml file, into the packages Profiles TDI solution directory.

    Add a reference to the profiles property store to your adapter files by running the fixup_tdi_adapters.sh or fixup_tdi_adapters.bat command. This reference is required to use the Profiles Tivoli Directory Integrator adapter. Even if you do not believe that your adapter file requires access to the profiles property store, there is no penalty for adding the reference so it is strongly advised that you run this command regardless.


    Related tasks

  • Set up your development environment


    Create an iterator connector

    Create an iterator connector to perform a sequential read of your entire user source repository.

    If you are using a source other than an LDAP, you must provide an iterator that will return each entry to process in sequence. If you are combining data from multiple sources, you must join all the data that is relevant to the data population mapping for a particular user into the work entry of the iterator assembly line. The only output should be a work entry that contains all the attributes for that user. Joining all the data together in a single step allows you to provide just this hook component and rely on the remainder of the Profiles Tivoli Directory Integrator (TDI) assembly lines to perform the majority of the processing.

    Create a source repository iterator connector by completing the following steps:

    1. To develop your iterator assembly line, connect to your source with an appropriate connector using its iterator mode. Retrieve the data to be used in the process into the work entry.

      You must populate the $dn attribute in the work entry. You can populate all the data from the source by mapping all attributes. You can use the mapping functionality to map fields from their names in your source into the fields expected by Profiles; you do not have to perform that mapping in your connector. The $dn attribute is the only required attribute name you must provide at this point in the process.

      To help get started with Tivoli Directory Integrator, go to the Learning TDI site. You can also refer to the Tivoli Directory Integrator product documentation for more information.

    2. Export your iterator solution :

      You can package the iterator connector together with the lookup assembly line, which is best practice although not a required step.

      1. Shift-click the assembly lines that comprise your iterator solution in the IBM Tivoli Directory Integrator Config Editor.

      2. Right-click a member of the selected assembly line group and select Publish.

      3. In the Publish window, enter a name for your solution in the Package ID field. For example, myIterateAdapter.

      4. Optional: Enter additional information, such as a version number or a help URL for future administrators.

      5. Assuming you followed the development environment set-up guide outlined in the topic, Set up your development environment, select the packages directory located in your IBM Connections TDI solution from the File Path menu, and then click Finish.

    3. To make the adapter file visible to the Profiles TDI solution, restart the Tivoli Directory Integrator Config Editor. If the Tivoli Directory Integrator server is not recycled during testing, it might not detect the existence of the new adapter.xml file. Recycling the Config Editor stops and starts the embedded Tivoli Directory Integrator server.

    4. Configure the Profiles TDI solution to use your adapter for data iteration :

      1. Open the profiles_tdi.properties file in a text editor.

      2. Add a property of the following format to the file:

        source_repository_iterator_assemblyline={name-of-your-adapter.xml}:/AssemblyLines/{name-of-your-ITERATOR-al}

        This property may already be present and commented out in the file. If so, remove the comment character (hash sign) and make the edits.

      3. Substitute {name-of-your-adapter.xml} with the package ID that you entered in step 2c.

      4. Substitute {name-of-your-ITERATOR-al} with the name of your iterator assembly line. The line should now look similar to the following:

        source_repository_iterator_assemblyline=myIterateAdapter:/AssemblyLines/iterate_over_csv_file

      5. Save your changes and then close the profiles_tdi.properties file.

    5. Optional: Test your solution and verify that you are able to iterate and to ensure that you are selecting the users that you are expecting, run the ./collect_dns.sh or collect_dns.bat script located in the TDI solution directory. You can then review the resulting collect.dns script to ensure that you have the results that you are expecting.


    Related tasks

  • Set up your development environment
  • Create a lookup connector


    Create a lookup connector

    Create a lookup connector to fetch data for a single user, including all the attributes necessary for mapping that user in your source repository. The lookup assembly line is used in the populate_from_dns_file script to populate users. Using the default mapping for secretary ($secretary_uid) and manager ($manager_uid), the script uses the assembly line to look up the manager and secretary uid values. If you can extract the manager and secretary uid values from the work entry without an additional lookup, it is advisable to do so for performance reasons.

    After developing your lookup connector, export it and then restart the Tivoli Directory Integrator configuration editor to make the adapter file visible to the Profiles TDI solution. To test the adapter, configure the Profiles TDI solution to use your adapter for data lookup. You can then test the adapter using the TEST_source_repository_lookup script provided by the TDI solution.

    A lookup connector is not usable in every situation. For example, if your source is a data file, you cannot retrieve the data using a lookup mode with the TDI file. However, you can provide an iterator connector and use the TDI assembly lines that do not use the lookup connector, such as sync_all_dns.

    Create a source repository lookup connector by completing the following steps:

    1. Develop your lookup assembly line by performing the following steps.

      1. Add an attribute map to your assembly line flow section by mapping the following attributes:

        • $dn . This attribute should be present in the attribute map with the value from the work entry.

        • $lookup_operation . This attribute should be present in the attribute map with the value from the work entry

        • $lookup_status . This attribute should be initialized to return the string error, for example map it to ret.value = "error"; .

      2. Connect to your source with an appropriate connector using its iterator mode. Retrieve the data to be used in the process into the work entry. Use the $dn attribute as the link criteria, or ensure that another value you wish to use is present in the work entry.

      3. Add the following Javascript entries to the following lookup connector hooks:

        • On no Match hook:

          work.setAttribute("$lookup_status", "nomatch");
          system.skipEntry();

        • Default Success hook:

          work.setAttribute("$lookup_status", "success");

        • Lookup Error hook:

          work.setAttribute("$lookup_status", "nomatch");
          system.skipEntry();

      4. Add the following entry to the assembly line On Failure hook:

        system.ignoreEntry();

      5. Optionally add additional error checking code and tracing output.

      To help get started with Tivoli Directory Integrator, go to the Learning TDI site. You can also refer to the Tivoli Directory Integrator product documentation for more information.

    2. Export your lookup solution :

      You can package the lookup connector together with the iterator assembly line, which is best practice suggestion but not a required step.

      1. Shift-click the assembly lines that comprise your lookup solution in the IBM Tivoli Directory Integrator Config Editor.

      2. Right-click a member of the selected assembly line group and select Publish.

      3. In the Publish window, enter a name for your solution in the Package ID field. For example, myLookupAdapter.

      4. Optional: Enter additional information, such as a version number or a help URL for future administrators.

      5. Assuming you followed the development environment procedure outlined in the topic, Set up your development environment, select the packages directory located in your IBM Connections TDI solution from the File Path menu, and then click Finish.

    3. To make the adapter file visible to the Profiles TDI solution, restart the Tivoli Directory Integrator Config Editor. If the Tivoli Directory Integrator server is not recycled during testing, it might not detect the existence of the new adapter.xml file. Recycling the Config Editor stops and starts the embedded Tivoli Directory Integrator server.

    4. Configure the Profiles TDI solution to use your adapter for data lookup :

      1. Open the profiles_tdi.properties file in a text editor.

      2. Add a property of the following format to the file:

        source_repository_iterator_assemblyline={name-of-your-adapter.xml}:/AssemblyLines/{name-of-your-ITERATOR-al}

        This property may already be present and commented out in the file. If so, remove the comment character (hash sign) and make the edits.

      3. Substitute {name-of-your-adapter.xml} with the package ID that you entered in step 2c.

      4. Substitute {name-of-your-ITERATOR-al} with the name of your lookup assembly line. The line should now look similar to the following:

        source_repository_lookup_assemblyline=myLookupAdapter:/AssemblyLines/lookup_from_db

      5. Save your changes and then close the profiles_tdi.properties file.

    5. Test your lookup adapter using the TEST_source_repository_lookup script in the Profiles TDI solution. To use this script:

      1. Configure the assembly line as described in the previous steps.

      2. Write the distinguished names of a number of users in a file named collect.dns and place this file at the root of the Profiles TDI solution directory. Separte each distinguished name with a carriage return.

      3. Run the runAl.sh TEST_source_repository_lookup or runAl.bat TEST_source_repository_lookup command. This command iterates over the collect.dns file and attempts to look up each user specified. The resulting data returned by your adapter is generated in the ibmdi.log file in the {TDI solution}/logs/ibmdi.log directory. You can examine this file to confirm that it is returning all of the expected values correctly.

      4. Repeat this procedure as needed until you are satisfied with the output of your adapter.


    Related tasks

  • Set up your development environment
  • Create an iterator connector


    Use the ProfileConnector

    Use the ProfileConnector to retrieve, create, update, and reset profile entries in the employee, profile extension, and other employee tables in the Profiles database. The connector flattens these tables into a single view of the profile data. The ProfileConnector can also be used to change the user state and change whether a user profile is listed as a manager. The ProfileConnector is the only supported way to perform these operations on a proflie using TDI as IBM Connections does not support the use of direct database access.

    For information about how to configure your development environment for working with the IBM Tivoli Directory Integrator connectors, and where to place the connectors, see Set up your development environment.

    Database properties are read from the profiles_tdi.properties file, which must be configured prior to using the connector. The Profiles property store must be part of the configuration (.xml) file where your assembly lines are located. For related information, see Connector modes in the Tivoli Directory Integrator documentation. The mode setting of the ProfileConnector determines what role the connector carries out in the assembly line. You can use the ProfileConnector in the following modes.

    Table 4. ProfileConnector modes

    Mode Description
    Iterator

    Iteratively scans data source entries, reads their attribute values, and delivers each entry to the appropriate AssemblyLine Flow section components.

    All attributes that contain data in the profile can be mapped to be returned by the iterator mode. In addition to the list of profile attributes listed in the map_dbrepos_from_source.properties file, the following attributes can also be retrieved in the iterator and lookup modes:

    • key - an internal key used to uniquely identify this profile. This key is used to link data between tables in the profiles database. It is not exported from profiles out to other connections components.

    • sys_usrState - the value active or inactive based on the user's state

    • lastUpdate - the time when this record was last updated by any means int the database

    The sync_all_dns assembly line uses the Iterator mode during the hash records in database phase.

    Lookup

    Fetches records from the Employee table in the Profiles database according to specified search criteria.

    The following attributes can be used for the search criteria:

    • key

    • uid

    • email

    • guid

    • distinguishedName

    • sourceUrl

    • managerUid

    This is used by the dump_photos call.

    The search (link) criteria must be the key attribute.

    Update

    Updates the profile records in the Employee table in the Profiles database. The following attributes can be used for the search criteria:

    • key

    • uid

    • email

    • guid

    • distinguishedName

    • sourceUrl

    • managerUid

    In Update mode the following options are available on the connector panel:

    • Update user state . The available options are as follows:

      • Do not change (default)

      • Activate

      • Inactivate
      If Activate or Inactivate is selected this state will be explicitly set during the update processing of the record. This option is used during the sync_dns_process_add phase of sync_all_dns.

    • Mark manager . The available options are as follows:

      • Checked . Sets the manger status to Yes or No

      • Unchecked (default) . No manager status is specified

    • When this option is enabled, the update mode will perform the Mark manager processing in addition to any other update operations. It will recognize if the profile being updated is referenced as the manager by any other profile in the database. If it is referenced, it will be marked with a Y as being a manager. If it is not referenced, it will be marked with a N as not being a manager. This option is used by the mark_manager assembly line.

    The Update mode of the ProfileConnector is used by the update mode of the SyncDBFromSource internal assembly line, which is called by populate_from_dn_file.

    The ProfileConnector also supports the Compute Changes and Skip Lookup checkboxes in the Advanced area. Consider unchecking the Compute Changes option if you want a state change or mark manager operation to be executed whether or not other changes are necessary. For more information about Compute Changes and Skip Lookup options, see Connector modes in the Tivoli Directory Integrator documentation.

    The search (link) criteria is the same as the Lookup mode.

    Delete

    Deletes records in the Employee table in the Profiles database according to specified search criteria.

    The Delete mode of the ProfileConnector is used by the delete mode of the SyncDBFromSource internal assembly line, which is called by sync_all_dns.

    The search (link) criteria is the same as the Lookup mode.

    addOnly

    Adds new records to the Employee table in the Profiles database.

    markManager

    This mode has been deprecated in Connections 4; use Update mode with the Mark manager option instead.

    activate

    This mode has been deprecated in Connections 4; use Update mode with the Update user state option instead.

    inactivate

    This mode has been deprecated in Connections 4; use Update mode with the Update user state option instead.

    1. To add the connector to an assembly line, open the assembly line, and then click Add Component in the Configuration Editor.

    2. Select Connectors, and then select ProfileConnector from the Components list.

    3. Enter a name for the connector in the Name field.

    4. Select a mode from the Mode list, and then click Finish.


    What to do next

    Consider referencing the supplied assembly lines for examples in using the ProfileConnector. In addition to these ProfilesConnector supplied assembly lines, the following topics describe additional example programs that are included as part of the TDI solution and that use the ProfileConnector. Do not modify the existing assembly lines, but use the extension points available through the hooks or create your own assembly line.


    Related tasks

  • Set up your development environment
  • Uploading pronunciation files


    Create a connector to customize TDI attribute mapping

    You can customize extension attribute mappings in the Profiles connector.

    Only use this function if you plan to use the mapping functionality in the same way that the default assembly lines do.

    • If you want to set extension attributes, they must be added to the work entry in a certain way. In TDI, the work entry is the object passed to the different steps of the assembly line.

    The following function reads the extension attributes out of the tdi-profiles-config file and adds them to the work entry.

    var theEntry = system.newEntry();
    ...
    create_extension_attribute_mappings(db_from_ldap_array, theEntry);
    


    Create a connector to synchronize Profiles data using LDIF

    You can use a source other than LDAP to synchronize Profiles user data. This sample shows how to use an LDIF text file as the user data source.

    In this sample, data exported from an LDAP or constructed from another means contains data for the Profiles users in your IBM Connections deployment. If you have user data in a text file such as in LDIF format, you can use this sample connector in conjunction with sync_all_dns to synchronize the source data with connections.

    Use this process, you.ll do the following:

    • Configure TDI to use the iterator connector during operations to synchronize the Profiles database form the source.

    • Use TDI mapping and extension attribute processing functions to upload data from the LDIF file to the Profiles database. Based on the source content, you will specify the mapping functions as needed.

    A sample connector for use with an LDIF file is supplied as samples/ldifSourceConnectorIterator.xml.

    The following is sample LDIF file content for a single user:

    dn: uid=asingh, cn=users, dc=ibm,dc=com
    cn: Allie Singh
    givenName: Allie
    sn: Singh
    employeeNumber: 24251
    ou: Office of the CEO
    departmentNumber: 10
    title: Administrative Assistant to George Bandini
    telephoneNumber: 1-301-555-1001
    mobile: 1-312-555-0302
    pager: 1-773-555-8840
    facsimileTelephoneNumber: 1-301-555-1002
    uid: asingh
    roomNumber: 1-400A
    workloc: ID
    countryName: USA
    mail: asingh@rennovations.com
    manager: uid=gbandini, cn=users, dc=ibm,dc=com

    In this example, using source data from am LDIF text file, the iterator connector is available but the lookup connector is not. TDI assembly lines that work in an iterative manner will read from the LDIF file, however assembly lines that must look up a particular user will not. For example, the collect_dns utility and the sync_all_dns utility will work but the populate_from_dn file utility will not because it also requires a lookup connector.

    Use the following procedure:

    1. Create or otherwise obtain the LDIF file from your source data repository, for example an LDAP database.

    2. Move the supplied ldifSourceConnectorIterator.xml connector file from the samples directory to the packages subdirectory.

    3. Add the following statement to the profiles_tdi.properties file:

      source_employees_file=your_file_name.ldif

    4. Open the map_dbrepos_from_source.properties file and configure mappings as needed based on the attributes in your source LDIF file. Note the following sample mapping for a single user:

      In this example, a guid field was not present in the LDIF file so the guid entry in the following sample is mapped to employeeNumber, which will enable processing. See Map fields manually and Create an iterator connector for details.

      deptNumber=departmentNumber
      displayName=cn
      distinguishedName=$dn
      email=mail
      faxNumber=facsimileTelephoneNumber
      givenName=given_name
      givenNames=given_name
      guid=employeeNumber
      #managerUid={func_map_to_db_MANAGER_UID}
      mobileNumber=mobile
      officeName=roomNumber
      #secretaryUid={func_map_to_db_SECRETARY_UID}
      surname=sn
      surnames=sn
      telephoneNumber=telephoneNumber
      title=title
      uid=uid

    5. Uncomment and change the following statement in the profiles_tdi.properties file to enable access to the connector:

      source_repository_iterator_assemblyline=ldifSourceConnectorIterator:/AssemblyLines/ldifSourceConnectorIterator

    6. Run a command to process the connector, such as sync_all_dns, to update the corresponding Profiles user data.

      Summary output will appear in the console and any errors generated will appear in the log file.


    Synchronize a subset of Profiles data

    You can synchronize an explicit set of Profiles users out of cycle from your scheduled synchronization plan supplying a list of users to synchronize to an alternate synchronization utility.

    While IBM Connections enables you to upload and synchronize Profiles user data from an LDAP or alternate source repository (such as an LDIF file) on a scheduled basis, you can also synchronize data for a small user subset using the alternative process described here.

    Typically the sync_all_dns command is used to synchronize the entire Profiles data set on a scheduled basis. If you need to synchronize a set of users, you can use the sample sync_dns_from_file command to accomplish the task. For example, you can use this utility, and a small user data subset, as a diagnostic tool when troubleshooting the synchronization process, making it easier to analyze trace output with a smaller sample size.

    In this example, you will synchronize a list of users using sync_dns_simple_file. Functionally, this process works as though you had run the sync_all_dns command.

    • If the user is found in the Profiles database but not in the source repository (for example LDAP), the specified delete action occurs.

    • If the user is found in the source repository (for example LDAP) but not in the Profiles database, specified adds occur as they would in an sync_all_dns action.

    • If the user is found in the source repository (for example LDAP) and also in the Profiles database, specified updates occur as they would in an sync_all_dns action.

    The file uses the same formatting as the existing delete_or_inactivate_employees.in file in the samples directory. See Delete or inactivate users in the Profiles database for details.

    Use the following procedure:

    1. Create your user synchronization source data fileyour_file.txt, for example sync_users_subset.txt, using the following format:

      $dn:cn=Amy Jones3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
      uid:Amy Jones3
      .
      $dn:cn=Amy Jones8,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
      uid:Amy Jones8 

    2. Save the completed your_file.txt file, for example sync_users_subset.txt.

    3. Open the profiles_tdi.properties file and reference your file and path using the sync_dns_simple_file statement; use the following format:

      sync_dns_simple_file=samples/your_file.ext

    4. Save the profiles_tdi.properties file.

    5. Run the sync_dns_from_file.bat or sync_dns_from_file.sh command.

      Summary output will appear in the console and any errors generated will appear in the log file.


    Use supplied scripts to delete inactive users based on inactivity length

    You can use supplied Tivoli Directory Integrator (TDI) scripts to surface and delete users who have been inactive for specified length of time. You might use this process to ensure that users who are no longer in the organization, according to LDAP, are deleted from the Profiles directory. If your organization plans to reuse UID values, or other unique profiles fields, you should permanently delete inactive users to so that these values can be reassigned to others.

    When you inactivate a user, their email field is cleared but other fields such as UID, GUID, and distinguished name are not. These users also remain listed in components such as Communities, Activities, and Profiles. After a specified length of time you may want to delete these inactive users completely from your other Connections components. You can use the revoke users sample to delete inactive users who meet the length of time criteria. For related information, see User life cycle details.

    After flagging a user as inactive, but prior to revoking or deleting that user, you can retrieve that user and their data. However, after revoking or deleting a user, you cannot retrieve that user or that user.s data.

    Typically the sync_all_dns utility is used to synchronize the Profiles data set on a scheduled basis. When a user leaves the organization, and is removed from the LDAP directory, by default the sync_all_dns utility inactivate that user by flagging them as inactive in the Profiles database and propagating this infomation to the other Connections components.

    In this example, you will use supplied scripts to delete inactive user(s) who were inactivated earlier than the specified number of days. This gives the organization a transition period, during which the users are in an inactive state. These users can then be deleted after the transition period. The transition period can be any value, in days. When the user is deleted, their UID and GUID identifiers are made available for reuse.

    See Delete or inactivate users in the Profiles database for related information.

    Use the following procedure:

    1. Copy the revoke_users.sh or revoke_users.bat, revoke_users.xml, and revoke_users.properties files to the Profiles TDI solution directory from the supplied samples directory.

    2. Optional: Run the revoke_users script with the validate parameter to check that you have installed the fixpacks required to run the revoke_users script with the revoke parameter. Results are sent to the logs/ibmdi.log file.

      See the following sample output:

      2012-06-19 11:22:03,076 INFO  [AssemblyLine.AssemblyLines/validate.1]
        +++++++++ VALID TDI SOLUTION +++++++++++

    3. Optional: Run the revoke_users script with the summary parameter to preview the users to be deleted before actually deleting them.

      This script creates the following two preview files:

      • revoke.ldif . lists the inactive users to be deleted from the Profiles database by the revoke_users revoke script. These are the inactive users who have been inactive for as long as or longer than the specified amount of time.

      • revoke_skip.ldif . lists the inactive users to not be deleted from the Profiles database by the revoke_users revoke script. These are the inactive users who have been inactive for less than the specified amount of time.

        The logs/ibmdi.log file is updated after every 10K user names processed.

      After flagging a user as inactive, but prior to revoking or deleting that user, you can retrieve that user and their data. However, after revoking or deleting a user, you cannot retrieve that user or that user.s data.

    4. Run the revoke_users script with the revoke parameter to delete the inactive users from the Profiles database.

      This script creates the same revoke.ldif and revoke_skip.ldif files as the revoke_users summary script. It then deletes the users listed in the revoke.ldif file from the Profiles database.


    Use the PhotoConnector

    Use the PhotoConnector to retrieve, create, update, and delete photo entries in the Photo table in the Profiles database.

    For information about how to configure your development environment for working with the IBM Tivoli Directory Integrator connectors, and where to place the connectors, see Set up your development environment.

    Database properties are read from the profiles_tdi.properties file, which must be configured prior to using the connector. The Profiles property store must be part of the configuration (.xml) file where your assembly lines are located. For related information, see General Concepts in the Tivoli Directory Integrator documentation. The PhotoConnector works with photos in the Profiles database. The mode setting of the connector determines what role the connector carries out in the assembly line. You can use the PhotoConnector in the following modes.

    Table 5. PhotoConnector modes

    Mode Description
    Iterator

    Iteratively scans data source entries, reads their attribute values, and delivers each entry to the appropriate AssemblyLine Flow section components.

    The available attributes that are returned in the work entry are in the iterator and lookup modes:

    • fileType - for example image/jpeg

    • image - specifies the byte array containing the photo contents

    • key - specifies the user.s key value

    • updated - specifies when the photo was last modified

    The dump_photos_to_files assembly line uses the Iterator mode.

    Lookup

    Fetches records from the Photo table in the Profiles database according to specified search criteria, which is the key attribute.

    The following attributes can be used for the search criteria:

    • fileType - for example image/jpeg

    • image - specifies the byte array containing the photo contents

    • key - specifies the user.s key value

    • updated - specifies when the photo was last modified

    The search (link) criteria must be the key attribute.

    Update

    Updates the photo for the user specified in the search criteria, that being the key attribute.

    One of the following additional attributes must be supplied:

    • The image attribute must contain the byte array containing the photo.

    • The linkStream must contain a URL reference to the photo.

    The load_photos_from_files assembly line uses the Update mode.

    The search (link) criteria is the same as the Lookup mode.

    Delete

    Deletes records in the Photo table in the Profiles database according to specified search criteria.

    The search (link) criteria is the same as the Lookup mode.

    updateToDB

    This mode has been deprecated, use the Update mode instead.

    1. To add the connector to an assembly line, create a new or open an existing assembly line and click Add Component in the Configuration Editor.

    2. Select Connectors, and then select PhotoConnector from the Components list.

    3. Enter a name for the connector in the Name field.

    4. Select a mode from the Mode list, and then click Finish.

    5. Continue with any additional development of your assembly line.


    Related tasks

  • Set up your development environment
  • Populate Profiles with photos


    Use the PronunciationConnector

    Use the PronunciationConnector to retrieve, create, update, and delete pronunciation entries in the Pronunciation table in the Profiles database.

    For information about how to configure your development environment for working with the IBM Tivoli Directory Integrator connectors, and where to place the connectors, see Set up your development environment.

    Database properties are read from the profiles_tdi.properties file, which must be configured prior to using the connector. The Profiles property store must be part of the configuration (.xml) file where your assembly lines are located. For related information, see General Concepts in the Tivoli Directory Integrator documentation. The PronunciationConnector writes changes to the Pronunciation table in the Profiles database. The mode setting of the connector determines what role the connector carries out in the assembly line. You can use the PronunciationConnector in the following modes.

    Table 6. PronunciationConnector modes

    Mode Description
    Iterator

    Iteratively scans data source entries, reads their attribute values, and delivers each entry to the appropriate AssemblyLine Flow section components. The available attributes that are returned in the work entry are in the iterator and lookup modes:

    In this mode, the PronunciationConnector connects to the Pronunciation table in the Profiles database, retrieves all the records, and handles them one by one.

    Lookup

    Fetches records from the Pronunciation table in the Profiles database according to specified search criteria.

    The PronunciationConnector only supports searches by uid and key.

    The search (link) criteria must be the key attribute.

    Update

    Updates the pronunciation records in the Pronunciation table in the Profiles database. The connector can update the database using the pronunciation file link, inputting it as an InputStream data type, or using the pronunciation content, inputting it as a byte data type.

    The search (link) criteria is the same as the Lookup mode.

    Delete

    Deletes records in the Pronunciation table in the Profiles database according to specified search criteria.

    The PronunciationConnector can only delete pronunciation records that are specified by key.

    The search (link) criteria is the same as the Lookup mode.

    updateToDB

    This mode has been deprecated, use the Update mode instead.

    1. To add the connector to an assembly line, open the assembly line, and then click Add Component in the Configuration Editor.

    2. Select Connectors, and then select PronunciationConnector from the Components list.

    3. Enter a name for the connector in the Name field.

    4. Select a mode from the Mode list, and then click Finish.

    5. If you want to add the connector to your project's connector library, right-click the Connectors folder in the Configuration Browser, and then select PronunciationConnector from the Components list.


    Use the CodesConnector

    Use the CodesConnector to retrieve, create, update, and delete code entries in various codes tables in the Profiles database.

    For information about how to configure your development environment for working with the IBM Tivoli Directory Integrator connectors, and where to place the connectors, see Set up your development environment. For additional information, see Supplemental user data for Profiles.

    Database properties are read from the profiles_tdi.properties file, which must be configured prior to using the connector. The Profiles property store must be part of the configuration (.xml) file where your assembly lines are located. For related information, see General Concepts in the Tivoli Directory Integrator documentation.

    The Codes Table Name menu option in the CodesConnector contains the choices Country, Department, EmployeeType, Organization, and WorkLocation. The CodesConnector requires that one of these table choices be assigned to the Codes Table Name field option. The table choice specified is used during CodesConnector operations. Each table has a different, but similar, schema. You can determine the schema of a particular table by making connections in the input or output map panels of the connector and then clicking Next to advance to the applicable record.

    The CodesConnector works with records in the COUNTRY, DEPARTMENT, EMP_TYPE, ORGANIZATION, and WORKLOC tables in the Profiles database. The mode setting of the connector determines what role the connector carries out in the assembly line. You can use the CodesConnector in the following modes.

    Table 7. CodesConnector modes

    Mode Description
    Iterator

    Connects to the codes table in the Profiles database, retrieves all the records, and handles them one by one.

    Lookup

    Fetches records from the codes table in the Profiles database according to specified search criteria.

    The search (link) criteria attribute is determined by the code table name specified in the connector panel. The following table name and their associated attribute are supported for use as the search criteria:

    • Country . countryCode

    • Department . departmentCode

    • EmployeeType . employeeType

    • Organization . orgCode

    • WorkLocation . workLocationCode
    Update

    Updates records in the codes table in the Profiles database.

    The search (link) criteria is the same as the Lookup mode.

    Delete

    Deletes records in the codes table in the Profiles database according to specified search criteria.

    The search (link) criteria is the same as the Lookup mode.

    updateToDB

    This mode has been deprecated in Connections 4; use Update mode instead.

    1. To add the connector to an assembly line, create a new or open an existing assembly line and click Add Component in the Configuration Editor.

    2. Select Connectors, and then select CodesConnector from the Components list.

    3. Enter a name for the connector in the Name field.

    4. Click Next.

    5. Select the desired table name from the list and click Finish.

    6. Continue with any additional development of your assembly line.


    Related tasks

  • Set up your development environment

    Manage profile content

    You can enable the active content filter to prevent users from embedding malicious content in text input fields in Profiles. You can also use administrative commands to update or remove inappropriate information in fields to which you do not have owner access.


    Filter active content in Profiles

    Profiles provides a filter that prevents users from creating rich text descriptions with malicious scripts that are executed when other users visit Profiles. You can enable or disable this component.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. The active content filter prevents a user from embedding malicious content such as JavaScript in the About me and Background text input fields. You can disable the filter to provide richer options for content in these fields.

    Disabling this filter introduces a vulnerability to malicious cross-site scripting (XSS) attacks.

    To configure active content filter settings, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. To configure the active content filter for Profiles, use the following command:

      ProfilesConfigService.updateConfig(property, value)

      ...where

      • property is one of the editable Profiles configuration properties.

      • value is the new value with which you want to set that property.

      The following table displays information regarding the active filter property and the type of data you can enter for it.

      Table 8. The active content filter property

      Option Description
      activeContentFilter.enabled

      Enables and disables filtering for active content of text entered into the About me and Background text input fields.

      This property takes a Boolean value: true or false. The value must be formatted in lowercase.

      For example, to disable filtering:

      ProfilesConfigService.updateConfig("activeContentFilter.enabled","false")

    4. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Profiles for information about how to save and apply your changes.


    Related tasks

  • Apply property changes in Profiles


    Remove inappropriate content

    Content management commands are used to update inappropriate information stored in the Profiles database, such as text displayed in the About Me and Background fields of the Profiles user interface. These administrative commands can also be used to delete inappropriate photos from the database. No file checkout or server restart is required when using the commands.

    To access configuration files, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. Profiles provides a number of administrative commands that allow you to remove offensive or unwanted content from the database.

    To update or delete content in the Profiles database, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands to remove or replace inappropriate or unwanted content from the Profiles database.

      ProfilesService.updateExperience(String user_email_addr, String new_content_for_experience_field)

      Replaces the existing experience text associated with a user's email address with alternate text enclosed by double quotes.

      Experience is the information contained in the Background area of a user's profile.

      For example:

      ProfilesService.updateExperience("ann_jones@company.com","This is new text that will be entered into the Background field for Ann.")

      Rich text cannot be entered with this command.

      ProfilesService.updateDescription(String user_email_addr, String new_content_for_description_field)

      Replaces the existing description text associated with a user's email address with alternate description text enclosed by double quotes.

      Description text is information contained on the About Me tab of a user's profile.

      For example:

      ProfilesService.updateDescription("ann_jones@company.com","This is new text that will be entered into the About Me tab for Ann.")

      Rich text cannot be entered with this command.

      ProfilesService.deletePhoto(String user_email_addr)

      Deletes image files associated with a user's email address. This command can be used only if the user has uploaded a photo to their profile. This command removes the photo.

      For example:

      ProfilesService.deletePhoto("john_doe@company.com")

    Configure features by profile type

    You can configure certain features in Profiles according to profile type.

    By modifying settings in profiles-policy.xml file, you can enable, disable, and set access control settings for the following Profiles features, according to profile type.


    Related

  • Add profile types


    Configure the recent updates feature by profile type

    Edit settings in profiles-policy.xml file to configure the recent updates feature according to profile type.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool.

    The recent updates feature allows users to connect with people in their network by posting messages to their profile and commenting on their status messages. As administrator, you can enable or disable the feature for specific profile types, depending on your organization's needs. You can also configure access control settings according to profile type.

    Profiles directory extensions must be enabled to support this capability. Extensions are enabled by default.

    Profiles policy contains two related settings that impact how a user is enabled to post a status update on their Profile page . profiles.board and profile.status.update. IBM recommends to have identical settings for both of these policies. In case of conflict between the two settings, the most restrictive setting is used. See Configuring the status update feature for related information.

    The following steps provide information about the properties that you can set for the recent updates feature, and the access levels and scopes that you can configure.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the recent updates feature as needed.

      profile.board

      Enables or disables the Profiles recent updates feature.

      Configuring this property does not affect the ability to post status messages.

      This property takes a string value. Possible values include:

      • true. Enables the recent updates feature for users with the specified profile type. When set to true, message posts display in the user interface.

      • false. Disables the recent updates feature for users with the specified profile type. When set to false, message posts do not display in the user interface. The access control level settings are also ignored when the feature is disabled.

      profile.board.write.message

      Controls user access to post messages.

      Access levels for this property can be defined using one of the following scopes:

      • none. No user can post messages to users with the specified profile type.

      • self. Users with the specified profile type can view and post messages in their own recent updates area. Administrators can also view and post messages in the recent updates area of users with the specified profile type.

      • colleagues_not_self. Only people who belong to the network of the user with the specified profile type, and who have the person role, can view and post messages to the user's recent updates area. Users with the specified profile type cannot post messages to their own recent updates area.
        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • colleagues_and_self. People who belong to the network of the user with the specified profile type, and who have the person role, can view and post messages to the user's recent updates area. Users with the specified profile type can also post messages to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_not_self. Users with the Person role in the News application can post messages to or view the recent updates area of users with the specified profile type. Users with the specified profile type cannot post messages to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_and_self. Users with the Person role in the News application, including self, can post messages to or view the recent updates area of users with the specified profile type. Users with the specified profile type can also post messages to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      profile.board.write.comment

      Controls user access to post comments to the recent updates area.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can post comments to the recent updates area of users with the specified profile type.

      • self. Users with the specified profile type can view and post comments to their own recent updates area. Administrators can also view and post comments to the recent updates area of users with the specified profile type.

      • colleagues_not_self. Only the people who belong to the network of the user with the specified profile type, and who have the person role, can view and post comments to the user's recent updates area. Users with the specified profile type cannot post comments to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • colleagues_and_self. People who belong to the network of the user with the specified profile type, and who have the person role, can view and post comments to the user's recent updates area. Users with the specified profile type can also post comments to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_not_self. Users with the Person role in the News application can post comments to and view the recent updates area of users with the specified profile type. Users with the specified profile type cannot post comments to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_and_self. Users with the Person role in the News application, including self, can post comments to and view the recent updates area of users with the specified profile type. Users with the specified profile type can also post comments to their own recent updates area.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      For example:

      <feature name="profile.board">
        <profileType type="default" enabled="true">
         <acl name="profile.board.write.message" scope="colleagues_and_self" /> 
         <acl name="profile.board.write.comment" scope="colleagues_and_self" /> 
        </profileType>
        <profileType type="contractor" enabled="true">
         <acl name="profile.board.write.message" scope="person_and_self" /> 
         <acl name="profile.board.write.comment" scope="colleagues_and_self" /> 
        </profileType>
        <profileType type="visitor" enabled="false" /> 
      </feature>
      This code sample enables the recent updates feature for the default profile type, but restricts access to post messages and comments to people in the profile owner's network who have the person and the profile owner. The recent updates feature is also enabled for the contractor profile type, but access to post messages is restricted to users with the person role, including the profile owner. Access to post comments is restricted to the profile owner, and people in the profile owner's network who have the person role. The recent updates feature is disabled for the visitor profile type.

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Related tasks

  • Manage widgets in Profiles


    Configure the following feature by profile type

    Edit settings in profiles-policy.xml file to configure the following feature according to profile type.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool. When the following feature is enabled, users can follow people and content that they are interested in to get the latest updates about them. In this release of IBM Connections, the following feature is enabled by default and you cannot disable it. However, you can configure access control settings for the feature according to profile type.

    These steps provide information about the properties that you can set and the access levels that you can configure.

    1. Use the wsadmin client to access the Profiles configuration files.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    2. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    3. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    4. Edit the following properties for the following feature as needed.

      profile.following

      This property is always enabled in this release so that users are always able to see who they are following and who their followers are. You can use the profile.following.add access scope to control who can follow users of the specified profile type.

      profile.following.add

      Controls access to follow users with the specified profile type.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can follow users with the specified profile type.

      • self. Users with the specified profile type can follow themselves to subscribe to their own updates. Administrators can also follow users with the specified profile type.

      • colleagues_not_self. Only people who belong to the network of the user with the specified profile type, and who have the person role, can follow the user. Users with the specified profile type cannot follow themselves.
        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • colleagues_and_self. People who belong to the network of the user with the specified profile type, and who have the person or self role, can follow the user. Users of the specified profile type can also follow themselves to subscribe to their own updates.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_not_self. Only users with the person J2EE role can post follow users with the specified profile type. Users with the specified profile type cannot follow themselves.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_and_self. Users with the person J2EE role can follow users with the specified profile type. Users of the specified profile type can also follow themselves to subscribe to their own updates.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      For example:

      <feature name="profile.following">
        <profileType type="default" enabled="true">
         <acl name="profile.following.add" scope="person_not_self" /> 
        </profileType>
        <profileType type="contractor" enabled="true">
         <acl name="profile.following.add" scope="colleagues_not_self" /> 
        </profileType>
        <profileType type="visitor" enabled="false">
         <acl name="profile.following.add" scope="none" /> 
        </profileType>
      </feature>
      This code sample allows only users who have the person J2EE role to follow users with the specified profile type. For users with the contractor profile type, only the people who belong to the user's network can follow users of that profile type. Following is disabled for users with the visitor profile type.

    5. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    6. To exit the wsadmin client, type exit at the prompt.

    7. Stop and restart the Profiles server.


    Configure the networking feature by profile type

    Edit settings in profiles-policy.xml file to configure the networking feature according to profile type.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool. When networking is enabled, users can invite other users to join their network. The networking feature is enabled by default and you cannot disable it. However, you can configure access control settings for the feature according to profile type.

    The following steps provide information about the properties for the networking feature, and the access levels and scopes that you can configure.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the networking feature as needed.

      profile.colleague

      This property is always set to enabled to ensure that users are always able to see their possible colleagues. You cannot set the property to disabled. However, you can use the profile.colleague.connect access scope to control who can invite the user to be a colleague.

      profile.colleague.connect

      Controls user access to invite people to join their network.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can invite a user with the specified profile type to join their network. If the user has an existing network of colleagues, it is not available.

        Set the scope to none does not make a user's network read-only. If you need to lock the state of a user, note that users can still remove contacts from their network when you set the scope to none.

      • person_not_self. Only users with the person J2EE role can invite users with the specified profile type to join their network. The profile owner cannot invite themselves to join their own network.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the admin role.

      For example:

      <feature name="profile.colleague">
        <profileType type="default" enabled="true">
         <acl name="profile.colleague.connect" scope="person_not_self" /> 
        </profileType>
        <profileType type="contractor" enabled="true">
         <acl name="profile.colleague.connect" scope="none" /> 
        </profileType>
        <profileType type="visitor" enabled="false">
         <acl name="profile.colleague.connect" scope="none" /> 
        </profileType>
      </feature>
      This code sample enables the networking feature for users with the default profile type, and enables only users with the person J2EE role to invite the profile owner to join their network. Networking is also enabled for the contractor profile type, although no one can invite contractor users to join their network. Networking is disabled for users with the visitor profile type.

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Configure the profile photo feature by profile type

    Edit settings in profiles-policy.xml file to configure the profile photo feature according to profile type.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. When the profile photo feature is enabled, users can enhance their profile page by adding a picture of themselves. As administrator, you can enable or disable this feature for specific profile types, depending on your organization's needs. You can also configure access control settings for the profile photo feature according to profile type.

    The following steps provide information about the properties that you can set for the profile photo feature, and the access levels and scopes that you can configure.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the profile photo feature as needed.

      profile.photo

      Enables or disables the profile photo feature.

      This property takes a string value. Possible values include:

      • true. Enables the photo feature for users with the specified profile type. The user interface displays the user's photo and provides options for editing the photo.

      • false. Disables the photo feature for users with the specified profile type. The user interface does not display the user's photo or options for editing the photo. A generic photo image is displayed in place of the user's photo.

      profile.photo.update

      Control access to view the photo. In additional to the scope attribute for this access control, dissallowNonAdminIfInactive can be used to indicate whether photos for inactive users can be viewed. Administrative users can view photos regardless of the configuration.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can update the profile photo of users with the specified profile type.

      • self. Users with the specified profile type can update their own profile photo. Administrators can also update the profile photo of users with the specified profile type.

      profile.photo.view

      Controls access to view the photo.

      In additional to the scope attribute for this access control, dissallowNonAdminIfInactive can be used to indicate whether photos for inactive users can be viewed. Administrative users can view photos regardless of the configuration.

      In the following photo policy sample, users who have been assigned the reader role can view active user's photos with the default profile type, but photos for inactive users are only viewable by users who have been assigned theadmin role. When a user's photo is not viewable, the default gray photo image is displayed.

      <profileType type="default" enabled="true">
      <acl name="profile.photo.view" scope="reader" dissallowNonAdminIfInactive="true"/>
      <acl name="profile.photo.update" scope="self" />
      </profileType>

      The following sample enables the profile photo feature for the default profile type, but restricts access to update profile photos to profile owners and administrators. For users with the contractor profile type, the profile photo is enabled, but no access is provided to update the profile photo for users of this profile type. The profile photo feature is disabled for users with the visitor profile type, and no one can update the profile photo for users of this profile type.

      <feature name="profile.photo">
         <profileType type="default" enabled="true">
            <acl name="profile.photo.update" scope="self" />
         </profileType>
         <profileType type="contractor" enabled="true">
            <acl name="profile.photo.update" scope="none" />
         </profileType>
         <profileType type="visitor" enabled="false">
            <acl name="profile.photo.update" scope="none" />
         </profileType>
      </feature>

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Configure the pronunciation feature by profile type

    Edit settings in profiles-policy.xml file to configure the pronunciation feature according to profile type.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool. When the pronunciation feature is enabled, users can upload a recording of their name being pronounced correctly to their profile. You can enable or disable this feature for specific profile types. You can also configure access control settings for the pronunciation feature according to profile type.

    The following steps provide information about the properties that you can set for the pronunciation feature, and the access levels and scopes that you can configure.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the pronunciation feature as needed.

      profile.pronunciation

      Enables or disables the profile pronunciation feature.

      This property takes a string value. Possible values include:

      • true. Enables the pronunciation feature for users with the specified profile type. The user interface displays an icon for the user's pronunciation file and provides options for editing the file.

      • false. Disables the pronunciation feature for users with the specified profile type. The feature does not display in the user interface.

      profile.pronunciation.update

      Controls user access to update the profile pronunciation file.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can update the pronunciation file of users with the specified profile type.

      • self. Users with the specified profile type can update their own pronunciation file. Administrators can also update the pronunciation file of users with the specified profile type.

      For example:

      <feature name="profile.pronunciation">
         <profileType type="default" enabled="true">
            <acl name="profile.pronunciation.update" scope="self" />
         </profileType>
      </feature>
      This code sample enables the pronunciation feature for users with the default profile type, but restricts the ability to update pronunciation files to profile owners and administrators.

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Configure the reporting structure feature by profile type

    Edit settings in profiles-policy.xml file to configure the reporting structure feature according to profile type. You can specify whether a user's manager information is available, and whether a manager's direct reports are available, for a specific profile type.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. When the report-to feature is enabled, users can view the position of other users within the organization using the report-to chain information displayed on their profile page. When the people-managed feature is enabled, users can view the direct reports of a particular manager. As administrator, you can enable or disable these reporting structure features for specific profile types.

    The following steps provide information about the properties that you can set for the reporting structure feature.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the reporting structure feature.

      profile.reportTo

      Enables or disables the display of the user's report-to information on their profile page.

      This property takes a string value. Possible values include:

      • true. Report-to information is available for the users with this profile type. The user interface displays the report-to information, and the user's service document contains the reporting structure links.

      • false. Report-to information is not available for the users with this profile type. The user interface still displays the Report-to-Chain widget, but with only the profile owner shown. The report-to information is hidden, as if the profile owner does not have a manager. If you are disabling this option, consider also disabling the widget for this profile type in the widgets-config.xml file. For more information, see Managing widgets in Profiles.

      For example, to enable the display of report-to information for users with the default profile type:

      <feature name="profile.reportTo">
         <profileType type="default" enabled="true">
         </profileType>
      </feature>

      profile.peopleManaged

      Enables or disables the display of direct reports for managers with the specified profile type.

      This property takes a string value. Possible values include:

      • true. People-managed information is available for the users with this profile type, when they are managers. The user interface displays the report-to information, and the user's service document contains the reporting structure links.

      • false. People-managed information is not available for managers with this profile type. The user interface still displays the Report-to Chain widget, but with only the current profile owner shown. The people-managed information is hidden, as if the user does not have any direct reports.

      For example, to enable the display of people-managed information for managers with the default profile type:

      <feature name="profile.peopleManaged">
         <profileType type="default" enabled="true">
         </profileType>
      </feature>

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Configure the status update feature by profile type

    Edit settings in profiles-policy.xml file to configure the status update feature according to profile type.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool. Profiles users can keep people in their network and the wider organization informed about their latest activities by posting status messages. You can control whether users can update their status message by enabling or disabling status updates for specific profile types. You can also configure access control settings for status updates according to profile type.

    The following steps provide information about the properties you can set for the status update feature, and the access levels you can configure.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

    5. Edit the following properties for the status update feature as needed.

      profile.status

      Enables or disables the status update feature.

      This property takes a string value. Possible values include:

      • true. Enables the status update feature for users with the specified profile type. The user interface for status messages displays.

      • false. Disables the status update feature for users with the specified profile type. The user interface for status messages does not display. The access control level settings are also ignored when this feature is disabled.

      profile.status.update

      Controls user access to update status messages.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can update the status message of users with the specified profile type.

      • self. Users with the specified profile type can update their own status message. Administrators can also update the status message of users with the specified profile type.

      For example:

      <feature name="profile.status">
        <profileType type="default" enabled="true">
         <acl name="profile.status.update" scope="self" /> 
        </profileType>
      </feature>
      This code sample enables the status update feature for the default profile, but restricts the ability to update status messages to profile owners and administrators.

    6. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Configure the tagging feature by profile type

    Edit settings in profiles-policy.xml file to configure the tagging feature for specific profile types.

    To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin tool. The tagging feature allows users to assign meaningful keywords to their own profile and other users' profiles, making it easier to find people with a particular interest or expertise. You can control whether users can tag themselves and others by enabling or disabling the tagging feature for specific profile types. You can also configure access control settings for this feature according to profile type.

    To enable or disable tagging by profile type, complete the following steps:

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out profiles-policy.xml file:

      ProfilesConfigService.checkOutPolicyConfig("<working_directory>", "cell_name")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the IBM WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutPolicyConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open profiles-policy.xml file using a text editor, from the temporary directory to which you checked it out.

      Edit the following properties for the tagging feature as needed.

      profile.tag

      Controls user access to add tags to their profile.

      Access levels for this property can be defined using one of the following scopes:

      • none. No one can tag the profile of users with the specified profile type.

      • self. Users with the specified profile type can tag their own profiles. Administrators can also tag the profiles of users with the specified profile type.

      • colleagues_not_self. Only people who belong to the network of the user with the specified profile type, and who have the person role, can tag the user's profile. Users with the specified profile type cannot tag their own profiles.
        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • colleagues_and_self. People who belong to the network of the user with the specified profile type, and who have the person role, can tag the user's profile. Users with the specified profile type can tag their own profiles.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_not_self. Users with the person J2EE role can tag the profile of users with the specified profile type. Users with the specified profile type cannot tag their own profiles.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      • person_and_self. Users with the person J2EE role can tag the profile of users with the specified profile type. Users with the specified profile type can also tag their own profiles.

        If resourceOwner is specified on the access check, the resource owner constraint must also be met, unless the user has the self role.

      For example:

      <feature name="profile.tag">
        <profileType type="default" enabled="true">
         <acl name="profile.tag.add" scope="person_and_self" /> 
        </profileType>
        <profileType type="contractor" enabled="true">
         <acl name="profile.tag.add" scope="colleagues_and_self" /> 
        </profileType>
        <profileType type="visitor" enabled="false">
         <acl name="profile.tag.add" scope="none" /> 
        </profileType>
      </feature>
      This code sample enables tagging for users with the default profile type. Users with the person J2EE role can tag users of the default profile type, and default users can tag their own profiles. Tagging is also enabled for users with the contractor profile type. People in the profile owner's network who have the person role can add tags to profiles of the contractor type, and contractor users can tag their own profiles. Tagging is disabled for users with the visitor profile type.

    5. Save your changes and check profiles-policy.xml file back in :

      ProfilesConfigService.checkInPolicyConfig()

    6. To exit the wsadmin client, type exit at the prompt.

    7. Stop and restart the Profiles server.


    Related tasks

  • Manage widgets in Profiles

    Configure widgets in Profiles

    To configure existing widgets or to make custom widgets available for use in Profiles, you modify settings in the widgets-config.xml file.


    Related tasks

  • Configure the Recent Posts widget


    Check out the widgets-config.xml file for Profiles

    The widgets-config.xml files contains configuration settings for each of the widgets supported by Profiles. To update settings in the file, check the file out and, after making changes, check the file back during the same wsadmin session as the checkout for the changes to take effect.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for details. The widgets-config.xml file defines the widgets available for use in Profiles and Communities. You can edit configuration settings in this file to perform various tasks. For example, if you want to make custom widgets available, you define the widgets in this file. You also edit settings in this file if you want to configure the Recent Posts widget to only display tabs for the applications included in your deployment. For more information, see Configuring the Recent Posts widget.

    To configure settings in the widgets-config.xml file for Profiles.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out the widget configuration file:

      ProfilesConfigService.checkOutWidgetConfig("<working_directory>", "<cell_name>")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutWidgetConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Navigate to the temporary directory in which you saved the widgets-config.xml file, and then open the file in a text editor and make the required changes.

    5. Save your changes and check the widgets-config.xml file back in :

      ProfilesConfigService.checkInWidgetConfig()

    6. To exit the wsadmin client, type exit at the prompt.

    7. Stop and restart the Profiles server.


    Related tasks

  • Use the widgets-config.xml file for Communities
  • Configure the Recent Posts widget
  • Manage widgets in Profiles


    Manage widgets in Profiles

    Configure settings in the widget definition file, widgets-config.xml, when you want to modify the widgets that display in the Profiles application.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details. The widgets-config.xml file contains information about widget definitions, widget attributes, widget location, default widget templates, and page definitions. Each widget has a corresponding <widgetDef> element that contains the attributes for the widget. When you want to edit the widget, enable or disable it, or move it to a different location, you need to update the corresponding <widgetDef> element in the widgets-config.xml file.

    The widgets-config.xml file is stored in the following location:

    WAS_HOME\profiles\AppSrv01\config\cells\CELL_NAME\LotusConnections-config\widgets-config.xml

    To edit the widgets that display in Profiles, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out the widget configuration file:

      ProfilesConfigService.checkOutWidgetConfig("<working_directory>", "<cell_name>")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutWidgetConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Navigate to the temporary directory in which you saved the widgets_config.xml file, and then open the file in a text editor.

    5. Do one of the following:

      • To edit a widget's properties, look for the corresponding <widgetDef> element, and then modify the widget attributes and parameters as needed. For information about the attributes and parameters, see Profiles widget attributes.

      • To associate a widget with a different profile type, look for the relevant <widgetDef> element, and then modify the value of the resourceSubType attribute. For information about the resourceSubType attribute, see Profiles widget attributes.

      • To move a widget to a different location, look for the relevant <widgetDef> element, and then modify the value of the pageId and uiLocation attributes. For information about these attributes, see Profiles widget attributes.

      • To disable a widget, look for the relevant <widgetDef> element and either delete the element or comment it out of the code.

    6. Save your changes and check the widgets-config.xml file back in :

      ProfilesConfigService.checkInWidgetConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Example

    <layout resourceSubType="default">
           <page pageId="searchView">
                    <widgetInstance uiLocation="col1" defIdRef="commonTags"/>
                    <widgetInstance uiLocation="col3" defIdRef="sand_DYK"/>
                    <widgetInstance uiLocation="col3" defIdRef="sand_recomItems"/>
           </page >
           <page pageId="profilesView">
                    <widgetInstance uiLocation="col1" defIdRef="socialTags"/>
                    <widgetInstance uiLocation="col1" defIdRef="sand_thingsInCommon"/>
                    <widgetInstance uiLocation="col2" defIdRef="multiWidget"/>
                    <widgetInstance uiLocation="multiWidget" defIdRef="board"/>
                    <widgetInstance uiLocation="multiWidget" defIdRef="contactInfo"/>
                    <widgetInstance uiLocation="multiWidget" defIdRef="backgroundInfo"/>
                    <widgetInstance uiLocation="multiWidget" defIdRef="multiFeedReader"/>
                    <widgetInstance uiLocation="col3" defIdRef="sand_socialPath"/>
                    <widgetInstance uiLocation="col3" defIdRef="reportStructure"/>
                    <widgetInstance uiLocation="col3" defIdRef="friends"/>
                    <widgetInstance uiLocation="col3" defIdRef="linkRoll"/>
           </page >
           <page pageId="searchView">
                    <widgetInstance uiLocation="col1" defIdRef="commonTags"/>
           </page >
           <page pageId="networkView">
                    <widgetInstance uiLocation="col1" defIdRef="sand_DYK"/>
           </page >
           <page pageId="editProfileView">
                    <widgetInstance uiLocation="col1" defIdRef="socialTags"/>
                    <widgetInstance uiLocation="col1" defIdRef="sand_thingsInCommon"/>
                    <widgetInstance uiLocation="col3" defIdRef="sand_socialPath"/>
                    <widgetInstance uiLocation="col3" defIdRef="reportStructure"/>
                    <widgetInstance uiLocation="col3" defIdRef="friends"/>
                    <widgetInstance uiLocation="col3" defIdRef="linkRoll"/>
           </page >
    </layout>


    Related

  • Add custom widgets to Profiles

  • Profiles widget attributes


    Profiles widgets

    The following table lists the widgets that are available for the Profiles application.

    You can edit, enable or disable, and change the location of the following Profiles widgets by configuring settings in the widgets-config.xml file. For more information, see Managing widgets in Profiles.

    Table 9. Profiles widgets

    User interface element Widget defIdRef Description
    Organization Tags widget commonTags Displays the tags for the entire organization. This widget is visible on the Directory page.
    Do You Know widget sand_DYK Recommends people for users to add to their network. This widget is visible on the Directory page.
    Tags widget socialTags Displays the tags associated with a specific profile.
    Things in Common widget sand_thingsInCommon Displays a list of the things that a user has in common with another user.
    Tabs widget multiWidget Displays the tabs in the center section of the profile view page. By default, this tabbed section displays the following widgets:

    • Recent Updates

    • Contact Information

    • Background
    You can include additional widgets as part of the Tabs widget if required.
    Recent Updates widget board Displays the latest updates to the profile owner's status message, and messages or comments that other users have posted. Also displays a status message for actions and posts of users that the profile owner follows and from content the profile owner is a member of, such as communities, blogs, and wikis.
    Contact Information widget contactInfo Displays the profile owner's contact information, such as name, job title, company, location, telephone numbers, and email addresses.
    Background widget backgroundInfo Displays the profile owner's background information, such as work experience, technical skills, languages spoken, interests, past work experience, and education.
    Who Connects Us widget sand_socialPath Displays the social path that links two users in IBM Connections.
    Report-to Chain widget reportStructure Displays the profile owner's position in the organization.
    Network widget friends Displays a selection of the people in the profile owner's network.
    My Links widget linkRoll Displays a list of external links that the profile owner has included as part of their profile.


    Configure the Recent Posts widget

    Configure the Recent Posts widget to display multiple feeds in a user's profile. The widget can be extended to display additional feeds from IBM Connections applications and external services as required.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. The Recent Posts widget that displays on a user's profile page provides an aggregated summary of that user's recent activity in the different IBM Connections applications. The widget also displays the latest updates from content that the profile owner is a member of, such as communities and wikis. The widget only displays updates for content that is publicly accessible.

    The Recent Posts widget is automatically configured to provide feeds from all the IBM Connections applications, but you can configure it to display information for only those applications that are included in your deployment.

    To configure the Recent Posts widget, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out the widget configuration file:

      ProfilesConfigService.checkOutWidgetConfig("<working_directory>", "<cell_name>")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutWidgetConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Open widgets-config.xml in a text editor, and specify the widget attributes using the information in the following tables. You can find the configuration section for this component under config > widgets > definitions > widgetDef > defId = multiFeedReader > configData.

      Table 10. Recent posts widget attributes

      Attribute Description
      serviceNameResourceId The resource string that specifies the name of the given feed that is displayed in the tab.
      serviceNameFeedUrl The feed URL for the specified IBM Connections application. A standard URL can be used, or a serviceNameSvcRef parameter can be used if the serviceName has been defined in the lotusConnections-config.xml file.
      Set the following URL parameters:

      Table 11. Recent posts widget URL parameters

      Parameter Description
      email A substitution variable for the user email displayed. This is used as a placeholder in the URL; it is replaced at runtime.
      serviceNameSvcRef A substitution variable for the URL value that is replaced at runtime. This parameter is retrieved from the lotusConnections-config.xml file for the given IBM Connections application.
      For example:

      <widgetDef defId="multiFeedReader" url="{contextRoot}/widget-catalog/multifeedreader.xml?version={version}">
        <itemSet>
          <item name="numberOfEntriesToDisplay" value="5" />
          <item name="communityResourceId" value="communityResourceId"/>
          <item name="communityFeedUrl" value="{communitiesSvcRef}/service/atom/communities/all?userid={userid}&amp;ps=5"/>
          <item name="dogearResourceId" value="dogearResourceId"/>
          <item name="dogearFeedUrl" value="{dogearSvcRef}/atom?userid={userid}&amp;access=any&amp;sort=date&amp;sortOrder=desc&amp;ps=5&amp;showFavIcon=true{appLangParam}"/>
          <item name="blogsResourceId" value="blogsResourceId"/>
          <item name="blogsFeedUrl" value="{blogsSvcRef}/roller-ui/feed/{userid}?order=asc&amp;maxresults=5&amp;sortby=0"/>
          <item name="activitiesResourceId" value="activitiesResourceId"/>
          <item name="activitiesFeedUrl" value="{activitiesSvcRef}/service/atom2/activities?public=only&amp;userid={userid}&amp;authenticate=no&amp;ps=5"/>
          <item name="filesResourceId" value="filesResourceId"/>
          <item name="filesFeedUrl" value="{filesSvcRef}/basic/anonymous/api/userlibrary/{userid}/feed?pagesize=5"/>
        </itemSet>
      </widgetDef>

    5. To remove an application feed, comment out or delete the <serviceNameResourceId> and <serviceFeedUrl> attributes.

      To comment out the attributes, use the <!-- XML notation to open the comment and --> to close the comment.

      In the following example, feeds from the Activities and Files applications are removed from the widget:

      <!--  <item name="activitiesResourceId" value="activitiesResourceId"/>
            <item name="activitiesFeedUrl" value="{activitiesSvcRef}/service/atom2/activities?public=only&amp;userid={userid}&amp;authenticate=no&amp;ps=5"/>                    
            <item name="filesResourceId" value="filesResourceId"/>
            <item name="filesFeedUrl" value="{filesSvcRef}/basic/anonymous/api/userlibrary/{userid}/feed?pagesize=5"/>  -->
        </itemSet>
      </widgetDef>

    6. Save your changes and check the widgets-config.xml file back in :

      ProfilesConfigService.checkInWidgetConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    Related

  • Configure widgets in Profiles

  • Apply property changes in Profiles
  • Check out the widgets-config.xml file for Profiles
  • Manage widgets in Profiles


    Add custom widgets to Profiles

    Extend the functionality of the Profiles application by adding custom widgets.

    You can use custom widgets to bring additional functionality to Profiles. Custom widgets must use the iWidget specification, which uses technology based on JavaScript, XML, HTML, and CSS. The widget files are stored on an HTTP server. The widgets can be bundled as EAR applications and deployed on IBM WebSphere Application Server. They can also be hosted in LAMP, .NET, and other environments.

    You need to register the widgets developed by iWidget developers to make them available for use in IBM Connections. You do this by configuring the widget attributes defined by the iWidget developer in the widgets-config.xml file.

    Profiles supports the use of mandated widgets only. Mandated widgets can be placed in any of the columns on the My Profile, Directory, and My Network pages. This type of widget exists in every profile and cannot be removed or hidden. Mandated widgets can also exist outside a profile, for example, they can show up in a search results page.


    Related

  • Add custom widgets to Communities

  • Manage widgets in Profiles


    Enable custom widgets for Profiles

    To make custom widgets available for use in Profiles, you need to configure the widgets in the widget definition file, widgets-config.xml.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details.

    The widgets-config.xml file contains information about widget definitions, widget attributes, widget location, default widget templates, and page definitions. Custom widget attributes are defined by the widget developer but, as administrator, you need to configure the widgets by adding a <widgetDef> element containing the appropriate attributes for each widget in the widget configuration file. The file is stored in the following location:

    WAS_HOME\profiles\AppSrv01\config\cells\CELL_NAME\LotusConnections-config\widgets-config.xml

    You can integrate a custom widget as part of IBM Connections and you can also integrate the widget as an external application. To integrate the widget inside the IBM Connections application, your widget must provide a full page mode. To integrate the widget as an external application, you must use a navBarLink attribute to register a navigation link along with your widget configuration information.

    To configure a custom widget for Profiles, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following command to check out the widget configuration file:

      ProfilesConfigService.checkOutWidgetConfig("<working_directory>", "<cell_name>")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files will be copied. The files are kept in this working directory while you make changes to them.

      • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required.
      For example:

      ProfilesConfigService.checkOutWidgetConfig("/wsadminoutput", "jdoe30Node02Cell")

    4. Navigate to the temporary directory in which you saved the widgets_config.xml file, and then open the file in a text editor.

    5. Define the custom widget by specifying a resource type of profile and adding a <widgetDef> element using the attributes and parameters defined in Profiles widget attributes. When adding custom strings using the resource bundle loader, the value of the category, description, and widgetDef attributes in the <widgetDef> element are used as the resource key for your custom bundle. For more information about adding widget strings, see Add custom strings for widgets and other specified scenarios.

      For example:

      <config id="widgets">
          <resource type="profile">
              <widgets>
                <definitions>
                  <widgetDef defId="HelloWorld" 
                     primaryWidget="false" modes="view fullpage edit search"  
                     url="{contextRoot}/comm.widgets/helloWorld/HelloWorld.xml?version={version}"/> <!-- XML attribute with substitution variables -->
                </definitions>
                <layout resourceSubType="default">
                  <page pageId="profilesView">
                     <widgetInstance uiLocation="col3" defIdRef="reportStructure"/>
                     <widgetInstance uiLocation="col3" defIdRef="friends"/>
                     <widgetInstance uiLocation="col1" defIdRef="socialTags"/>
                     <widgetInstance uiLocation="col3" defIdRef="linkRoll"/>
                     <widgetInstance uiLocation="col2" defIdRef="multiFeedReader"/>
                  </page>
                  <page pageId="searchResultView">
                     <widgetInstance uiLocation="col1" defIdRef="commonTags"/>
                  </page>
                  <page pageId="searchView">
                     <widgetInstance uiLocation="col1" defIdRef="commonTags"/>
                  </page>
                 </layout>
              </widgets>
          </resource>
          .....
      </config>
      The url, navBarLink, and item or @value XML attributes can be parameterized using substitution variables. For more information about the substitution variables that you can use, see Profiles widget configuration variables.

    6. Save your changes and check the widgets-config.xml file back in :

      ProfilesConfigService.checkInWidgetConfig()

    7. To exit the wsadmin client, type exit at the prompt.

    8. Stop and restart the Profiles server.


    What to do next

    If you are adding widgets that are hosted on third-party servers, then you might need to update your proxy configuration. For more information on configuring the Ajax proxy for Profiles, see Configuring the AJAX proxy for a specific application.


    Related tasks

  • Configure the AJAX proxy for a specific application
  • Manage widgets in Profiles

  • Profiles widget attributes


    Profiles widget configuration variables

    The following table lists the configuration variables that can be used for the url, navBarLink, helpLink, and item or @value attributes when configuring a third-party widget for integration with Profiles. The @value attribute refers to the value attribute in the item of the itemSet configuration elements in the widgets-config.xml file.

    Table 12. Profiles widget configuration variables

    Variable Description
    resourceId The profileUuid of the profile in use.
    lastMod The timestamp for the last time that the profile was updated.
    userid The IBM Connections user ID of the logged-in user. This variable is returned as undefined if the user is not logged in.
    email The email address of the logged-in user. This variable is returned as undefined if the user is not logged in.
    version The timestamp form, versionStamp, in LotusConnections-config.xml. This is updated on customizations and upgrades to ensure that static content URLs are updated.
    lang The language parameter.
    webresourcesSvcRef The service reference for the Common application as defined in LotusConnections-config.xml. For example, http://myserver.com/connections/resources.
    contextRoot The context root of the Profiles application. For example: /profiles.
    communitiesSvcRef The service reference for the Communities application, as defined in LotusConnections-config.xml. For example: http://myserver.com/communities.
    profilesSvcRef The service reference for the Profiles application, as defined in LotusConnections-config.xml. For example: http://myserver.com/profiles.
    dogearSvcRef The service reference for the Bookmarks application, as defined in LotusConnections-config.xml. For example: http://myserver.com/dogear.
    blogsSvcRef The service reference for the Blogs application, as defined in LotusConnections-config.xml. For example: http://myserver.com/blogs.
    activitiesSvcRef The service reference for the Activities application, as defined in LotusConnections-config.xml. For example: http://myserver.com/activities.
    forumsSvcRef The service reference for the Forums application, as defined in LotusConnections-config.xml. For example: http://myserver.com/forums.
    filesSvcRef The service reference for the Files application, as defined in LotusConnections-config.xml. For example: http://myserver.com/files.
    wikisSvcRef The service reference for the Wikis application, as defined in LotusConnections-config.xml. For example: http://myserver.com/wikis.
    opensocialSvcRef The service reference for the Status Updates application, as defined in LotusConnections-config.xml. For example: http://myserver.com/opensocial.


    Profiles widget attributes

    The following tables list the widget elements that you can configure when enabling, disabling, editing, or moving widgets in the Profiles application. These elements are configured in the widgets-config.xml file.

    Table 13. The widget definition element

    Attribute Description Required
    defId The widget name, which must be unique. The defId attribute is also used as a title or a resource bundle key.

    This attribute takes a string value.

    Yes
    primaryWidget Specifies that the widget displays in the center column of the page. The default value is true. No
    description Description of the widget that displays in the widget palette. This attribute uses the custom string framework. For more information about adding widget strings, see Add custom strings for widgets and other specified scenarios. No
    category The category in which the widget is placed in the widget palette. This attribute uses the custom string framework. For more information about adding widget strings, see Add custom strings for widgets and other specified scenarios. No
    requires Specifies which IBM Connections applications are required for the widget to function. The XML attribute values must match the serviceReference values in LotusConnections-config.xml. No
    url Specifies the location of the widget descriptor. This XML attribute can be parameterized with substitution variables.

    This attribute takes a string value.

    Yes
    modes Specifies the modes that are supported by the custom widget. Possible modes include:

    • view. This mode enables the widget to display on the profile overview page.

    • search. This mode integrates the widget into a community's search results page. Each widget displays as a separate tab on the page.

    • fullpage. This mode integrates the widget into the navigation bar. When users click the widget link in the navigation bar, the widget displays in a full page view in the community.

    • edit. This mode enables the Edit menu option in the widget's action menu, allowing community owners to edit the preferences of the widget inline, directly from the community's Overview page. The widget is also integrated in to the Edit Community page as a separate tab.
    No
    uniqueInstance Specifies whether the widget supports multiple instances on the same page. The default value is true. No
    resourceOwnerWidget Specifies whether the widget should be seen only by the profile owner. Set this to true or false as required. No
    navBarLink Specifies the URL to an external application. A link to this URL is added to the navigation bar when the widget is part of the community. The URL can contain substitution variables. No
    helpLink Specifies the URL to an HTML file containing help documentation for the widget. The help opens in a pop-up window. This parameter can contain subvariables. It can also be parameterized with substitution variables. No
    showInPalette Specifies if the widget should be displayed in the content palette. No
    loginRequired Specifies that the widget displays only when users are logged in. No
    bundleRefId The resource bundle reference ID that is defined in LotusConnections-config.xml. This ID is used to determine the bundle strings for the widget category, widget description, and widget title. For more information about adding widget strings, see Add custom strings for widgets and other specified scenarios. No

    The url, navBarLink, and item or @value XML attributes can be parameterized using substitution variables. For more information about the substitution variables that you can use, see Profiles widget configuration variables.

    Table 14. The layout element

    Attribute Description
    resourceSubType Contains the name of the profile type that is used to render the widget layout. Multiple profile type layout configuration is allowed in Profiles. For more information, see Add profile types.

    This attribute takes a string value.

    Table 15. The page element

    Attribute Description
    pageId Contains the page ID for the page that Profiles uses to render the widget layout. This attribute takes a string value.

    Possible values include:

    • profilesView

    • searchView

    • searchResultView

    • networkView

    • editProfileView

    Table 16. The widget instance element

    Attribute Description
    uiLocation Specifies which column on the page contains the widget. This attribute takes a string value.

    Possible values include:

    • col1

    • col2

    • col3. Note that this option is not available for the networkView page.
    defIdRef Defines the widget definition to which the instance is bound.

    This attribute takes a string value.


    Related tasks

  • Manage widgets in Profiles
  • Enable custom widgets for Profiles

    Configure Profiles events

    Use configuration settings to control how you want the events generated by Profiles to be handled in your deployment for auditing purpose.

    By default, all Tivoli Directory Integrator-related events are ignored for auditing purpose. For a list of the Tivoli Directory Integrator events that are logged, see Tivoli Directory Integrator events.

    You can modify configuration settings in the tdi-profiles-config.xml and profiles-config.xml files to specify whether Tivoli Directory Integrator events are stored in the Profiles database and whether they are made available to the News application or third-party audit integration tools. For example, you might want to continue storing Tivoli Directory Integrator events in the Profiles database but you might not want to publish the events to the event infrastructure.

    You can configure settings to control whether regular, end-user events are stored in the Profiles database or published to the event infrastructure.

    To configure Profiles events, complete the following steps.

    1. To specify whether to store Tivoli Directory Integrator events in the Profiles database, you need to manually update settings in the tdi-profiles-config.xml file.

      1. Use a text editor, open the tdi-profiles-config.xml file.

        After the Tivoli Directory Integrator Solution files are extracted, the file is located in the following directory:
        TDI/conf/LotusConnections-config

      2. In the <properties> section of the file, update the value of the profiles.events.system.ignore property.

        <property name="profiles.events.system.ignore" value="false" />

        By default, the property is set to true so that Tivoli Directory Integrator events are not stored in the Profiles database.

    2. To configure event settings for the Profiles Web application, manually update settings in the profiles-config.xml file.

      To edit the profiles-config.xml file, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command tool.

      1. Check out the profiles-config.xml file by completing steps 1 and 2 of the topic, Changing Profiles configuration property values.

      2. Use a text editor, open the profiles-config.xml file from the temporary directory to which you checked it out and perform the following steps:

        1. To configure Tivoli Directory Integrator and system events, update the following properties in the <properties> section of the profiles-config.xml file:

          profiles.events.system.publish

          Specifies whether to publish Tivoli Directory Integrator events to the IBM Connections event infrastructure. By default, this property is set to true.

          For example, if you do not want to publish Tivoli Directory Integrator events to the event infrastructure, set the value of the property to false as follows:

          <property name="profiles.events.system.publish" value="false" />

          Tivoli Directory Integrator events must be stored in the Profiles database if you want them to be published to the event infrastructure. Therefore, if profiles.events.system.ignore in the tdi-profiles-config.xml file is set to true, the profiles.events.system.publish property has no effect, that is, system events and Tivoli Directory Integrator events will not be published to the event infrastructure.

          profiles.events.ignore

          Ignores all the events generated by Profiles. This property is set to false by default.

          This property is not explicitly listed in the profiles-config.xml file when you install IBM Connections. If you want to change the default setting so that the events generated by the Profiles application are ignored, manually add the property to the <properties> section of the profiles-config.xml file and set its value to true as follows:

          <property name="profiles.events.ignore" value="true" />

          If you installed the News application and are using it in your deployment, do not set the value of the profiles.events.ignore property to true. If you set it to true, the News application will not receive any events from the Profiles application.

        2. To configure end-user events, update the following properties in the <properties> section of the profiles-config.xml file:

          profiles.events.user.store

          Specifies whether to store regular, end-user create, update, and delete events in the Profiles database. By default, this property is set to true.

          This property is not explicitly listed in the profiles-config.xml file when you install IBM Connections. If you want to change the default setting so that end-user create, update, and delete events are not stored in the Profiles database, manually add the property to the <properties> section of the profiles-config.xml file and set its value to false as follows:

          <property name="profiles.events.user.store" value="false" />

          By default, IBM Tivoli Directory Integrator-related events are not stored in the Profiles database.

          profiles.events.user.publish

          Specifies whether to publish regular, end-user create, update, and delete events to the event infrastructure. By default, this property is set to true.

          This property is not explicitly listed in the profiles-config.xml file when you install IBM Connections. If you want to change the default setting so that end-user create, update, and delete events are not published to the event infrastructure, manually add the property to the <properties> section of the profiles-config.xml file and set its value to false as follows:

          <property name="profiles.events.user.publish" value="false" />

          If you installed the News application and are using it in your deployment, do not set the value of the profiles.events.user.publish property to false. If you set it to false, the News application will not receive any events from the Profiles application.

      3. Save your changes and then close the profiles-config.xml file.

      4. After making changes, check the profiles-config.xml file back in, and you must do so during the same wsadmin session in which you checked it out for the changes to take effect. See Applying property changes in Profiles for information about how to apply your changes.


    Related tasks

  • Apply property changes in Profiles
  • Start the wsadmin client
  • Change Profiles configuration property values


    Tivoli Directory Integrator events

    By default, all IBM Tivoli Directory Integrator-related events are stored in the Profiles database and are published to the event infrastructure in IBM Connections.

    The following Tivoli Directory Integrator events are logged by default:

    Table 17. Tivoli Directory Integrator events

    Event name Description
    profiles.person.updated Generated when a user's profile is modified.
    profiles.person.added Generated when a new user record is added to Profiles. There is no user interface for this task. This action can only be performed using the API or Tivoli Directory Integrator.
    profiles.person.deleted Generated when a new user record is deleted from the Profiles database.
    profiles.code.created Generated when new profile code is created using a Tivoli Directory Integrator script. The code might be for department, work location, or organization.
    profiles.code.updated Generated when profile code is updated using a Tivoli Directory Integrator script. The code might be for department, work location, or organization.
    profiles.code.deleted Generated when profile code is deleted using a Tivoli Directory Integrator script. The code might be for department, work location, or organization.

    Manage Profiles scheduled tasks

    Use the ProfilesScheduledTaskService administrative commands to manage the tasks scheduled for Profiles.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Profiles uses the IBM WebSphere Application Server scheduling service for performing regular managed tasks. For more information about how the scheduler works, see Scheduling tasks.

    Profiles has four managed tasks that are specified in the profiles-config.xml property file. You can use the ProfilesScheduledTaskService commands to pause and resume a Profiles task, and to retrieve information about a task. The SystemOut.log file also contains information about whether the scheduler is running and whether any scheduled tasks have started.

    To administer the tasks performed by the WebSphere Application Server scheduler, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter :

      execfile("profilesAdmin.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands to administer the Profiles scheduler service.

      ProfilesScheduledTaskService.pauseSchedulingTask(string taskName)

      Suspends scheduling of a task. Has no effect on currently running tasks. Returns a 1 to indicate that the task has been paused. Paused tasks remain paused until you explicitly resume them, even if the server is stopped and restarted.

      Parameters: taskName

      Task names have the following string values:

      • DbCleanupTask

      • ProcessLifeCycleEventsTask

      • ProcessTDIEventsTask

      • StatsCollectorTask
      For example:

      ProfilesScheduledTaskService.pauseSchedulingTask("StatsCollectorTask")

      ProfilesScheduledTaskService.resumeSchedulingTask(string taskName)

      Resumes the start of a paused task. Returns a 1 to indicate that the task has been resumed.

      Parameters: taskName

      Task names have the following string values:

      • DbCleanupTask

      • ProcessLifeCycleEventsTask

      • ProcessTDIEventsTask

      • StatsCollectorTask
      For example:

      ProfilesScheduledTaskService.resumeSchedulingTask("StatsCollectorTask")

      ProfilesScheduledTaskService.forceTaskExecution(string taskName, string executeSynchronously)

      Property settings in the profiles-config.xml file specify whether tasks are enabled to run automatically, and how often. This command allows you to run tasks manually, for example if you disabled a task but want to run it occasionally.

      Executes a task. Returns a 1 to indicate that the task has been executed.

      Parameters: taskName

      Task names have the following string values:

      • DbCleanupTask

      • ProcessLifeCycleEventsTask

      • ProcessTDIEventsTask

      • StatsCollectorTask
      Parameters: executeSynchronously

      This takes the string values true or false. Specifying this value is not required; the default is false. If this value is false, then the task executes asynchronously, meaning if the taskId is valid the command returns immediately and the execution continues in the background. If this value is true, it the command does not return until the task completes. The StatsCollectorTask is a local task (run on each node) and is always run asynchronously when triggered from the admin console.

      For example:

      ProfilesScheduledTaskService.forceTaskExecution("StatsCollectorTask")

      FilesScheduler.getTaskDetails(string taskName)

      Displays status of a task and details about configuration parameters.

      Parameters: taskName

      Task names have the following string values:

      • DbCleanupTask

      • ProcessLifeCycleEventsTask

      • ProcessTDIEventsTask

      • StatsCollectorTask
      For example:

      ProfilesScheduledTaskService.getTaskDetails("StatsCollectorTask")

    Administer cache

    You can modify settings in the profiles-config.xml file to configure the full report-to and object caches for Profiles. Use Profiles administrative commands when you want to enable, disable, or reload the full report-to chain cache.

    Profiles can display organizational structure information using report-to cache settings. These settings determine how the cache that is used to store the full-report-to data is configured. For performance reasons, this cache is used to present report-chain information rather than accessing the corporate directory. If the cache is disabled, the reporting structure information is still available, but it displays more slowly.

    Profiles uses the object cache to store auxiliary table information, including department, organization, work location, employee type, and country code display values. You can configure settings to specify when the cache is refreshed, and to define the refresh interval and start delay.


    Controlling cache operations

    Use Profiles administrative commands to control the operation of the full report-to chain cache without having to stop and start the Profiles server.

    To run administrative commands, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. Profiles uses an in-memory cache to support the organizational structure view available in every profile . the full report-to chain cache. You can use this procedure to change the behavior of the cache at runtime. However, the changes that you make using this procedure are not permanently stored. You must change the configuration settings in the profiles-config.xml file to change the behavior permanently because the changes you make here will be overwritten by the settings in the configuration file the next time you stop and restart the server. See Configuring the full reports-to cache for details. Only use these steps to immediately effect the behavior of the organizational structure cache without having to stop and restart the server.

    If you use the administrative commands to disable the cache, the reporting structure information is still available, but it displays more slowly.

    To control cache operations for Profiles, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands to control cache operations.

      ProfilesService.enableFullReportsToCache(startDelay, interval, schedTime)

      Enables the full report-to chain cache with the specified start delay in minutes, refresh interval in minutes, and scheduled refresh time in HH:MM format.

      This cache is used to populate the full report-to chain view available in a user's profile. The cache contains the specified number of top employees in the organizational pyramid; it is not intended to store an entry for each profile. It stores the profiles of those people at the top of the chain who are included in many full report-to chain views.

      For example:

      ProfilesService.enableFullReportsToCache(5, 15, "23:00")

      ProfilesService.disableFullReportsToCache()

      Disables the full report-to chain cache capability. This command does not take any arguments.

      ProfilesService.reloadFullReportsToCache()

      Forces a reload of the full report-to chain cache from the Profiles database. This command does not take any arguments.

      If the full report-to cache is disabled, it cannot be reloaded. This command fails when the cache is disabled.


    Related tasks

  • Configure the full reports-to cache


    Configure the full reports-to cache

    The full reports-to cache is one of the two in-memory caches used by Profiles to support the organizational structure views.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    The other in-memory cache is the object cache, which caches auxiliary table information, including department, organization, work location, employee type, and country code display values. The full reports-to cache is used to populate the full reports-to chain view available in a profile. The cache contains the specified number of top employees in the organizational pyramid. It is not intended to store an entry for each profile; it stores the profiles of those people at the top of the chain who are included in many full report-to chain views.

    When you use this procedure to change the default behavior of the cache, it changes the behavior permanently, but requires a server restart. If you want to change the cache behavior in a production environment without having to disrupt service, see Controlling cache operations. But, any changes you make to the runtime cache are overwritten by the setting in the configuration file when the server next restarts.

    To manage the display of report-chain information using the full reports-to cache.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. To configure the full reports-to cache, use the following command:

      ProfilesConfigService.updateConfig(property, value)

      ...where

      • property is one of the editable Profiles configuration properties.

      • value is the new value with which you want to set that property.

      The following table displays information regarding the properties that you can configure for the full reports-to chain cache, and the type of data that you can enter for them.

      Table 18. Full reports-to chain cache properties

      Option Description
      fullReportsToChainCache.enabled Enables or disables the full reports-to cache.

      This property takes a Boolean value: true or false. The value must be formatted in lowercase.

      fullReportsToChainCache.ceouid The corporate directory user ID of the person who will appear at the top of the organizational structure.

      This property takes a UID value.

      fullReportsToChainCache.size The number of employee entries that should be loaded into the cache.

      This property takes an integer value.

      fullReportsToChainCache.refreshTime Determines the time of day in 24-hour time format that Profiles performs the first scheduled reloading of the cache.

      The property value must be expressed in hours and minutes using this formatting: HH:MM.

      fullReportsToChainCache.refreshInterval The time in minutes between cache reload operations.

      This property takes an integer value.

      fullReportsToChainCache.startDelay The time in minutes that Profiles should wait after starting before loading the cache for the first time.

      This property takes an integer value.

      For example, to disable the cache, enter:

      ProfilesConfigService.updateConfig("fullReportsToChainCache.enabled","false")

    4. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Profiles for information about how to save and apply your changes.


    Related tasks

  • Apply property changes in Profiles
  • Controlling cache operations


    Configure the Profiles object cache

    You can modify settings in the profiles-config.xml file to specify when the Profiles object cache is refreshed, and to define the refresh interval and start delay.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. The Profiles object cache is used to cache auxiliary table information, including department, organization, work location, employee type, and country code display values. As a result, there is a delay before changes to these types of data are reflected in the user interface.

    By default, the data is refreshed every 15 minutes to ensure that, whenever data is updated, there is a relatively short delay from when the data is changed and when the changes are reflected in the user interface.

    To configure the Profiles object cache, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. Open the profiles-config.xml file in a text editor.

    4. Look for the <profileObjectCache> element, and then modify the following lines of code as needed:

      <profileObjectCache>
         <refreshTime>22:30</refreshTime> <!-- 24 hour time -->
         <refreshInterval>15</refreshInterval> <!-- minutes -->
         <startDelay>10</startDelay> <!-- minutes -->
      </profileObjectCache>

      ...where:

      • <refreshTime> is the scheduled refresh time in HH:MM format.

      • <refreshInterval> is the refresh interval in minutes.

      • <startDelay> is the specified start delay in minutes.

    5. Save your changes and close the configuration file.

    6. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Profiles for information about how to save and apply your changes.


    Related tasks

  • Apply property changes in Profiles

    Manage the Profiles search operation

    Use Profiles configuration settings to control how the search operation displays search results.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    To configure Profiles search, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. To configure the Profiles search operation, use the following command:

      ProfilesConfigService.updateConfig(property, value)

      ...where

      • property is one of the editable Profiles configuration properties.

      • value is the new value with which you want to set that property.

      The following table displays information regarding the search property and the type of data that you can enter for it.

      Table 19. Profiles search properties

      Property Description
      search.maxRowsToReturn

      Determines the maximum number of Profiles database rows returned by a name search operation.

      This property takes an integer value. The default value is 250. You can increase the number, but do not specify a number larger than 500. Doing so causes search operations to fail entirely. Do not specify 0 unless you want no results to be returned.

      The keyword and directory search operations do not have this limit.

      search.pageSize Determines the number of returned rows to place on a results page.

      This property takes an integer value. The default value is 10.

      search.firstNameSearchEnabled

      Determines if search by first name only is enabled. By default, this setting is set to false.

      This property takes a Boolean value.

      Enabling this setting negatively impacts the performance of the Search by > Name function available in the Profiles user interface.

      nameOrdering.enabled

      When this property is set to true, names must be entered as (FirstName LastName) or (LastName, FirstName). By default, it is set to false.

      When only a single word is entered, that word is treated as the LastName value during search.

      This property takes a Boolean value.

      For example:

      ProfilesConfigService.updateConfig("search.pageSize","20")

    4. To specify the default sorting key to use for displaying search results, you must edit properties in the profiles-config.xml file manually as follows.

      1. Open the profiles-config.xml file in a text editor.

      2. Update the following properties as needed.

        sortNameSearchResultsBy

        Determines what sorting key to use for Profiles name search results. This property is also applied to the search results that display when a tag is clicked in a profile overview page. It does not affect the results generated by clicking a tag in a directory search.

        The valid values for the default attribute are:

        • displayName. Lists name search results in order of user display name.

        • last_name. Lists name search results in order of user last name.
        For example:

        <sortNameSearchResultsBy default="displayName" />

        sortIndexSearchResultsBy

        Determines what sorting key to use for Profiles keyword and advanced search results.

        The valid values for the default attribute are:

        • relevance. Lists keyword and advanced search results in order of relevance.

        • displayName. Lists keyword and advanced search results in order of user display name.

        • last_name. Lists keyword and advanced search results in order of user last name.
        For example:

        <sortIndexSearchResultsBy default="relevance" />

      3. Save your changes and then close the profiles-config.xml file.

    5. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Profiles for information about how to save and apply your changes.


    Related

  • Customize Profiles search

  • Apply property changes in Profiles

    Monitor statistics and metrics for Profiles

    Use the Profiles statistics capabilities to monitor operations and product usage.

    Profiles enables you to monitor statistics in the following ways:


    Enable and disable automatic generation of Profiles statistics files

    You can enable or disable automatic generation of Profiles statistics files. By default, automatic generation is enabled.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. Usage statistics are stored in memory and saved to the file system during Profiles shutdown. The statistics are saved to the location configured in the statistics.filePath and statistics.fileName files. The statistics logged depend on the Profiles capabilities that are enabled. For example, if you disable the full report-to chain cache, you do not see statistics listed for that capability.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. In the working_directory from Step 2, locate and open the profiles-config.xml file using a text editor. Scroll to task StatsCollectorTask in the <scheduledTasks> section.

      • To disable auto generation of the statistics file, specify enabled="false" in the StatsCollectorTask statement.

      • To enable auto generation of the statistics file, specify enabled="true" in the StatsCollectorTask statement.

      Example:

      <task name="StatsCollectorTask" interval="0 0 1 * * ?" enabled="false" type="internal" scope="local">
      <args>
      <property name="filePath">${PROFILES_STATS_DIR}//LC_NODE_NAME//${WAS_SERVER_NAME}</property>
      <property name="fileName">profilesStats</property>
      </args>
      </task> 

    4. After making changes, check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in Profiles for information about how to save and apply your changes.

    Configure the vCard export application for Profiles

    Configure settings in the profiles-config.xml file to specify the character set encoding options used to export vCards.

    To use administrative commands, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for details. Profiles users can export vCards from people's profiles and then import the profiles into their email client as contacts. You can configure the profiles-config.xml file to specify the encoding options that are available when exporting vCards from Profiles and determine which options are most appropriate for your users.

    To configure the vCard export application, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. Open the Profiles configuration file, profiles-config.xml, using a text editor and locate the following <vcardExport> section:

      <vcardExport>
       <charset name="UTF-8">
        <label key="label.vcard.encoding.utf8"/>
       </charset>
       <charset name="ISO-8859-1">
        <label key="label.vcard.encoding.iso88591"/>
       </charset>
       <charset name="Cp943c">
        <label key="label.vcard.encoding.cp943c"/>
       </charset>
      </vcardExport>

    4. To provide an export encoding that is specific to your language, include the following lines of code within the <vcardExport> tags:

      <charset name="character_encoding">
        <label key="ui_label"/>
      </charset>

      ...where:

      • character_encoding is the name of the character encoding to export.

      • ui_label is the label for the character encoding in the user interface.
      For example, to add an export setting for Arabic, include the following element:

      <vcardExport>
       ...
       <charset name="Windows-1256">
        <label key="label.vcard.encoding.windows.arabic"/>
       </charset>
      </vcardExport>
      The following character set encoding options work best:

      Table 20. Export character set encodings

      Character encoding Description
      Windows-1250 Central European languages that use Latin script (Polish, Czech, Slovak, Hungarian, Slovene, Serbian, Croatian, Romanian, and Albanian)
      Windows-1251 Cyrillic alphabets
      Windows-1252 Western languages
      Windows-1253 Greek
      Windows-1254 Turkish
      Windows-1255 Hebrew
      Windows-1256 Arabic
      Windows-1257 Baltic languages
      Windows-1258 Vietnamese
      gb2312 Chinese
      gb18030 Chinese
      Complete this step for every language for which you require encoding support. There is no limit to the number of character set encodings that you can specify.

    5. After making changes, check the configuration files back in during the same wsadmin session in which you checked them out. See Applying property changes in Profiles for information about how to save and apply your changes.


    Related tasks

  • Apply property changes in Profiles
  • Add custom strings for widgets and other specified scenarios

    Making photos cachable in secure environments

    If your Profiles deployment is configured to prevent profile data from being accessible to readers, you can opt to make just user photos cachable.

    This is an optional task; it is only useful if Profiles is configured to lock profile data. For security reasons, when the reader role is set to something other than 'everyone', Profiles does not publicly cache photos in order to protect the integrity of the customer data. As a result, no profile photos are visible to readers. If you want to override this behavior and make photos visible, you must define a rule in the IBM HTTP Server's configuration file to explicitly set the caching headers of photos.

    Define a rule in the IBM HTTP Server to explicitly set the caching headers of profile photos by completing the following steps:

    1. Use a text editor, open the httpd.conf file, which is the IBM HTTP Server configuration file. The file is stored in the following directory by default:

      • AIX: /usr/IBM/HTTPServer/conf

      • Linux: /opt/IBM/HTTPServer/conf

      • Microsoft

        Windows: C:\IBM\HTTPServer\conf

    2. Add the following block of code to the httpd.conf file:

      <LocationMatch  /*/profiles/photo.do >
        <IfModule mod_headers.c>
          Header set Pragma ""
          Header set Cache-Control "max-age=21600,s-maxage=21600,public"
        </IfModule>
      </LocationMatch>

    3. Save and close the configuration file.

    4. Restart the IBM HTTP Server.

    Enable the use of pronunciation files in an HTTPS environment

    Ensure that Profiles users can save and play pronunciation files in an HTTPS environment by defining a rule in the IBM HTTP Server's configuration file.

    This task needs to be performed in an HTTPS environment only. Profiles users can add a recording of how their name is pronounced to enhance their profile. To ensure that users can save a pronunciation file to their own profile and listen to the recordings of other users, you must define a rule in the IBM HTTP Server's configuration file to explicitly set the caching headers of pronunciation files.

    Define a rule in the IBM HTTP Server :

    1. Use a text editor, open the IBM HTTP Server configuration file, httpd.conf file. The file is stored in the following directory by default:

      • AIX: /usr/IBM/HTTPServer/conf

      • Linux: /opt/IBM/HTTPServer/conf

      • Microsoft

        Windows: C:\IBM\HTTPServer\conf

    2. Add the following block of code to the httpd.conf file:

      <LocationMatch /*/profiles/audio.do>
         Header set Pragma ""
         Header set Cache-Control "private, max-age=0, must-revalidate"
      </LocationMatch>

    3. Save and close the configuration file.

    4. Restart the IBM HTTP Server.


    Related tasks

  • Uploading pronunciation files

    Manage the Profiles event log

    Use Profiles administrative commands to manage the Profiles event log.

    To run administrative commands, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool. The Profiles EVENTLOG table logs records relating to Profiles user events. For example, every time a user removes a board post or adds a tag to their profile, an entry is logged in the table. From time to time, you might want to purge older records from the table to control the size of the data. Otherwise, the entries can grow rapidly and impact performance in areas such as seedlist indexing.

    By default, records that are more than 30 days old are automatically purged from the event log. For information about how to modify the setting that controls this interval, see Configuring event log clean-up for Profiles.

    To manage entries in the event log table for Profiles, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly. For more information, see Starting the wsadmin client.

    2. Start the Profiles Jython script interpreter.

      1. Access the Profiles configuration files:

        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    3. Use the following commands as required.

      ProfilesService.purgeEventLogs()

      Deletes all event log entries in the EVENTLOG table. This command does not take any arguments.

      ProfilesService.purgeEventLogsByDates(string startDate, string endDate)

      Deletes event log entries created between the specified start date and end date.

      This command takes the following parameters:

      startDate

      A string that specifies the start date for the period in MM/DD/YYYY format.

      endDate

      A string that specifies the end date for the period in MM/DD/YYYY format.

      For example:

      ProfilesService.purgeEventLogsByDates("06/21/2009", "06/26/2009")
      This command deletes all the event log entries that were created on or after June 21st, 2009 and before June 26th, 2009 from the EVENTLOG table.

      ProfilesService.purgeEventLogsByEventNameAndDates(eventName, string startDate, string endDate)

      Deletes event log entries with the specified event name that were created between given start date and end date.

      This command takes the following parameters:

      eventName

      The type of event to remove from the EVENTLOG table. The following names are some examples of valid event names:

      • profiles.created

      • profiles.removed

      • profiles.updated

      • profiles.person.photo.updated

      • profiles.person.audio.updated

      • profiles.colleague.created

      • profiles.colleague.added

      • profiles.connection.rejected

      • profiles.person.tagged

      • profiles.person.selftagged

      • profiles.tag.removed

      • profiles.link.added

      • profiles.link.removed

      • profiles.status.updated

      • profiles.wallpost.created

      • profiles.wallpost.removed

      • profiles.wall.comment.added
      For a complete list of valid event names for Profiles event log cleaning administrative tasks, refer to the following web page:
      http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Events_Reference

      startDate

      A string that specifies the start date for the period in MM/DD/YYYY format.

      endDate

      A string that specifies the end date for the period in MM/DD/YYYY format.

      For example:

      ProfilesService.purgeEventLogsByEventNameAndDates(profiles.colleague.created, "06/21/2009", "06/26/2009")
      This command deletes all the profiles.colleague.created event log entries that were created on or after June 21st, 2009 and before June 26th, 2009 from the EVENTLOG table.


    Related tasks

  • Configure event log clean-up for Profiles . obsolete

    Configure advanced settings in Profiles

    Configure advanced settings in Profiles by adding information to the <properties> element in the profile-config.xml file.

    For the most part, you can use the ProfilesConfigService.updateConfig command to update settings in the profiles-config.xml file. However, for some advanced settings, check out the configuration file and make changes to it manually. For example, if you want to change the display order of the information that displays on the Reporting Structure page or to expose information relating to the following feature, you must use the steps documented in the following topics.

    For a full list of the properties that you can update using the ProfilesConfigService.updateConfig command, see Profiles configuration properties.

  • Profiles configuration properties


    Expose information about following

    You can add a setting to the profiles-config.xml file to specify whether information relating to the following feature is made public.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. When the following feature is enabled, users can follow other users to get the latest updates about them. By default, following information is private in the sense that only the logged-in user can view information about the people that they are following and the people who are following them. You can change this behavior to make following information public by adding a setting to the profiles-config.xml file.

    To expose following information, complete the following steps.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. Open the profiles-config.xml file in a text editor.

    4. Add the following setting to the <properties> section of the file:

      <property name="com.ibm.lconn.profiles.config.MakeFollowingInfoPublic" value="true"/>

    5. Save your changes and close the configuration file.


    Related tasks

  • Apply property changes in Profiles


    Change the display order of the Reporting Structure page

    You can add a setting to the profiles-config.xml file to change the order in which the full report-to chain is displayed on the Reporting Structure page.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool. Users can click Full Report-to Chain in a profile to view the profile owner's place in the organization's reporting structure. The default sorting order lists the profile owner first. To reverse the default order, edit the profiles-config.xml file.

    To reverse the sorting order of the report-to chain displayed on the Reporting Structure page, edit properties in the profiles-config.xml file.

    1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

      You must start the client from this directory or subsequent commands that you enter do not execute correctly.

    2. Start the Profiles Jython script interpreter.

      1. Enter the following command to access the Profiles configuration files:
        execfile("profilesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Enter the following command to check out the Profiles configuration files:
        ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.

          AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
          print AdminControl.getCell()
        For example:

        • AIX or Linux:

          ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")

        • Microsoft

          Windows:

          ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")

    3. Open the profiles-config.xml file in a text editor.

    4. Add the following setting to the <properties> section:
      <property name="com.ibm.lconn.profiles.ui.reportingChain.isBottomUp" value="false"/>

    5. Save your changes and close the configuration file.


    Related tasks

  • Apply property changes in Profiles

    Administer Wikis

    You administer Wikis using the wsadmin client to specify properties in a configuration file, or run administrative commands.

    You edit the configuration file to control how and when various Wikis operations take place. You use the administrative commands to perform tasks that manipulate Wikis content. Changes to the configuration file require node synchronization and a restart of the Wiki server before they take effect. Changes made using administrative commands take effect immediately.


    Related

  • Groups

    Change Wikis configuration property values

    Configuration properties control how and when various Wikis operations take place. You can edit the properties to change the ways that Wikis operates.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    In the client, you access scripts that use the AdminConfig object to interact with the configuration file. After changing the configuration properties, you must synchronize nodes and restart the Wikis server before the changes take effect.

    To edit Wikis configuration properties:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view a list of the valid Wikis configuration settings and their current values, use the following command:

      WikisConfigService.showConfig() Here is some sample output from the WikisConfigService.showConfig() command:

      Wikis configuration properties:
      	security.logout.href = /wikis/ibm_security_logout
      	activeContentFilter.enabled = true
      	cache.user.timeout = 43200000
      	cache.http.publicContentMaxAgeInSecs = 604800
      	db.dialect = DB2

    4. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly. To change a Wikis configuration setting, do one of the following:

      • To edit a property using the wsadmin client, use the following command:

        WikisConfigService.updateConfig("property", "value")

        where property is one of the editable Wikis configuration properties and value is the new value with which you want to set that property. See Wikis configuration properties for a complete list of editable properties. For example:

        WikisConfigService.updateConfig("file.page.maximumSizeInKb", "512")

      • To edit the value of a property in a configuration file directly, from the temporary directory to which you checked it out, open the file in a text editor, and then make your changes.

    5. Optional: Repeat step 4 for each single-value property setting to change.

    6. Optional: After updating the Wikis properties with new values, use the WikisConfigService.showConfig() command to display the list of properties and their updated values. These are the values that will be checked in with the WikisConfigService.checkInConfig() command.


    What to do next

    You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Related tasks

  • Start the wsadmin client
  • Customize Wikis notification templates
  • Change application URLs


    Wikis configuration properties

    Configuration properties control how and when various Wikis operations take place, and also help in the optimization of server performance. They require a Wikis server restart to take effect.

    The following are configuration properties in the wikis-config.xml file that you can modify. Note the following restrictions on the values allowed in the file:

    • All configuration properties (except those with multiple values) are required.

    • .enabled properties must have boolean values true or false.

    • Number values must be integers.

    activeContentFilter.enabled

    Specifies the mime types that are scanned and scripts removed from wiki pages when they are viewed.

    You can disable this filter by changing the value to false, but that might leave your environment open to cross-site scripting attacks unless you have taken other security precautions. For more information on securing against cross-site scripting attacks, see the topic Securing applications from malicious attack.

    api.indent.enabled

    Specifies whether the Wikis service API output is indented. This is false by default. To enable indentation, specify true.

    Enable this property to help with development and debugging. It is disabled by default because it does affect performance.

    cache.http.publicContentMaxAgeInSecs

    Maximum age of the public content cache before it is refreshed, in seconds. The public content cache stores static web resources, such as JavaScript. and images. Lower this value to show resource changes more quickly.

    The value must be greater than or equal to 0.

    You can force a resource update by opening the LotusConnections-config.xml common configuration properties file and setting the versionStamp property to any token. The token is included in most urls, and urls cache by path and cache header, so the new url overrides the old version and refreshes the resources. For information, see the topic Common configuration properties.

    Some resources, such as some images, do not use version stamps. If you edit those frequently, you can lower the cache.http.publicContentMaxAgeInSecs value to show changes more quickly. If not, you can leave the value high and update the version stamp when you make changes.

    cache.http.publicFeedMaxAgeInSecs

    Maximum age of the public feed cache before it is refreshed, in seconds. Public feeds pass information to the Public Wikis view. You may want to raise this value in very large deployments (for example, over 200,000 wikis) to avoid performance issues. It could also be lowered to have very up-to-date information in the public view.

    The value must be greater than or equal to 0.

    cache.user.timeout

    Number of milliseconds user objects stay in the user information cache. The user information cache stores metadata about users, such as names and email addresses. Use this property to control the frequency of requests to the Wikis database for user information.

    The value must be greater than or equal to 1.

    If the value of a user's data changes in the background (when the update user task or commands for MemberSynch are executed) the cache is invalidated.

    db.dialect

    Reflects the current database type, typically specified during installation. Accepts the values DB2, Oracle, or SQL Server.

    directory.community.membershipCache.maximumAgeOnLoginInSeconds

    Number of seconds after a user logs in that community membership cache is refreshed after user login. Only applicable if Community Wikis and Community Integration are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the community, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the community can access.

    You can lower the value here and then tell users that logging out and then in again is the best way to refresh the cache. This would allow you to increase the number of seconds in directory.community.membershipCache.maximumAgeOnRequestInSeconds so that frequent requests would not affect performance.

    directory.community.membershipCache.maximumAgeOnRequestInSeconds

    Number of seconds after an application request that the community membership cache is refreshed. Only applicable if Community Wikis and Community Integration are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the community, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the community can access.

    If you lower the value of directory.community.membershipCache.maximumAgeOnLoginInSeconds and then tell users that logging out and then in again is the best way to refresh the cache, you can increase this value to 10 or even 20 minutes, so that frequent requests will not affect performance.

    directory.group.membershipCache.maximumAgeOnLoginInSeconds

    Number of seconds after a user logs in that group membership cache is refreshed after user login. Only applicable if groups are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the group, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the group can access.

    You can lower the value here and then tell users that logging out and then in again is the best way to refresh the cache. This would allow you to increase the number of seconds in directory.group.membershipCache.maximumAgeOnRequestInSeconds so that frequent requests would not affect performance.

    directory.group.membershipCache.maximumAgeOnRequestInSeconds

    Number of seconds after an application request that the group membership cache is refreshed. Only applicable if groups are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the group, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the group can access.

    If you lower the value of directory.group.membershipCache.maximumAgeOnLoginInSeconds and then tell users that logging out and then in again is the best way to refresh the cache, you can increase this value to 10 or even 20 minutes, so that frequent requests will not affect performance.

    directory.typeaheadSearch.maximumResults

    Maximum number of names to display when a user searches for user or group names in a search field. Sets a maximum for both typeahead results and search results (when they click the search icon).

    The value must be greater than or equal to 1.

    If the value is very large, such as 1000, and there are 1000 or more matches, all names are returned and performance is greatly reduced. If the value is low, such as 10, users typing a generic name might not see all matches.

    Typeahead only is available for public pages but not for filtered pages that might appear in Owner, Editor, or Reader views.

    download.modIBMLocalRedirect.enabled

    Specifies whether the IBM HTTP Server serves downloaded files instead of the WebSphere Application Server redirect servlet.

    You can configure IBM Connections to have the IBM HTTP Server download files. This is strongly recommended in production environments.

    If this property is set to true, you must also specify a URL in the download.modIBMLocalRedirect.hrefPathPrefix property. If the property is set to false, the WebSphere Application Server redirect servlet downloads files.

    To see information and steps for configuring the IBM HTTP Server to download files, see the topic Configuring Files and Wikis downloading for production deployments.

    download.modIBMLocalRedirect.hrefPathPrefix

    Path to the file system directory where Wikis data is stored. The file path should not include a trailing slash.

    This is only relevant if the download.modIBMLocalRedirect.enabled property is true.

    To see information and steps for configuring the IBM HTTP Server to download files, see the topic Configuring Files and Wikis downloading for production deployments.

    download.stats.logging.enabled

    Level of detail to log about page views. If false (the default), Wikis only logs the number of times a page is viewed. If true, Wikis logs the names of authenticated users who view pages.

    Specify true for a better user experience and auditing.

    editor.wikitexttab.enabled

    Specifies if the WikiText tab feature is enabled (default is false).

    You can enable this feature by changing the value to true.

    During migration from Connections version 3.0.x to 4.0 this configuration parameter is preserved.

    During migration from Connections version 3.0 to 4.0 this configuration parameter is set to false.

    file.attachment.maximumSizeInKb

    Maximum size allowed for file attachments, in kilobytes.

    The value must be greater than or equal to 1.

    Attachments larger than this setting will fail to upload and return an error to users. Use this to restrict users from uploading files that will negatively affect your system environment.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.media.maximumSizeInKb

    Maximum size allowed for media, in kilobytes. In Wikis, media are wiki pages.

    The value must be greater than or equal to 1.

    This property is useful if you want a relatively large quota size for libraries, but you do not want users attach very large files, such as .iso files.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.page.maximumSizeInKb

    Maximum size allowed for wiki pages, in kilobytes. Since pages are a type of media, this value must be less than or equal to the maximum size set in the file.media.maximumSizeInKb property.

    The value must be greater than or equal to 1.

    Pages larger than this setting will fail to upload and return an error to users. Use this to restrict users from uploading files that will negatively affect your system environment.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.restrictions.enabled

    Enables or disables the ability to restrict the types of files that users can upload as attachments in Wikis. Accepts the values true or false.

    To see information and steps for restricting file types, see the topic Restricting attachment file types in Wikis.

    file.restrictions.mode

    Sets the mode for file extension restrictions. Accepts the values allow or deny. If the value is allow, then the list of file extensions are the only ones allowed to be uploaded as attachments. If the value is deny, then the list of extensions are not allowed, and all extensions not on the list are allowed.

    For example:

    <file>
     ....
     <restrictions enabled="true" mode="allow">
      <extensions>
       <extension>odt</extension>
       <extension>odp</extension>
       <extension>ods</extension>
      </extensions>
     </restrictions>
    </file>

    To see information and steps for restricting file types, see the topic Restricting attachment file types in Wikis.

    file.storage.rootDirectory

    Path to the file system directory where Wikis data is stored. This can be set during installation and be different for each node in a cluster. If a directory is specified in during installation this value (a variable by default) is populated by the WebSphere Application Server. However, you can specify any directory.

    IBM Connections looks for a /files and a /temp directory within this directory. If they are not there they are created. The /temp directory stores data while the data is uploaded or virus scanned (if enabled). The /files directory contains the binary data that must be backed up.

    For more information on backing up data, see the topic Back up data.

    file.versioning.enabled

    Specifies whether wiki page versioning is allowed. Specify true or false.

    If false, the versioning interface does not display and the first version is always current. If you disable this after multiple versions of a page are created the latest version becomes the current and only version.

    Note that new versions are created only when content changes, not title or tags or other metadata.

    Specify false to simplify and reduce data storage.

    See the topic Disabling wiki page versioning.

    scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours

    Number of hours that group information can remain in the Wikis database before the synchronization task can run on it. Does not run if groups are disabled.

    The value must be greater than or equal to 0.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any group information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    scheduledTasks.DirectoryGroupSynch.args.pauseInMillis

    Number of milliseconds that the synchronization task should wait before updating the next group's information. Use this to add a small amount of time between synchronizing items in the queue to avoid overloading your user directory as the task runs. Does not run if groups are disabled.

    The value must be greater than or equal to 0.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    Zero is an acceptable value if the remote user directory can handle many simultaneous queries.

    scheduledTasks.DirectoryGroupSynch.enabled

    Enables or disables the synchronization task for groups. The default is true.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name. If the group name is not found in the user directory, it is removed from the database.

    scheduledTasks.DirectoryGroupSynch.interval

    Frequency with which the synchronization task runs.

    This property accepts a chronological expression.*

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any group information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    Adjust this property to speed up or slow down the process of synchronizing group information.

    scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins

    Number of minutes that files must be in the pending deletion queue before the delete files task will delete them. For example, the default value of 720 means they will be deleted if they have been in the pending deletion queue 720 or more minutes.

    The value must be greater than or equal to 0.

    More pending time allows users to finish downloads of files added to the pending deletion queue. It also allows looser online back up policies. For example, for online backups that take less than this number of minutes you do not need to pause the file deletion task. To see more information about pausing the file deletion task during backups, see the topic Backing up data.

    scheduledTasks.FileActuallyDelete.enabled

    Enables or disables the delete files task. The default is true.

    The task deletes files if they are marked as pending deletion, and they are older than the value specified in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property.

    scheduledTasks.FileActuallyDelete.interval

    Frequency with which the delete files task runs.

    This property accepts a chronological expression.*

    Wikis are deleted if they are marked as pending deletion, and they are older than the value specified in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property.

    scheduledTasks.MetricsDailyCollection.enabled

    Specifies whether to collect metrics. Specify true or false.

    See the topic Wikis administrative commands for MetricService commands you can use to access metrics.

    The collection task runs near midnight in the server timezone, so all of the date-based metrics include data from most of a given day. Metrics entries only require a few kilobytes per day, so there is little performance impact to enabling them.

    scheduledTasks.MetricsDailyCollection.interval

    Frequency with which daily metrics collection task runs. Only the default is supported: the task can only run at midnight in the server timezone. Do not edit this property.

    scheduledTasks.TagUpdateFrequency.enabled

    Specifies whether to run the tag frequency update task. This task finds the most frequently used tags in public wikis and updates the public wikis tag cloud.

    scheduledTasks.TagUpdateFrequency.interval

    Frequency with which the tag frequency update task runs. This task finds the most frequently used tags in public wikis and updates the public wikis tag cloud and the autocomplete lists that display when users type a tag name in the tag filter field. For example, it measures how often the tag human-resources is used on pages in public wikis and updates the cloud and lists accordingly.

    This property accepts a chronological expression.*

    Update tag frequency data is resource-intensive, so you may want to adjust this value as your deployment grows. In very small deployments 60 minutes is appropriate. In very large deployments, once per day is recommended. Only updating once per day in large deployments should not cause problems, since the 100 to 500 most-used tags do not change very often.

    This property only affects public tags. Tag clouds for individual wikis are updated in real time and are not affected.

    search.seedlist.maximumIncrementalQuerySpanInDays

    Number of days that deletion records are saved before they are eligible to be deleted by the SearchClearDeletionHistory task.

    The value must be greater than or equal to 1.

    Wikis keeps records of deleted files. These records are eligible to be deleted by the SearchClearDeletionHistory task after the number of days specified in this property. The incremental search crawler needs these deletion records to update the search index. If the records are deleted before the incremental crawler reads them, updates will be incomplete. This is not allowed, so Wikis performs a full crawl instead of an incremental crawl. Full crawls delete the existing search index and create a new one, which is more time consuming than incremental crawls.

    To avoid frequent full crawls, make sure that incremental crawls occur sooner than the time it takes for a deletion record to be created and deleted. For example, if deletion records are eligible for deletion after five days, specify that incremental crawls occur every four days.

    search.seedlist.maximumPageSize

    Maximum number of items on search return page. The value must be greater than or equal to 100.

    security.inlineDownload.enabled

    Enables inline display of file attachments. This is useful when you use the Wikis API to download and display active content, such as Adobe Flash (.swf) files, in your own HTML pages.

    By default, the IBM Connections server passes Wikis application file attachments to browsers with the header "Content-Disposition: attachment." This means files display as attachments; when users click the attachment they are prompted to open or download the file. It also prevents embedding files. If you want to embed files in your own HTML page using an <embed> tag, the content disposition must be inline. This affects active content, such as Adobe Flash (.swf), and HTML pages referenced with <iframe>.

    Configure a property in wikis-config.xml to change the content disposition from attachment to inline. Then set the inline parameter to true in your Wikis API download requests. See Displaying file attachments inline.

    Important: Wikis uses the attachment disposition for security reasons. Specifically, uploaded files could potentially contain malicious code that can exploit the cross-site scripting vulnerabilities of some browsers. If you switch to inline disposition, you should configure an alternate domain download for greater security. See Mitigating a cross site scripting attack.

    Accepted values are true and false.

    security.logout.href

    Logout URL for single-sign on solutions that require their own logout page.

    If you are configuring IBM Connections to work with Tivoli Access Manager, specify the following value:

    /wikis/ibm_security_logout?logoutExitPage=<url>

    where <url> is the Tivoli Access Manager junction URL (this is usually the host name of the server).

    For more information, see the topic Enabling single sign-on for Tivoli Access Manager.

    You must use fully-qualified domain names in this configuration file. If you use an abbreviated name, secure communications between servers will fail.

    * For information on how to format the value of an interval attribute, see Scheduling tasks.


    Related

  • Securing applications from malicious attack

  • Specify a separate file download domain
  • Disable wiki page versioning
  • Enable single sign-on for Tivoli Access Manager
  • Configure Files and Wikis downloading
  • IBM Connections configuration property values
  • Back up Wikis data
  • Disable trash bin in Wikis
  • Required post-customization step
  • Restrict attachment file types in Wikis

  • Common configuration properties
  • Wikis administrative commands


    Configure MIME types for Wikis

    You can assign Multipurpose Internet Mail Extensions (MIME) types to file extensions. This applies to files attachments uploaded to wiki pages.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    You can configure Wikis to assign a specific MIME type to files with specific extensions. Wikis with MIME types tell operating systems what applications to open them with, and what applications to display in file open windows. MIME types make it easier for users at a glance to know what type of data a file contains. Also, some applications do not download files that do not have a MIME type that they support.

    This configuration applies to files attached to Wikis pages through the web user interface. The configuration is ignored if a third party application assigns MIME types to extensions using the API. See the topic Wikis API for information about how to assign MIME types through the API.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Navigate to the working directory specified in Step 2b and open the mime-wikis-config.xml file. The contents look like this:

      <mapping mimeType="..." mediaType="..."> 
      		<extension></extension> 
      		<extension></extension> 
      		.... 
      </mapping>

    4. In the mimeType attribute specify a mime type in standard format, for example text/plain. Each value must be unique compared with other mimeType values in other mapping elements, or an error is returned when you start the system. See the Internet Assigned Numbers Authority (IANA) web site for a list of MIME types.

      The mediaType attribute is not supported in this release.

    5. In each extension element specify the extensions that you want to map to the MIME type. Each value must be unique compared with other extension elements in the configuration file, or an error is returned when you start the system.

    6. Apply the changes following steps in the Applying Wikis property changes.


    Example

    <mapping mimeType="text/plain" mediaType=""> 
    	<extension>.txt</extension> 
      .... 
    </mapping>


    Related tasks

  • Apply Wikis property changes


    Apply Wikis property changes

    After you have edited the Wikis configuration properties, check the changed configuration file in, update the version stamp property, and restart the servers to apply the changes. For information about the properties that you can edit, see Wikis configuration properties. To apply Wikis property changes, complete the following steps:

    1. Check in the changed configuration property keys using the following wsadmin client command:

      WikisConfigService.checkInConfig()

    2. Update the value of the version stamp configuration property in LotusConnections-config.xml to force users' browsers to pick up this change. See Required post-customization step for more details.

    3. To exit the wsadmin client, type exit at the prompt.

    4. Stop and restart the server hosting the Wikis application.


    Related tasks

  • Apply common configuration property changes
  • Required post-customization step
  • Restrict attachment file types in Wikis
  • Customize Wikis notification templates
  • Set maximum sizes on media, pages, and attachments
  • Disable wiki page versioning
  • Configure MIME types for Wikis

  • Wikis configuration properties

    Run Wikis administrative commands

    Use administrative commands to perform tasks that manipulate Wikis content.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Administrative commands interact with the Wikis application and its resources through scripts. These scripts use the AdminControl object available in the IBM WebSphere Application Server wsadmin tool to interact with the Wikis server.

    If an error occurs when you are executing the commands, you can examine the SystemOut.log file to determine what went wrong.

    To run Wikis administrative commands, complete the following steps:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. See Wikis administrative commands for a complete list of administrative commands for the Wikis application.


    Related tasks

  • Start the wsadmin client


    Wikis administrative commands

    Use these commands to perform administrative tasks for Wikis. No file checkout or server restart is needed when using these commands.

    The following sections define administrative commands you can use when working with Wikis. Each section describes the commands for a specific service.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus® Connections API documentation for information on getting ID information using feeds.


    WikisConfigService

    WikisConfigService.checkOutConfig("working_directory", "cell_name")

    Checks Wikis configuration files out to a temporary directory. Run from the wsadmin command processor.

    <working_directory>

    Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

    <cell_name>

    Name of the WebSphere® Application Server cell hosting the Lotus® Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:

    print AdminControl.getCell()

    For example:

    • AIX/Linux:

      WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    • Microsoft

      Windows:

      WikisConfigService.checkOutConfig("c:/temp","foo01Cell01")

    WikisConfigService.showConfig()

    Displays the current configuration settings. You must check out the configuration files with WikisConfigService.checkOutConfig() before running WikisConfigService.showConfig().

    WikisConfigService.updateConfig("quick_config_property", "new_value")

    Updates configuration properties.

    quick_config_property

    Property in the wikis-config.xml configuration file expressed as a quick config command. For example the quick config value for following property:

    <security>
    <logout href="/wikis/ibm_security_logout" />
    </security>
    is this:

    security.logout.href

    See Wikis configuration properties for configuration properties and descriptions.

    new_value

    The new value for the property. Property values can be restricted, for example to either true or false. See Wikis configuration properties for configuration properties and descriptions.

    For example, to set the scheduledTasks.MetricsDailyCollection.enabled property to false, use the following command:

    WikisConfigService.updateConfig("scheduledTasks.MetricsDailyCollection.enabled", "false")

    WikisConfigService.checkInConfig()

    Checks in Wikis configuration files. Run from the wsadmin command processor.


    WikisMemberService

    WikisMemberService.getById(string id)

    Returns information about a user specified by a user ID. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    id

    The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisMemberService.getByExtId(string externalId)

    Returns information about a user specified by an external directory ID. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    externalId

    A string value matching the user's external directory ID. This can be any parameter in the user directory that you have configured as the directory ID. The following user information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getByExtId("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisMemberService.getByEmail(string email)

    Returns information about a user specified by an email address. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    email

    The email address for the user. The following user information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getByEmail("john_doe@company.com")

    WikisMemberService.syncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"] } )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberByExtId("currentExternalId"[, {"newExtId" : "id-string" [, "allowExtIdSwap" : ["true" | "false"] ] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.inactivateMemberByEmail("email")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.inactivateMemberByExtId("externalID")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.getMemberExtIdByEmail("email")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.getMemberExtIdByLogin("login")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncBatchMemberExtIdsByEmail("emailFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncBatchMemberExtIdsByLogin("loginFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberExtIdByEmail("email" [, { "allowInactivate" : ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate": ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.


    WikisLibraryService

    WikisLibraryService.getById(string libraryId)

    Returns information about a single library specified by an ID. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    libraryId

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

    • type: The type of library. The only valid value is wiki.

    • label: A string of characters used to identify the library in a URL.

    • title: The library's title.

    • summary: A summary of library information.

    • size: The total size of the library binary data.

    • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

    • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

    • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • lastUpdate: The last time a significant user-driven update occurred to the metadata.

    • createDate: The library's creation date.

    • externalInstanceId: The widget ID if the library is owned by a community.

    • externalContainerId: The community ID if the library is owned by a community.

    • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

    • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

    For example:

    WikisLibraryService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisLibraryService.delete(string libraryId)

    Deletes the library specified by the library ID, including all associated content.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    libraryID

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisLibraryService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")

    WikisLibraryService.deleteBatch(string filePath)

    Deletes libraries specified in a text file. The file must contain a list with a single library ID per line in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must create the file and save it in a directory local to the server

    ...where you are running the wsadmin processor.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    filePath

    The full path to the text file, as a string.

    For example:

    WikisLibraryService.deleteBatch("C:/connections/delete_libraries.txt")

    WikisLibraryService.assignPolicy(string libraryId, string policyId)

    Assigns a policy to a library. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments. A policy sets a maximum size for a wiki.

    No message is printed if the task succeeds.

    Parameters:

    libraryId

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    policyId

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisLibraryService.assignPolicy("f0d01111-9b21-4dd8-b8be-8825631cb84b", "2d93497d-065a-4022ae25-a4b52598d11a")

    WikisLibraryService.assignPolicyBatch(string filePath)

    Assigns policies to libraries as specified in a text file. The file must contain a list of library-policy ID pairs, one pair per line, values separated by a comma. For example: libraryId, policyId. Extra whitespace is ignored. You must create this text file and save it in a directory local to the server where you are running the wsadmin processor.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    filePath

    The full path to the text file, as a string.

    For example:

    WikisLibraryService.assignPolicyBatch("C:/connections/assign_policies.txt")

    WikisLibraryService.browseWiki(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

    Returns a list of all wikis, with information about each wiki. The list includes wikis owned by communities, and wikis whose owners were removed from the user directory.

    Parameters:

    sortOption

    A string value that specifies how to sort the list. The default value is title, but you can use lastUpdate, size, createDate, or quotaPercentage.

    sortAscending

    A string value that specifies whether to sort the list in ascending alphabetical order. This depends on the sortOption value. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

    pageNumber

    The number of the page to display. For example, if you specify in the itemsPerPage parameter that each page will have 50 items, page 1 will contain items 1-50.

    itemsPerPage

    The maximum number of wikis to list per page. The default value is 20. The following information is returned:

    • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

    • type: The type of library. The only valid value is wiki.

    • label: A string of characters used to identify the library in a URL.

    • title: The library's title.

    • summary: A summary of library information.

    • size: The total size of the library binary data.

    • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

    • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

    • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • lastUpdate: The last time a significant user-driven update occurred to the metadata.

    • createDate: The library's creation date.

    • externalInstanceId: The widget ID if the library is owned by a community.

    • externalContainerId: The community ID if the library is owned by a community.

    • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

    • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

    For example:

    WikisLibraryService.browseWiki("title", "true", 1, 25)

    WikisLibraryService.getWikiCount()

    Returns the total number of wikis.

    WikisLibraryService.exportSyncedResourceInfo (string fullpathForOutput, string type)

    Returns a report of all of the communities that the Wikis application has interacted with. After a system crash you can compare the report to the latest metadata in the Communities database to help synchronize and update any missing data. See the topic Comparing remote application data with the Communities database for more information.

    Note that in clusters, when you run the command from the deployment manager the path and file are created on the server running Wikis. In clusters

    ...where multiple nodes are running Wikis, you are asked choose a server to connect to and run the command on, and then the path and file are created on that server.

    Parameters:

    fullPathforOutput

    The full path location where you want the report, and the report filename, as a string in quotes. The report is an XML file. Use forward slashes ("/") in the path, even on Microsoft Windows computers.

    type

    This is always the string value, "community" (including quotes). An error is returned if this is anything except "community".

    For example:

    WikisLibraryService.exportSyncedResourceInfo("c:/connections/sync/community_output.xml", "community")


    WikisDataIntegrityService

    WikisDataIntegrityService.checkFiles(string extraFileDirectory)

    Checks the integrity of the binary files in the file system extra files directory against the metadata in the database, and prints results to log files in a specified directory. The database is used as the primary source, as during a back up the file system is assumed to have extra data, if there is any.

    The task logs a message for every extra file found, or every missing file. Missing files are errors that must be resolved (by finding the files or restoring a backup) before the application can start in a consistent state.

    This information might be useful before restoring database and file system images, to see how closely they match in a test environment. For more information see the topic Checking Wikis data integrity.

    Parameters:

    extraFileDirectory

    A directory path as a string. This is the location where you want to store files not found in the database. If the directory does not exist, the command creates it. If the directory cannot be created, or read or written to, an error is returned.

    For example:

    WikisDataIntegrityService.checkFiles("C:/wikis_integrity")


    WikisPrintService

    WikisPrintService.saveToFile(string object, string filePath, string append)

    Prints information returned by other commands to a file.

    Parameters:

    object

    A command with parameters that returns a Map or List<Map> java object. You can use any of the following commands:

    • WikisMemberService.getById (returns a Map)

    • WikisMemberService.getByExtId (returns a Map)

    • WikisMemberService.getByEmail (returns a Map)

    • WikisLibraryService.getById (returns a Map)

    • WikisLibraryService.browseWiki (returns a List<Map>)

    • WikisPolicyService.getById (returns a Map)

    • WikisPolicyService.browse (returns a List<Map>>)

    • WikisMetricsService.browse (returns a List<Map>)

    filePath

    A path to a file in which to save the object data. The data is saved in comma-separated value (.csv) format.

    append

    string whose default value is "true". Change to "false" to have the command overwrite the existing file instead of appending the data in the existing file.

    Example:

    WikisPrintService.saveToFile(WikisLibraryService.browseWiki("title","true", 1, 20), "/opt/wsadmin/LibraryMap.txt")


    WikisScheduler

    WikisScheduler.pauseSchedulingTask(string taskName)

    Suspends scheduling of a task. Has no effect on currently running tasks. Returns a 1 to indicate that the task has been paused. Paused tasks remain paused until you explicitly resume them, even if the server is stopped and restarted.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.pauseSchedulingTask("DirectoryGroupSynch")

    WikisScheduler.resumeSchedulingTask(string taskName)

    Resumes the start of a paused task. Returns a 1 to indicate that the task has been resumed.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.resumeSchedulingTask("DirectoryGroupSynch")

    WikisScheduler.forceTaskExecution(string taskName, string executeSynchronously)

    Executes a task. Returns a 1 to indicate that the task has been executed.

    Property settings in the wikis-config.xml configuration properties file specify whether tasks are enabled to run automatically, and how often. This command allows you to run tasks manually, for example if you disabled a task but want to run it occasionally.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    executeSynchronously

    Takes the string values true or false. Specifying this value is not required; the default is false. If this value is false, then the task executes asynchronously, meaning if the taskId is valid the command returns immediately and the execution continues in the background. If this value is true, it the command does not return until the task completes.

    For example:

    WikisScheduler.forceTaskExecution("DirectoryGroupSynch")

    WikisScheduler.getTaskDetails(string taskName)

    Displays status of a task. Returns detailed status message.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.getTaskDetails("DirectoryGroupSynch")


    WikisPolicyService

    WikisPolicyService.add(string title, long maximumSize)

    Creates a policy with a specified title and maximum size. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    When a policy is created, an ID is created for it and returned to you. The ID is in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must provide policy IDs as parameters when running other WikisPolicyService commands.

    Policies can be applied to libraries using the WikisLibraryService.assignPolicy or WikisLibraryService.assignPolicyBatch commands.

    Parameters:

    title

    The policy title. A required value.

    maximumSize

    The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.add("My Policy", 2147483648L)

    WikisPolicyService.edit(string policyId, string title, long maximumSize)

    Edits the title and maximum size of a policy with a specified ID. If the ID is for a default policy, the title is not modified. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    policyID

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    title

    The policy title. A required value.

    maximumSize

    The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.edit("2d93497d-065a-4022ae25-a4b52598d11a", "My Policy", 2147483648L)

    WikisPolicyService.getById(string id)

    Returns information for a single policy specified by an ID. Policies set a maximum size limit on libraries.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    id

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: the ID

    • title: the policy title

    • maximumSize: the maximum size (in bytes) the library can be, or 0 for unlimited

    For example:

    WikisPolicyService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisPolicyService.browse(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

    Returns a list of policies with ID, title, and maximum size information, as described for the WikisPolicyService.getById(id) command. Policies set a maximum size limit on libraries.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    sortOption

    A string value that specifies how to sort the list. The default value is title, but you can also use maximumSize.

    sortAscending

    A string value that specifies whether the list sorts in ascending alphabetical order. This depends on sortOption. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

    pageNumber

    The number of the page to return. For example, if the itemsPerPage value is 40, and pageNumber value is 2, the command returns items 41 to 80 (page 2) instead of 1 to 40 (page 1).

    itemsPerPage

    The maximum number of policies to list per page. The default value is 20.

    For example:

    WikisPolicyService.browse("title", "true", 1, 25)

    WikisPolicyService.getCount()

    Returns the number of policies. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    WikisPolicyService.editDefault(long maximumSize)

    Sets the maximum size, in bytes, for the personal wiki library default policy. Personal wikis are owned by a person.

    Parameters:

    maximumSize

    A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.editDefault(2147483648L)

    WikisPolicyService.editCommunityDefault(long maximumSize)

    Sets the maximum size, in bytes, for the community wiki library default policy. Community wikis are owned by a community.

    Parameters:

    maximumSize

    A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.editCommunityDefault(2147483648L)

    WikisPolicyService.delete(string id)

    Deletes the policy specified by the ID. You cannot delete default policies or policies in use by any libraries.

    id

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisPolicyService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")


    WikisMetricsService

    WikisMetricsService.browse(string startDate, string endDate, string filePathWithFilterKeys)

    Returns metrics about wikis stored in the database. The same metrics are provided for each day in a specified period.

    If you do not specify dates, then the command uses the first available day with data for startDate, and the last available day with data for endDate.

    See the topic Wikis metrics for metrics and their descriptions.

    Parameters:

    startDate

    The start date for the period, in YYYY-MM-DD format. This date is included in the returns, for example a start date of "2009-01-01" will include metrics from January 1, 2009. It must be in quotes, for example "2009-01-01".

    endDate

    The end date for the period, in YYYY-MM-DD format. This date is included in the returns, for example an end date of "2009-01-10" will include metrics from January 10, 2009. It must be in quotes, for example "2009-01-10".

    filePathWithFilterKeys

    Optional: The full path to a text file in which each line contains a statistical key. If you specify a file, only metrics listed in the file are returned. If you do not specify a file, all data is returned.

    For example:

    WikisMetricsService.browse("2009-01-01", "2009-01-10", "C:/connections/wikis/metrics.txt")

    WikisMetricsService.saveToFile(string filePath, string startDate, string endDate, string filePathWithFilterKeys, string append)

    Returns metrics about wikis and exports them to a local file. The same metrics are provided for each day in a specified period.

    If you do not specify dates, then the command uses the first available day with data for startDate, and the last available day with data for endDate.

    See the topic Wikis metrics for metrics and their descriptions.

    Parameters:

    filePath

    Path to a file in which to export the metrics. Metrics are exported in comma separated value (CSV) format. If you specify a file name with a .csv extension, it is possible to open it as a spreadsheet. See Importing statistics and metrics into a spreadsheet.

    startDate

    The start date for the period, in YYYY-MM-DD format. This date is included in the returns, for example a start date of "2009-01-01" will include metrics from January 1, 2009. It must be in quotes, for example "2009-01-01".

    endDate

    The end date for the period, in YYYY-MM-DD format. This date is included in the returns, for example an end date of "2009-01-10" will include metrics from January 10, 2009. It must be in quotes, for example "2009-01-10".

    filePathWithFilterKeys

    Optional: The full path to a text file in which each line contains a metric key. If you specify a file, only metrics listed in the file are returned. If you do not specify a file, all data is returned. For example, if the file lists these three keys, then only these metrics are returned:

    wikis.metric.user.count
    wikis.metric.user.created.today.count
    wikis.metric.user.login.count

    append

    String whose default value is "true". Change to "false" to have the command overwrite the existing file instead of appending the data in the existing file.

    For example:

    WikisMetricsService.saveToFile("C:/connections/wikis/metrics.csv", "2009-01-01", "2009-01-10", "C:/connections/wikis/metric_keys.txt", "false")

    WikisMetricsService.getAvailableRange()

    Returns a string array

    ...where the first element is the first day data is available and the second element is the last day that data is available for wiki libraries. Typically, the current day's data is not available until 12:01 A.M. the following day.

    If metrics collection was disabled or did not occur because of some issue, there may be gaps in data available.


    WikisUtilService

    WikisUtilService.filterListByString(List listOfMaps, string filterKey, string regexstringCriteria)

    Returns maps from a specified list that have a specified key matching a specified regular expression. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    regexstringCriteria

    A regular expression represented as a string to match against the filterKey value. For example, "[0-9]+" to match only >= 1 numbers in a row.

    The command returns maps from the listOfMaps whose filterKey is the regexstringCriteria value. For example, this command shows only the returned maps whose title values match the expression "Development*":

    WikisUtilService.filterListByString(WikisLibraryService.browseWiki("title", "true", 1, 25), "title", "Development*")

    WikisUtilService.filterListByDate(List listOfMaps, string filterKey, expression)

    Returns maps from a specified list that have a specified key with a specified date. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    expression

    A string of the form <operator> <date> where <date> is in yyyy-MM-dd format and <operator> is one of the following: > >= == <= <

    The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose creation date is on or later than January 1, 2010:

    WikisUtilService.filterListByDate(WikisLibraryService.browseWiki("title", "true", 1, 25), "createDate", ">=2010-01-01")

    WikisUtilService.filterListByNumber(List listOfMaps, string filterKey, expression)

    Returns maps from a specified list that have a specified key with a specified number. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    expression

    A string of the form <operator> <int> where <int> is an integer and <operator> is one of the following: > >= == <= <

    The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose percentUsed value (which reflects the percent of the library's available space that is currently used) is 20:

    WikisUtilService.filterListByNumber(WikisLibraryService.browseWiki("title", "true", 1, 25), "percentUsed", "==20")

    WikisUtilService.getFileById(string fileID)

    Returns the file path location of the wiki page file attachment identified by a provided file ID. Returns a path even if the file is not in use.

    Use this command to find the location of any file attachment stored in the shared file directory. This can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

    fileID

    The ID of a file in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisUtilService.getFileById("2d93497d-065a-4022ae25-a4b52598d11a")


    Related

  • Synchronize user data using administrative commands
  • IBM Connections APIs

  • Run administrative commands
  • Compare remote application data with the Communities database
  • Check Wikis data integrity
  • Back up Wikis data
  • Synchronize remote application data with the Communities database

  • Wikis configuration properties

    Back up Wikis data

    Wikis stores data in both the database and a file system. This adds some complication when backing up data while keeping the application available to users.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Wikis stores a large amount of data. If it were only stored in a database, maintenance and backups would be complex and costly. To prevent this, Wikis only stores file meta-data in the database, and stores binary files in a data directory on a file system. You specify this directory during IBM Connections installation, and you can find it at any time in the wikis-config.xml properties file in the file.storage.rootDirectory element.

    The file.storage.rootDirectory element will contain either the path itself, or a WebSphere Application Server variable whose value is the path. If it contains a variable, you can find the path by opening the WebSphere Application Server console, clicking Environment > WebSphere Variables, and finding the variable. For example, if the element's value is ${WIKIS_CONTENT_DIR}, find WIKIS_CONTENT_DIR in the console to find the path. See the topic Changing configuration property values for information on opening the wikis-config.xml file.

    File data is actually stored in unique directories below a storage_root_directory/files/files directory. Each file's data is stored in a sub-directory below /files, generated from the file's randomly generated UUID. Part of the UUID is used to create a directory with a number between 0 and 127. Another part is used to create a directory below that, with another number between 0 and 127, and the UUID itself is located in that directory. For example:

    storage_root_directory/files/18/113/<file_UUID>

    Files are only written once, so their identities are clear if one is missing during a restore.

    This storage architecture means you must maintain consistency between the database and file system during backups. The simplest way to maintain consistency is to perform "off-line" backups, making the application inaccessible and then backing up both locations. But often you will want to perform "on-line" backups, keeping the application accessible. During an on-line backup, users can continue to add and delete content from the application.

    During on-line backups of Wikis, you must back up the database before the file system. The database enforces transactional integrity between the two locations. If you back up the file system first, files added between the time the file system backup starts and the database backup later completes will be missing from the file system on restoration. Back up the database first ensures that you capture all new files during backup.

    You must also stop a file-deletion task from running during on-line backup. When a user deletes a file it is removed from the user interface, but the application actually adds it to a queue of files that must be deleted from the file system. This task runs regularly to delete the first item from the queue. You can also increase the time files can sit in the queue before they are deleted, by adjusting the value in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property in wikis-config.xml. This could give you enough time to run incremental backups and make sure your archive is never missing data. For information on editing wikis-config.xml, see the topic Changing configuration property values. For information on the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property see the topic Wikis configuration properties.

    To perform an on-line backup of Wikis complete the following steps:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Stop the task that deletes files from the queue with the following command:

      WikisScheduler.pauseSchedulingTask("FileActuallyDelete")

    4. Back up the database according to the database documentation.

    5. Back up the file system in whatever way makes sense in your environment. For example, for small deployments you can just zip the system, or for large deployments you can use a tool like Tivoli Storage Manager.

    6. Start the task that deletes files from the queue with the following command:

      WikisScheduler.resumeSchedulingTask("FileActuallyDelete")


    What to do next

    You can run a task that checks for inconsistencies between the database and the file system. It might be useful to compare database and file system images in a test environment before restoring them. See the topic Check Wikis data integrity for more information.


    Related tasks

  • Start the wsadmin client
  • Maintain application DBs
  • Change Wikis configuration property values

  • Wikis administrative commands
  • Wikis configuration properties


    Check Wikis data integrity

    The appropriate way to restore backed-up Wikis data is to restore versions of file system data and database data that match. You can check integrity between database data (metadata) and file system data (binary) by running the WikisDataIntegrityService.checkFiles command.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    The WikiDataIntegrityService.checkFiles command moves files found on the file system, but not in the database, to a file path location you specify in the command. You might want to delete these extra files, or back them up if you think you might need them for a future Files backup. Users cannot download files if they are missing from the database.

    Before running the WikisDataIntegrityService.checkFiles command, create the target path_to_extra_filesDirectory folder. This folder will be used to save unused files during the integrity check. Create the folder on the device from which you will run the command.

    If you are running the command on Linux or AIX, ensure that you have correct write permissions enabled for the folder.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Check the integrity of data in the database and file system directory with the following command: On

      Windows:

      WikisDataIntegrityService.checkFiles("C:\path_to_extra_wikisDirectory")
      On Linux or AIX:

      WikisDataIntegrityService.checkFiles("/opt/path_to_extra_wikisDirectory")


    Related tasks

  • Start the wsadmin client

  • Wikis administrative commands


    Synchronize Wikis data with Communities data

    Use the WikisLibraryService.exportSyncedResourceInfo command to return a report of all of the communities that Wikis has interacted with. The information in this report can help you to synchronize Wikis data with the Communities database after a system crash that includes data loss.

    See the Communities topic Recovering from a database failure for information.


    Related

  • Recover from a database failure

    Restrict attachment file types in Wikis

    Restrict the types of files that users can upload as attachments in wiki pages.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    You can create a list of denied file extensions and prevent users from uploading files with those extensions. Or you can create a list of allowed file extensions and only allow users to upload files with those extensions.

    Restrict file types affects users uploading new files, or changing the extensions of existing files. (Users cannot change existing files to a denied type.) But existing documents with denied extensions are not affected. For example, if you deny the .xls extension, users cannot upload .xls files or change existing files to have the .xls extension. But existing .xls files are not affected, and users can still upload new versions of them.

    This is not intended as a security application. Files are not analyzed to determine their type, only the file name is read to allow or deny (with an error) the upload. This is only to help you restrict the types of files you store in your environment.

    Perform the following steps to restrict file types in Wikis:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Open wikis-config.xml.

    4. In the <restrictions> element in the <file> section, specify the enabled attribute as true.

    5. In the <restrictions> element in the <file> section, specify the mode attribute as one of the following values:

      • A value of allow means the extensions in the list are the only ones allowed to be uploaded.

      • A value of deny means the extensions in the list are the only ones not allowed to be uploaded.

    6. In the <restrictions> element, add an <extensions> element, and within the <extensions> element add one or more <extension> elements, each containing a file extension to allow or deny.

    7. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Example

    <file>
     ....
     <restrictions enabled="true" mode="allow">
      <extensions>
    	 <extension>odt</extension>
    	 <extension>odp</extension>
    	 <extension>ods</extension>
      </extensions>
     </restrictions>
    </file>

    In the previous example, .odt, .odp, and .ods IBM Lotus Symphony. extensions are the only extensions users can upload. Case is ignored, and you can use values with or without periods. For example, odt, .odt, and ODT are all valid.

    Use an empty <extension> element to allow or deny files without extensions, or with extensions that exceed the platform limit of 16 characters.


    Related tasks

  • Apply Wikis property changes

  • Wikis configuration properties

    Set maximum sizes on media, pages, and attachments

    You can set maximum sizes for media, pages, and attachments in the wikis-config.xml properties file.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    You may want to set maximum sizes on media, pages, and attachments to control the size of these individual objects within the larger library size setting. See the topic Set maximum sizes on libraries for more information.

    In Wikis, pages are a type of media, so the maximum setting for pages cannot be larger than the maximum setting for media. Attachments have no relationship to media or pages, and can be any maximum size, however if you let people attach very large files you must make sure that network and browser timeout settings allow users to download those large files.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view the current configuration settings use the following command:

      WikisConfigService.showConfig()

    4. To set a maximum size (in kilobytes) for media, pages, and attachments, use the following commands:

      WikisConfigService.updateConfig("file.media.maximumSizeInKb", "<number_of_kilobytes>")

      WikisConfigService.updateConfig("file.page.maximumSizeInKb", "<number_of_kilobytes>")

      WikisConfigService.updateConfig("file.attachment.maximumSizeInKb", "<number_of_kilobytes>")

      IBM recommends that the attachment maximum size be below 2GB. Files larger than that are likely to reach browser or server limitations.

    5. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Related tasks

  • Required post-customization step
  • Set maximum sizes on libraries
  • Start the wsadmin client
  • Apply Wikis property changes

    Set maximum sizes on libraries

    Use WikisLibraryService commands to set maximum sizes on libraries by assigning them a policy. A library is the pages, attachments, and other data that make up a wiki. A policy sets a maximum size for a library.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Create a policy to specify the library size, using steps in the topic Working with policies.

    4. Run the following commands to set maximum sizes on libraries:

      WikisLibraryService.assignPolicy(string libraryId, string policyId)

      Assigns a policy to a library. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments. A policy sets a maximum size for a wiki.

      No message is printed if the task succeeds.

      Parameters:

      libraryId

      The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      policyId

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisLibraryService.assignPolicy("f0d01111-9b21-4dd8-b8be-8825631cb84b", "2d93497d-065a-4022ae25-a4b52598d11a")

      WikisLibraryService.assignPolicyBatch(string filePath)

      Assigns policies to libraries as specified in a text file. The file must contain a list of library-policy ID pairs, one pair per line, values separated by a comma. For example: libraryId, policyId. Extra whitespace is ignored. You must create this text file and save it in a directory local to the server where you are running the wsadmin processor.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      filePath

      The full path to the text file, as a string.

      For example:

      WikisLibraryService.assignPolicyBatch("C:/connections/assign_policies.txt")


    Related tasks

  • Set maximum sizes on media, pages, and attachments
  • Start the wsadmin client
  • Work with Wikis policies

    Work with Wikis policies

    Use the WikisPolicyService commands to add, edit, count, and return information about policies. You apply policies to libraries to set a maximum size on those libraries. A library is a set of files owned by a person or community.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to work with policies:

      WikisPolicyService.add(string title, long maximumSize)

      Creates a policy with a specified title and maximum size. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      When a policy is created, an ID is created for it and returned to you. The ID is in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must provide policy IDs as parameters when running other WikisPolicyService commands.

      Policies can be applied to libraries using the WikisLibraryService.assignPolicy or WikisLibraryService.assignPolicyBatch commands.

      Parameters:

      title

      The policy title. A required value.

      maximumSize

      The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.add("My Policy", 2147483648L)

      WikisPolicyService.edit(string policyId, string title, long maximumSize)

      Edits the title and maximum size of a policy with a specified ID. If the ID is for a default policy, the title is not modified. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      policyID

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      title

      The policy title. A required value.

      maximumSize

      The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.edit("2d93497d-065a-4022ae25-a4b52598d11a", "My Policy", 2147483648L)

      WikisPolicyService.getById(string id)

      Returns information for a single policy specified by an ID. Policies set a maximum size limit on libraries.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      id

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

      • id: the ID

      • title: the policy title

      • maximumSize: the maximum size (in bytes) the library can be, or 0 for unlimited

      For example:

      WikisPolicyService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

      WikisPolicyService.browse(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

      Returns a list of policies with ID, title, and maximum size information, as described for the WikisPolicyService.getById(id) command. Policies set a maximum size limit on libraries.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      sortOption

      A string value that specifies how to sort the list. The default value is title, but you can also use maximumSize.

      sortAscending

      A string value that specifies whether the list sorts in ascending alphabetical order. This depends on sortOption. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

      pageNumber

      The number of the page to return. For example, if the itemsPerPage value is 40, and pageNumber value is 2, the command returns items 41 to 80 (page 2) instead of 1 to 40 (page 1).

      itemsPerPage

      The maximum number of policies to list per page. The default value is 20.

      For example:

      WikisPolicyService.browse("title", "true", 1, 25)

      WikisPolicyService.getCount()

      Returns the number of policies. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      WikisPolicyService.editDefault(long maximumSize)

      Sets the maximum size, in bytes, for the personal wiki library default policy. Personal wikis are owned by a person.

      Parameters:

      maximumSize

      A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.editDefault(2147483648L)

      WikisPolicyService.editCommunityDefault(long maximumSize)

      Sets the maximum size, in bytes, for the community wiki library default policy. Community wikis are owned by a community.

      Parameters:

      maximumSize

      A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.editCommunityDefault(2147483648L)

      WikisPolicyService.delete(string id)

      Deletes the policy specified by the ID. You cannot delete default policies or policies in use by any libraries.

      id

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisPolicyService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")


    Related tasks

  • Start the wsadmin client

    See Wikis library information

    Use the WikisLibraryService commands to see information on Wikis libraries. A library is the pages, attachments, and other data that make up a wiki.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to return information about libraries:

      WikisLibraryService.getById(string libraryId)

      Returns information about a single library specified by an ID. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      libraryId

      The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

      • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

      • type: The type of library. The only valid value is wiki.

      • label: A string of characters used to identify the library in a URL.

      • title: The library's title.

      • summary: A summary of library information.

      • size: The total size of the library binary data.

      • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

      • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

      • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • lastUpdate: The last time a significant user-driven update occurred to the metadata.

      • createDate: The library's creation date.

      • externalInstanceId: The widget ID if the library is owned by a community.

      • externalContainerId: The community ID if the library is owned by a community.

      • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

      • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

      For example:

      WikisLibraryService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

      WikisLibraryService.browseWiki(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

      Returns a list of all wikis, with information about each wiki. The list includes wikis owned by communities, and wikis whose owners were removed from the user directory.

      Parameters:

      sortOption

      A string value that specifies how to sort the list. The default value is title, but you can use lastUpdate, size, createDate, or quotaPercentage.

      sortAscending

      A string value that specifies whether to sort the list in ascending alphabetical order. This depends on the sortOption value. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

      pageNumber

      The number of the page to display. For example, if you specify in the itemsPerPage parameter that each page will have 50 items, page 1 will contain items 1-50.

      itemsPerPage

      The maximum number of wikis to list per page. The default value is 20. The following information is returned:

      • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

      • type: The type of library. The only valid value is wiki.

      • label: A string of characters used to identify the library in a URL.

      • title: The library's title.

      • summary: A summary of library information.

      • size: The total size of the library binary data.

      • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

      • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

      • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • lastUpdate: The last time a significant user-driven update occurred to the metadata.

      • createDate: The library's creation date.

      • externalInstanceId: The widget ID if the library is owned by a community.

      • externalContainerId: The community ID if the library is owned by a community.

      • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

      • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

      For example:

      WikisLibraryService.browseWiki("title", "true", 1, 25)

      WikisLibraryService.getWikiCount()

      Returns the total number of wikis.

      WikisLibraryService.exportSyncedResourceInfo (string fullpathForOutput, string type)

      Returns a report of all of the communities that the Wikis application has interacted with. After a system crash you can compare the report to the latest metadata in the Communities database to help synchronize and update any missing data. See the topic Comparing remote application data with the Communities database for more information.

      Note that in clusters, when you run the command from the deployment manager the path and file are created on the server running Wikis. In clusters

      ...where multiple nodes are running Wikis, you are asked choose a server to connect to and run the command on, and then the path and file are created on that server.

      Parameters:

      fullPathforOutput

      The full path location where you want the report, and the report filename, as a string in quotes. The report is an XML file. Use forward slashes ("/") in the path, even on Microsoft Windows computers.

      type

      This is always the string value, "community" (including quotes). An error is returned if this is anything except "community".

      For example:

      WikisLibraryService.exportSyncedResourceInfo("c:/connections/sync/community_output.xml", "community")


    Related tasks

  • Start the wsadmin client
  • Compare remote application data with the Communities database

    Filter library lists

    Use the WikisUtilService commands to filter lists of library maps returned by the WikisLibraryService.browseWiki command. You can filter a list of library maps by a certain string value, a certain date value, or a certain number value.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    Browse commands, such as WikisLibraryService.browseWiki, return List<Map> java objects. A List<Map> object is a list of Map java objects. Maps are lists of key/value pairs. For example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values are information about the library, such as its title and creation date.

    You filter a list by specifying that it should only return maps that have a specified key with a specified string value, date value, or number value.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to filter a list of library maps:

      WikisUtilService.filterListByString(List listOfMaps, string filterKey, string regexstringCriteria)

      Returns maps from a specified list that have a specified key matching a specified regular expression. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      regexstringCriteria

      A regular expression represented as a string to match against the filterKey value. For example, "[0-9]+" to match only >= 1 numbers in a row.

      The command returns maps from the listOfMaps whose filterKey is the regexstringCriteria value. For example, this command shows only the returned maps whose title values match the expression "Development*":

      WikisUtilService.filterListByString(WikisLibraryService.browseWiki("title", "true", 1, 25), "title", "Development*")

      WikisUtilService.filterListByDate(List listOfMaps, string filterKey, expression)

      Returns maps from a specified list that have a specified key with a specified date. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      expression

      A string of the form <operator> <date> where <date> is in yyyy-MM-dd format and <operator> is one of the following: > >= == <= <

      The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose creation date is on or later than January 1, 2010:

      WikisUtilService.filterListByDate(WikisLibraryService.browseWiki("title", "true", 1, 25), "createDate", ">=2010-01-01")

      WikisUtilService.filterListByNumber(List listOfMaps, string filterKey, expression)

      Returns maps from a specified list that have a specified key with a specified number. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      expression

      A string of the form <operator> <int> where <int> is an integer and <operator> is one of the following: > >= == <= <

      The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose percentUsed value (which reflects the percent of the library's available space that is currently used) is 20:

      WikisUtilService.filterListByNumber(WikisLibraryService.browseWiki("title", "true", 1, 25), "percentUsed", "==20")

      WikisUtilService.getFileById(string fileID)

      Returns the file path location of the wiki page file attachment identified by a provided file ID. Returns a path even if the file is not in use.

      Use this command to find the location of any file attachment stored in the shared file directory. This can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

      fileID

      The ID of a file in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisUtilService.getFileById("2d93497d-065a-4022ae25-a4b52598d11a")


    Related tasks

  • Start the wsadmin client

    Print library information

    Use the WikisPrintService.saveToFile command to print information returned by other commands.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    This command prints Map or List<Map> java objects returned by any of the following commands:

    A List<Map> object is a list of Map java objects. Maps are lists of key/value pairs. For example the WikisLibraryService.browseWiki command returns a list of library maps. (A library is the pages, attachments, and other data that make up a wiki.) Each map in the list has a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values are information about the library, such as its title and creation date.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run one the following command to print library information returned by other commands:

      WikisPrintService.saveToFile(Object object, String filePath, String append)

      where object is a Map or List<Map> type of java object. You provide the command that returns the object, for example, WikisLibraryService.browseWiki(parameters), which returns a List<Map> object.

      The filePath parameter is the location where you want the data printed in a comma-separated value (.csv) file.

      The append parameter determines whether to append the returned information to information in an existing file. If true (the default), returned information is appended, if false the file is overwritten.

      For example:

      WikisPrintService.saveToFile(WikisLibraryService.browseWiki("title","true",1,20), "/opt/wsadmin/LibraryMap.csv")

      In this example the command runs WikisLibraryService.browseWiki with the given parameters, then prints the output to the LibraryMap.csv file. Because the append parameter is left at the default value of true, running the same command again will append the new data in the existing LibraryMap.csv. Here is an example of returned data printed to a file:

      "id","createDate","label","lastUpdate","maximumSize","orphan","ownerUserId",
      "percentUsed","policyId","size","summary","title","type","externalInstanceId","externalContainerId"
      "ef8ed3e2-22c0-4f20-aa53-bdc6b262abbd","2009-06-25 12:30:32.797","5adff8c0-7d67-102c-8452-e2ebc3ec5536","2009-06-25 12:30:32.797","524288000","false","9ddb97f0-cea5-49fd-9158-06e45b01cd46","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones1","personal","",""
      "30676b64-c792-46d1-9c21-bcea1f3350cf","2009-06-25 16:23:23.354","5b788f40-7d67-102c-8464-e2ebc3ec5536","2009-06-25 16:23:23.354","524288000","false","1c00bd59-20c1-48ea-857b-9c998670d715","8.170700073242188E-5","00000000-0000-0000-0000-000000000000","42838","","Amy Jones10","personal","",""
      "547b8f88-0cb9-4f84-95c2-382f235fe251","2009-06-26 10:57:57.384","5b788f40-7d67-102c-8468-e2ebc3ec5536","2009-06-26 10:57:57.384","524288000","false","a25fd14a-70d2-4978-b814-9e05f9b56503","3.90625E-5","00000000-0000-0000-0000-000000000000","20480","","Amy Jones12","personal","",""
      "605ff4d6-956a-446f-a393-4995057213c5","2009-06-26 16:15:58.778","5ca9bc40-7d67-102c-847c-e2ebc3ec5536","2009-06-26 16:15:58.778","524288000","false","5a79bd44-e5d1-4b4d-b51f-338eff519636","3.1642913818359376E-6","00000000-0000-0000-0000-000000000000","1659","","Amy Jones23","personal","",""
      "86aa4152-c661-4aae-ac7c-ca04da570715","2009-06-25 17:29:16.162","5ddae940-7d67-102c-849e-e2ebc3ec5536","2009-06-25 17:29:16.162","524288000","false","82252a4e-1355-4518-930c-983d7085ad6e","2.63214111328125E-7","00000000-0000-0000-0000-000000000000","138","","Amy Jones40","personal","",""
      "fb9f97fe-0c41-4276-96f0-f1c91478df68","2009-06-25 11:52:22.843","5e737fc0-7d67-102c-84b2-e2ebc3ec5536","2009-06-25 11:52:22.843","524288000","false","8daf28ad-f51e-4ef3-8990-283c9fd4574a","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones50","personal","",""
      "179be703-7e44-45f5-9fa8-eeab1f46e896","2009-06-25 18:17:38.639","5f0c1640-7d67-102c-84c6-e2ebc3ec5536","2009-06-25 18:17:38.639","524288000","false","3a99634c-fd29-4966-ae6f-217472f5439c","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones60","personal","",""


    Related tasks

  • Start the wsadmin client

    Disable wiki page versioning

    By default users can see all of the versions of a wiki page. You can disable versioning in the wikis-config.xml properties file.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    Disable versioning can help control the size of data storage. When you disable versioning before users start using Wikis, only one version of a page is ever stored, and all updates are reflected in that version.

    However, you can disable versioning at any time. If there are already multiple versions of a page when you disable versioning, the latest version becomes the "active" version, and all future updates are reflected in that version. The older versions are hidden from the user interface, but still exist and take up space in the database. If a user reaches their space quota, you can delete these older versions by enabling versioning again and having the user open the file page, click the Versions tab, and delete versions.

    You can also perform a manual database update to remove all versions of files prior to the current ones. You would execute a delete statement on your database for the MEDIA_REVISION table, but you must specify a constraint that the column IS_CURRENT_REVISION = 0, as a record still exists for the current version.

    Remember that in Wikis file attachments, which are not versioned, take up the most space. Only pages are versioned. So depending on your environment you may not need to disable versioning at all.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view the current configuration settings use the following command:

      WikisConfigService.showConfig()

    4. To set the file.versioning.enabled property to false, use the following command:

      WikisConfigService.updateConfig("file.versioning.enabled", "false")

    5. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Related tasks

  • Start the wsadmin client
  • Apply Wikis property changes

    Delete wikis from the system

    Use the WikisLibraryService delete commands to delete wikis.

    Use wikis administrative commands to see wiki library information to help you decide what wikis to delete, for example the WikisLibraryService.browseWiki command returns a list of wikis with information on each wiki. Use the returned information to see which wikis have not been updated in a long time. See the topic Wikis administrative commands for detailed information.

    To use administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    In the Wikis database context, a library contains the pages, attachments, and other data that make up a wiki. Wikis can be owned by a person or a community. However, you should delete community libraries following steps in the topic Deleting orphaned data.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run one of these commands to delete libraries:

      • Run this command to delete a single library:

        WikisLibraryService.delete(libraryId)

        where libraryId is the library id in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • Run this command to delete multiple libraries:

        WikisLibraryService.deleteBatch(filePath)

        where filePath is the full path to a text file containing a list with a single library id per line in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must create the file and save it in a directory local to the server where you are running the wsadmin processor.


    Related tasks

  • Print library information
  • Delete orphaned data
  • Start the wsadmin client

    Find the location of a stored attachment

    Use the FilesUtilService.getFileById command to locate a file attachment stored in a directory on a file system.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    In network deployments, files attached to wiki pages are stored on a shared file system, as described in the topic Install the first node of a cluster.

    This command can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following command to locate a file attachment stored in the file directory:

      WikisUtilService.getFileById(fileId)

      where fileID is the ID of a file stored in the database. The ID must be a string in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      The command returns the file path as a string, even if the file is not in use.

    Display file attachments inline

    Configure Wikis to display file attachments inline instead of as attachments. This is useful when you download and display active content, such as Adobe Flash (.swf) files, in your own HTML pages. Enable inline display by changing a configuration property in the wikis-config.xml file. Then change the attachment URLs to use inline parameter.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    By default, the IBM Connections server passes Wikis application file attachments to browsers with the header "Content-Disposition: attachment." This means files display as attachments; when users click the attachment they are prompted to open or download the file. It also prevents embedding files. If you want to embed files in your own HTML page using an <embed> tag, the content disposition must be inline. This affects active content, such as Adobe Flash (.swf), and HTML pages referenced with <iframe>.

    Configure a property in wikis-config.xml to change the content disposition from attachment to inline.

    Important: Wikis uses the attachment disposition for security reasons. Specifically, uploaded files could potentially contain malicious code that can exploit the cross-site scripting vulnerabilities of some browsers. If you switch to inline disposition, you should configure an alternate domain download for greater security. See Mitigating a cross site scripting attack.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Change the content disposition to inline :

      WikisConfigService.updateConfig("security.inlineDownload.enabled", "true")

    4. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.

    5. Change your attachment URLs to use the inline parameter.

    Administer Wikis

    You administer Wikis using the wsadmin client to specify properties in a configuration file, or run administrative commands.

    You edit the configuration file to control how and when various Wikis operations take place. You use the administrative commands to perform tasks that manipulate Wikis content. Changes to the configuration file require node synchronization and a restart of the Wiki server before they take effect. Changes made using administrative commands take effect immediately.

    Change Wikis configuration property values

    Configuration properties control how and when various Wikis operations take place. You can edit the properties to change the ways that Wikis operates.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    In the client, you access scripts that use the AdminConfig object to interact with the configuration file. After changing the configuration properties, you must synchronize nodes and restart the Wikis server before the changes take effect.

    To edit Wikis configuration properties:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view a list of the valid Wikis configuration settings and their current values, use the following command:

      WikisConfigService.showConfig() Here is some sample output from the WikisConfigService.showConfig() command:

      Wikis configuration properties:
      	security.logout.href = /wikis/ibm_security_logout
      	activeContentFilter.enabled = true
      	cache.user.timeout = 43200000
      	cache.http.publicContentMaxAgeInSecs = 604800
      	db.dialect = DB2

    4. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly. To change a Wikis configuration setting, do one of the following:

      • To edit a property using the wsadmin client, use the following command:

        WikisConfigService.updateConfig("property", "value")

        where property is one of the editable Wikis configuration properties and value is the new value with which you want to set that property. See Wikis configuration properties for a complete list of editable properties. For example:

        WikisConfigService.updateConfig("file.page.maximumSizeInKb", "512")

      • To edit the value of a property in a configuration file directly, from the temporary directory to which you checked it out, open the file in a text editor, and then make your changes.

    5. Optional: Repeat step 4 for each single-value property setting to change.

    6. Optional: After updating the Wikis properties with new values, use the WikisConfigService.showConfig() command to display the list of properties and their updated values. These are the values that will be checked in with the WikisConfigService.checkInConfig() command.


    What to do next

    You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Wikis configuration properties

    Configuration properties control how and when various Wikis operations take place, and also help in the optimization of server performance. They require a Wikis server restart to take effect.

    The following are configuration properties in the wikis-config.xml file that you can modify. Note the following restrictions on the values allowed in the file:

    • All configuration properties (except those with multiple values) are required.

    • .enabled properties must have boolean values true or false.

    • Number values must be integers.

    activeContentFilter.enabled

    Specifies the mime types that are scanned and scripts removed from wiki pages when they are viewed.

    You can disable this filter by changing the value to false, but that might leave your environment open to cross-site scripting attacks unless you have taken other security precautions. For more information on securing against cross-site scripting attacks, see the topic Securing applications from malicious attack.

    api.indent.enabled

    Specifies whether the Wikis service API output is indented. This is false by default. To enable indentation, specify true.

    Enable this property to help with development and debugging. It is disabled by default because it does affect performance.

    cache.http.publicContentMaxAgeInSecs

    Maximum age of the public content cache before it is refreshed, in seconds. The public content cache stores static web resources, such as JavaScript. and images. Lower this value to show resource changes more quickly.

    The value must be greater than or equal to 0.

    You can force a resource update by opening the LotusConnections-config.xml common configuration properties file and setting the versionStamp property to any token. The token is included in most urls, and urls cache by path and cache header, so the new url overrides the old version and refreshes the resources. For information, see the topic Common configuration properties.

    Some resources, such as some images, do not use version stamps. If you edit those frequently, you can lower the cache.http.publicContentMaxAgeInSecs value to show changes more quickly. If not, you can leave the value high and update the version stamp when you make changes.

    cache.http.publicFeedMaxAgeInSecs

    Maximum age of the public feed cache before it is refreshed, in seconds. Public feeds pass information to the Public Wikis view. You may want to raise this value in very large deployments (for example, over 200,000 wikis) to avoid performance issues. It could also be lowered to have very up-to-date information in the public view.

    The value must be greater than or equal to 0.

    cache.user.timeout

    Number of milliseconds user objects stay in the user information cache. The user information cache stores metadata about users, such as names and email addresses. Use this property to control the frequency of requests to the Wikis database for user information.

    The value must be greater than or equal to 1.

    If the value of a user's data changes in the background (when the update user task or commands for MemberSynch are executed) the cache is invalidated.

    db.dialect

    Reflects the current database type, typically specified during installation. Accepts the values DB2, Oracle, or SQL Server.

    directory.community.membershipCache.maximumAgeOnLoginInSeconds

    Number of seconds after a user logs in that community membership cache is refreshed after user login. Only applicable if Community Wikis and Community Integration are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the community, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the community can access.

    You can lower the value here and then tell users that logging out and then in again is the best way to refresh the cache. This would allow you to increase the number of seconds in directory.community.membershipCache.maximumAgeOnRequestInSeconds so that frequent requests would not affect performance.

    directory.community.membershipCache.maximumAgeOnRequestInSeconds

    Number of seconds after an application request that the community membership cache is refreshed. Only applicable if Community Wikis and Community Integration are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the community, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the community can access.

    If you lower the value of directory.community.membershipCache.maximumAgeOnLoginInSeconds and then tell users that logging out and then in again is the best way to refresh the cache, you can increase this value to 10 or even 20 minutes, so that frequent requests will not affect performance.

    directory.group.membershipCache.maximumAgeOnLoginInSeconds

    Number of seconds after a user logs in that group membership cache is refreshed after user login. Only applicable if groups are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the group, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the group can access.

    You can lower the value here and then tell users that logging out and then in again is the best way to refresh the cache. This would allow you to increase the number of seconds in directory.group.membershipCache.maximumAgeOnRequestInSeconds so that frequent requests would not affect performance.

    directory.group.membershipCache.maximumAgeOnRequestInSeconds

    Number of seconds after an application request that the group membership cache is refreshed. Only applicable if groups are enabled.

    The value must be greater than or equal to 0.

    Refreshing the cache is required for a user to have the same access as the group, but it affects performance. A short time before refresh means Wikis is more up-to-date, but performance may be slower. A long time before refresh may affect performance less, but users do not have immediate access to what the group can access.

    If you lower the value of directory.group.membershipCache.maximumAgeOnLoginInSeconds and then tell users that logging out and then in again is the best way to refresh the cache, you can increase this value to 10 or even 20 minutes, so that frequent requests will not affect performance.

    directory.typeaheadSearch.maximumResults

    Maximum number of names to display when a user searches for user or group names in a search field. Sets a maximum for both typeahead results and search results (when they click the search icon).

    The value must be greater than or equal to 1.

    If the value is very large, such as 1000, and there are 1000 or more matches, all names are returned and performance is greatly reduced. If the value is low, such as 10, users typing a generic name might not see all matches.

    Typeahead only is available for public pages but not for filtered pages that might appear in Owner, Editor, or Reader views.

    download.modIBMLocalRedirect.enabled

    Specifies whether the IBM HTTP Server serves downloaded files instead of the WebSphere Application Server redirect servlet.

    You can configure IBM Connections to have the IBM HTTP Server download files. This is strongly recommended in production environments.

    If this property is set to true, you must also specify a URL in the download.modIBMLocalRedirect.hrefPathPrefix property. If the property is set to false, the WebSphere Application Server redirect servlet downloads files.

    To see information and steps for configuring the IBM HTTP Server to download files, see the topic Configuring Files and Wikis downloading for production deployments.

    download.modIBMLocalRedirect.hrefPathPrefix

    Path to the file system directory where Wikis data is stored. The file path should not include a trailing slash.

    This is only relevant if the download.modIBMLocalRedirect.enabled property is true.

    To see information and steps for configuring the IBM HTTP Server to download files, see the topic Configuring Files and Wikis downloading for production deployments.

    download.stats.logging.enabled

    Level of detail to log about page views. If false (the default), Wikis only logs the number of times a page is viewed. If true, Wikis logs the names of authenticated users who view pages.

    Specify true for a better user experience and auditing.

    editor.wikitexttab.enabled

    Specifies if the WikiText tab feature is enabled (default is false).

    You can enable this feature by changing the value to true.

    During migration from Connections version 3.0.x to 4.0 this configuration parameter is preserved.

    During migration from Connections version 3.0 to 4.0 this configuration parameter is set to false.

    file.attachment.maximumSizeInKb

    Maximum size allowed for file attachments, in kilobytes.

    The value must be greater than or equal to 1.

    Attachments larger than this setting will fail to upload and return an error to users. Use this to restrict users from uploading files that will negatively affect your system environment.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.media.maximumSizeInKb

    Maximum size allowed for media, in kilobytes. In Wikis, media are wiki pages.

    The value must be greater than or equal to 1.

    This property is useful if you want a relatively large quota size for libraries, but you do not want users attach very large files, such as .iso files.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.page.maximumSizeInKb

    Maximum size allowed for wiki pages, in kilobytes. Since pages are a type of media, this value must be less than or equal to the maximum size set in the file.media.maximumSizeInKb property.

    The value must be greater than or equal to 1.

    Pages larger than this setting will fail to upload and return an error to users. Use this to restrict users from uploading files that will negatively affect your system environment.

    After changing this value, the maximum size limit will not change for users until their browser cache is refreshed. You can force a refresh by running a command to update the product version stamp. See the topic Required post-customization step for more information on forcing a browser cache refresh.

    file.restrictions.enabled

    Enables or disables the ability to restrict the types of files that users can upload as attachments in Wikis. Accepts the values true or false.

    To see information and steps for restricting file types, see the topic Restricting attachment file types in Wikis.

    file.restrictions.mode

    Sets the mode for file extension restrictions. Accepts the values allow or deny. If the value is allow, then the list of file extensions are the only ones allowed to be uploaded as attachments. If the value is deny, then the list of extensions are not allowed, and all extensions not on the list are allowed.

    For example:

    <file>
     ....
     <restrictions enabled="true" mode="allow">
      <extensions>
       <extension>odt</extension>
       <extension>odp</extension>
       <extension>ods</extension>
      </extensions>
     </restrictions>
    </file>

    To see information and steps for restricting file types, see the topic Restricting attachment file types in Wikis.

    file.storage.rootDirectory

    Path to the file system directory where Wikis data is stored. This can be set during installation and be different for each node in a cluster. If a directory is specified in during installation this value (a variable by default) is populated by the WebSphere Application Server. However, you can specify any directory.

    IBM Connections looks for a /files and a /temp directory within this directory. If they are not there they are created. The /temp directory stores data while the data is uploaded or virus scanned (if enabled). The /files directory contains the binary data that must be backed up.

    For more information on backing up data, see the topic Back up data.

    file.versioning.enabled

    Specifies whether wiki page versioning is allowed. Specify true or false.

    If false, the versioning interface does not display and the first version is always current. If you disable this after multiple versions of a page are created the latest version becomes the current and only version.

    Note that new versions are created only when content changes, not title or tags or other metadata.

    Specify false to simplify and reduce data storage.

    See the topic Disabling wiki page versioning.

    scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours

    Number of hours that group information can remain in the Wikis database before the synchronization task can run on it. Does not run if groups are disabled.

    The value must be greater than or equal to 0.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any group information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    scheduledTasks.DirectoryGroupSynch.args.pauseInMillis

    Number of milliseconds that the synchronization task should wait before updating the next group's information. Use this to add a small amount of time between synchronizing items in the queue to avoid overloading your user directory as the task runs. Does not run if groups are disabled.

    The value must be greater than or equal to 0.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    Zero is an acceptable value if the remote user directory can handle many simultaneous queries.

    scheduledTasks.DirectoryGroupSynch.enabled

    Enables or disables the synchronization task for groups. The default is true.

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name. If the group name is not found in the user directory, it is removed from the database.

    scheduledTasks.DirectoryGroupSynch.interval

    Frequency with which the synchronization task runs.

    This property accepts a chronological expression.*

    The synchronization task runs automatically in the background, synchronizing group names in the Wikis database with the IBM Connections user directory. It queries the user directory with the directory ID and when it finds a match it synchronizes the group name.

    The task runs on any group information older than the value specified in the scheduledTasks.DirectoryGroupSynch.args.maximumDataAgeInHours property. It runs at a frequency specified in the scheduledTasks.DirectoryGroupSynch.interval property. It pauses between groups for the amount of time specified in the scheduledTasks.DirectoryGroupSynch.args.pauseInMillis property.

    Adjust this property to speed up or slow down the process of synchronizing group information.

    scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins

    Number of minutes that files must be in the pending deletion queue before the delete files task will delete them. For example, the default value of 720 means they will be deleted if they have been in the pending deletion queue 720 or more minutes.

    The value must be greater than or equal to 0.

    More pending time allows users to finish downloads of files added to the pending deletion queue. It also allows looser online back up policies. For example, for online backups that take less than this number of minutes you do not need to pause the file deletion task. To see more information about pausing the file deletion task during backups, see the topic Backing up data.

    scheduledTasks.FileActuallyDelete.enabled

    Enables or disables the delete files task. The default is true.

    The task deletes files if they are marked as pending deletion, and they are older than the value specified in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property.

    scheduledTasks.FileActuallyDelete.interval

    Frequency with which the delete files task runs.

    This property accepts a chronological expression.*

    Wikis are deleted if they are marked as pending deletion, and they are older than the value specified in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property.

    scheduledTasks.MetricsDailyCollection.enabled

    Specifies whether to collect metrics. Specify true or false.

    See the topic Wikis administrative commands for MetricService commands you can use to access metrics.

    The collection task runs near midnight in the server timezone, so all of the date-based metrics include data from most of a given day. Metrics entries only require a few kilobytes per day, so there is little performance impact to enabling them.

    scheduledTasks.MetricsDailyCollection.interval

    Frequency with which daily metrics collection task runs. Only the default is supported: the task can only run at midnight in the server timezone. Do not edit this property.

    scheduledTasks.TagUpdateFrequency.enabled

    Specifies whether to run the tag frequency update task. This task finds the most frequently used tags in public wikis and updates the public wikis tag cloud.

    scheduledTasks.TagUpdateFrequency.interval

    Frequency with which the tag frequency update task runs. This task finds the most frequently used tags in public wikis and updates the public wikis tag cloud and the autocomplete lists that display when users type a tag name in the tag filter field. For example, it measures how often the tag human-resources is used on pages in public wikis and updates the cloud and lists accordingly.

    This property accepts a chronological expression.*

    Update tag frequency data is resource-intensive, so you may want to adjust this value as your deployment grows. In very small deployments 60 minutes is appropriate. In very large deployments, once per day is recommended. Only updating once per day in large deployments should not cause problems, since the 100 to 500 most-used tags do not change very often.

    This property only affects public tags. Tag clouds for individual wikis are updated in real time and are not affected.

    search.seedlist.maximumIncrementalQuerySpanInDays

    Number of days that deletion records are saved before they are eligible to be deleted by the SearchClearDeletionHistory task.

    The value must be greater than or equal to 1.

    Wikis keeps records of deleted files. These records are eligible to be deleted by the SearchClearDeletionHistory task after the number of days specified in this property. The incremental search crawler needs these deletion records to update the search index. If the records are deleted before the incremental crawler reads them, updates will be incomplete. This is not allowed, so Wikis performs a full crawl instead of an incremental crawl. Full crawls delete the existing search index and create a new one, which is more time consuming than incremental crawls.

    To avoid frequent full crawls, make sure that incremental crawls occur sooner than the time it takes for a deletion record to be created and deleted. For example, if deletion records are eligible for deletion after five days, specify that incremental crawls occur every four days.

    search.seedlist.maximumPageSize

    Maximum number of items on search return page. The value must be greater than or equal to 100.

    security.inlineDownload.enabled

    Enables inline display of file attachments. This is useful when you use the Wikis API to download and display active content, such as Adobe Flash (.swf) files, in your own HTML pages.

    By default, the IBM Connections server passes Wikis application file attachments to browsers with the header "Content-Disposition: attachment." This means files display as attachments; when users click the attachment they are prompted to open or download the file. It also prevents embedding files. If you want to embed files in your own HTML page using an <embed> tag, the content disposition must be inline. This affects active content, such as Adobe Flash (.swf), and HTML pages referenced with <iframe>.

    Configure a property in wikis-config.xml to change the content disposition from attachment to inline. Then set the inline parameter to true in your Wikis API download requests. See Displaying file attachments inline.

    Important: Wikis uses the attachment disposition for security reasons. Specifically, uploaded files could potentially contain malicious code that can exploit the cross-site scripting vulnerabilities of some browsers. If you switch to inline disposition, you should configure an alternate domain download for greater security. See Mitigating a cross site scripting attack.

    Accepted values are true and false.

    security.logout.href

    Logout URL for single-sign on solutions that require their own logout page.

    If you are configuring IBM Connections to work with Tivoli Access Manager, specify the following value:

    /wikis/ibm_security_logout?logoutExitPage=<url>

    where <url> is the Tivoli Access Manager junction URL (this is usually the host name of the server).

    For more information, see the topic Enabling single sign-on for Tivoli Access Manager.

    You must use fully-qualified domain names in this configuration file. If you use an abbreviated name, secure communications between servers will fail.

    * For information on how to format the value of an interval attribute, see Scheduling tasks.


    Configure MIME types for Wikis

    You can assign Multipurpose Internet Mail Extensions (MIME) types to file extensions. This applies to files attachments uploaded to wiki pages.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    You can configure Wikis to assign a specific MIME type to files with specific extensions. Wikis with MIME types tell operating systems what applications to open them with, and what applications to display in file open windows. MIME types make it easier for users at a glance to know what type of data a file contains. Also, some applications do not download files that do not have a MIME type that they support.

    This configuration applies to files attached to Wikis pages through the web user interface. The configuration is ignored if a third party application assigns MIME types to extensions using the API. See the topic Wikis API for information about how to assign MIME types through the API.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Navigate to the working directory specified in Step 2b and open the mime-wikis-config.xml file. The contents look like this:

      <mapping mimeType="..." mediaType="..."> 
      		<extension></extension> 
      		<extension></extension> 
      		.... 
      </mapping>

    4. In the mimeType attribute specify a mime type in standard format, for example text/plain. Each value must be unique compared with other mimeType values in other mapping elements, or an error is returned when you start the system. See the Internet Assigned Numbers Authority (IANA) web site for a list of MIME types.

      The mediaType attribute is not supported in this release.

    5. In each extension element specify the extensions that you want to map to the MIME type. Each value must be unique compared with other extension elements in the configuration file, or an error is returned when you start the system.

    6. Apply the changes following steps in the Applying Wikis property changes.


    Example

    <mapping mimeType="text/plain" mediaType=""> 
    	<extension>.txt</extension> 
      .... 
    </mapping>


    Apply Wikis property changes

    After you have edited the Wikis configuration properties, check the changed configuration file in, update the version stamp property, and restart the servers to apply the changes. For information about the properties that you can edit, see Wikis configuration properties. To apply Wikis property changes, complete the following steps:

    1. Check in the changed configuration property keys using the following wsadmin client command:

      WikisConfigService.checkInConfig()

    2. Update the value of the version stamp configuration property in LotusConnections-config.xml to force users' browsers to pick up this change. See Required post-customization step for more details.

    3. To exit the wsadmin client, type exit at the prompt.

    4. Stop and restart the server hosting the Wikis application.

    Run Wikis administrative commands

    Use administrative commands to perform tasks that manipulate Wikis content.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Administrative commands interact with the Wikis application and its resources through scripts. These scripts use the AdminControl object available in the IBM WebSphere Application Server wsadmin tool to interact with the Wikis server.

    If an error occurs when you are executing the commands, you can examine the SystemOut.log file to determine what went wrong.

    To run Wikis administrative commands, complete the following steps:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. See Wikis administrative commands for a complete list of administrative commands for the Wikis application.


    Wikis administrative commands

    Use these commands to perform administrative tasks for Wikis. No file checkout or server restart is needed when using these commands.

    The following sections define administrative commands you can use when working with Wikis. Each section describes the commands for a specific service.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.


    WikisConfigService

    WikisConfigService.checkOutConfig("working_directory", "cell_name")

    Checks Wikis configuration files out to a temporary directory. Run from the wsadmin command processor.

    <working_directory>

    Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them.

    <cell_name>

    Name of the WebSphere® Application Server cell hosting the Lotus® Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:

    print AdminControl.getCell()

    For example:

    • AIX/Linux:

      WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    • Microsoft

      Windows:

      WikisConfigService.checkOutConfig("c:/temp","foo01Cell01")

    WikisConfigService.showConfig()

    Displays the current configuration settings. You must check out the configuration files with WikisConfigService.checkOutConfig() before running WikisConfigService.showConfig().

    WikisConfigService.updateConfig("quick_config_property", "new_value")

    Updates configuration properties.

    quick_config_property

    Property in the wikis-config.xml configuration file expressed as a quick config command. For example the quick config value for following property:

    <security>
    <logout href="/wikis/ibm_security_logout" />
    </security>
    is this:

    security.logout.href

    See Wikis configuration properties for configuration properties and descriptions.

    new_value

    The new value for the property. Property values can be restricted, for example to either true or false. See Wikis configuration properties for configuration properties and descriptions.

    For example, to set the scheduledTasks.MetricsDailyCollection.enabled property to false, use the following command:

    WikisConfigService.updateConfig("scheduledTasks.MetricsDailyCollection.enabled", "false")

    WikisConfigService.checkInConfig()

    Checks in Wikis configuration files. Run from the wsadmin command processor.


    WikisMemberService

    WikisMemberService.getById(string id)

    Returns information about a user specified by a user ID. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    id

    The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisMemberService.getByExtId(string externalId)

    Returns information about a user specified by an external directory ID. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    externalId

    A string value matching the user's external directory ID. This can be any parameter in the user directory that you have configured as the directory ID. The following user information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getByExtId("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisMemberService.getByEmail(string email)

    Returns information about a user specified by an email address. The command only searches the Wikis database, so it only returns users who have logged in at least once.

    Parameters:

    email

    The email address for the user. The following user information is returned:

    • id: The user ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • name: The user's name in the database as of the date in directoryLastUpdate.

    • email: The user's email address.

    • isOrphan: Returns true if the user is in the database, but not the directory.

    • createDate: The date the user was added to the database.

    • lastVisit: The date of the user's last log in.

    • directoryLastUpdate: The last time the user's data was synchronized from the directory.

    • directoryGroupLastUpdate: The last time this user's group membership was synchronized from the directory.

    • communityLastUpdate: The last time this user's Community membership was synchronized.

    For example:

    WikisMemberService.getByEmail("john_doe@company.com")

    WikisMemberService.syncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"] } )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberByExtId("currentExternalId"[, {"newExtId" : "id-string" [, "allowExtIdSwap" : ["true" | "false"] ] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.inactivateMemberByEmail("email")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.inactivateMemberByExtId("externalID")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.getMemberExtIdByEmail("email")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.getMemberExtIdByLogin("login")

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncBatchMemberExtIdsByEmail("emailFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncBatchMemberExtIdsByLogin("loginFile" [, {"allowInactivate" : ["true" | "false"] } ] )

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberExtIdByEmail("email" [, { "allowInactivate" : ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.

    WikisMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate": ["true" | "false"] } ])

    See Synchronizing user data using administrative commands for details.


    WikisLibraryService

    WikisLibraryService.getById(string libraryId)

    Returns information about a single library specified by an ID. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    libraryId

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

    • type: The type of library. The only valid value is wiki.

    • label: A string of characters used to identify the library in a URL.

    • title: The library's title.

    • summary: A summary of library information.

    • size: The total size of the library binary data.

    • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

    • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

    • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • lastUpdate: The last time a significant user-driven update occurred to the metadata.

    • createDate: The library's creation date.

    • externalInstanceId: The widget ID if the library is owned by a community.

    • externalContainerId: The community ID if the library is owned by a community.

    • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

    • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

    For example:

    WikisLibraryService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisLibraryService.delete(string libraryId)

    Deletes the library specified by the library ID, including all associated content.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    libraryID

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisLibraryService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")

    WikisLibraryService.deleteBatch(string filePath)

    Deletes libraries specified in a text file. The file must contain a list with a single library ID per line in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must create the file and save it in a directory local to the server

    ...where you are running the wsadmin processor.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    filePath

    The full path to the text file, as a string.

    For example:

    WikisLibraryService.deleteBatch("C:/connections/delete_libraries.txt")

    WikisLibraryService.assignPolicy(string libraryId, string policyId)

    Assigns a policy to a library. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments. A policy sets a maximum size for a wiki.

    No message is printed if the task succeeds.

    Parameters:

    libraryId

    The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    policyId

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisLibraryService.assignPolicy("f0d01111-9b21-4dd8-b8be-8825631cb84b", "2d93497d-065a-4022ae25-a4b52598d11a")

    WikisLibraryService.assignPolicyBatch(string filePath)

    Assigns policies to libraries as specified in a text file. The file must contain a list of library-policy ID pairs, one pair per line, values separated by a comma. For example: libraryId, policyId. Extra whitespace is ignored. You must create this text file and save it in a directory local to the server where you are running the wsadmin processor.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    filePath

    The full path to the text file, as a string.

    For example:

    WikisLibraryService.assignPolicyBatch("C:/connections/assign_policies.txt")

    WikisLibraryService.browseWiki(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

    Returns a list of all wikis, with information about each wiki. The list includes wikis owned by communities, and wikis whose owners were removed from the user directory.

    Parameters:

    sortOption

    A string value that specifies how to sort the list. The default value is title, but you can use lastUpdate, size, createDate, or quotaPercentage.

    sortAscending

    A string value that specifies whether to sort the list in ascending alphabetical order. This depends on the sortOption value. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

    pageNumber

    The number of the page to display. For example, if you specify in the itemsPerPage parameter that each page will have 50 items, page 1 will contain items 1-50.

    itemsPerPage

    The maximum number of wikis to list per page. The default value is 20. The following information is returned:

    • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

    • type: The type of library. The only valid value is wiki.

    • label: A string of characters used to identify the library in a URL.

    • title: The library's title.

    • summary: A summary of library information.

    • size: The total size of the library binary data.

    • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

    • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

    • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    • lastUpdate: The last time a significant user-driven update occurred to the metadata.

    • createDate: The library's creation date.

    • externalInstanceId: The widget ID if the library is owned by a community.

    • externalContainerId: The community ID if the library is owned by a community.

    • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

    • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

    For example:

    WikisLibraryService.browseWiki("title", "true", 1, 25)

    WikisLibraryService.getWikiCount()

    Returns the total number of wikis.

    WikisLibraryService.exportSyncedResourceInfo (string fullpathForOutput, string type)

    Returns a report of all of the communities that the Wikis application has interacted with. After a system crash you can compare the report to the latest metadata in the Communities database to help synchronize and update any missing data. See the topic Comparing remote application data with the Communities database for more information.

    Note that in clusters, when you run the command from the deployment manager the path and file are created on the server running Wikis. In clusters

    ...where multiple nodes are running Wikis, you are asked choose a server to connect to and run the command on, and then the path and file are created on that server.

    Parameters:

    fullPathforOutput

    The full path location where you want the report, and the report filename, as a string in quotes. The report is an XML file. Use forward slashes ("/") in the path, even on Microsoft Windows computers.

    type

    This is always the string value, "community" (including quotes). An error is returned if this is anything except "community".

    For example:

    WikisLibraryService.exportSyncedResourceInfo("c:/connections/sync/community_output.xml", "community")


    WikisDataIntegrityService

    WikisDataIntegrityService.checkFiles(string extraFileDirectory)

    Checks the integrity of the binary files in the file system extra files directory against the metadata in the database, and prints results to log files in a specified directory. The database is used as the primary source, as during a back up the file system is assumed to have extra data, if there is any.

    The task logs a message for every extra file found, or every missing file. Missing files are errors that must be resolved (by finding the files or restoring a backup) before the application can start in a consistent state.

    This information might be useful before restoring database and file system images, to see how closely they match in a test environment. For more information see the topic Checking Wikis data integrity.

    Parameters:

    extraFileDirectory

    A directory path as a string. This is the location where you want to store files not found in the database. If the directory does not exist, the command creates it. If the directory cannot be created, or read or written to, an error is returned.

    For example:

    WikisDataIntegrityService.checkFiles("C:/wikis_integrity")


    WikisPrintService

    WikisPrintService.saveToFile(string object, string filePath, string append)

    Prints information returned by other commands to a file.

    Parameters:

    object

    A command with parameters that returns a Map or List<Map> java object. You can use any of the following commands:

    • WikisMemberService.getById (returns a Map)

    • WikisMemberService.getByExtId (returns a Map)

    • WikisMemberService.getByEmail (returns a Map)

    • WikisLibraryService.getById (returns a Map)

    • WikisLibraryService.browseWiki (returns a List<Map>)

    • WikisPolicyService.getById (returns a Map)

    • WikisPolicyService.browse (returns a List<Map>>)

    • WikisMetricsService.browse (returns a List<Map>)

    filePath

    A path to a file in which to save the object data. The data is saved in comma-separated value (.csv) format.

    append

    string whose default value is "true". Change to "false" to have the command overwrite the existing file instead of appending the data in the existing file.

    Example:

    WikisPrintService.saveToFile(WikisLibraryService.browseWiki("title","true", 1, 20), "/opt/wsadmin/LibraryMap.txt")


    WikisScheduler

    WikisScheduler.pauseSchedulingTask(string taskName)

    Suspends scheduling of a task. Has no effect on currently running tasks. Returns a 1 to indicate that the task has been paused. Paused tasks remain paused until you explicitly resume them, even if the server is stopped and restarted.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.pauseSchedulingTask("DirectoryGroupSynch")

    WikisScheduler.resumeSchedulingTask(string taskName)

    Resumes the start of a paused task. Returns a 1 to indicate that the task has been resumed.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.resumeSchedulingTask("DirectoryGroupSynch")

    WikisScheduler.forceTaskExecution(string taskName, string executeSynchronously)

    Executes a task. Returns a 1 to indicate that the task has been executed.

    Property settings in the wikis-config.xml configuration properties file specify whether tasks are enabled to run automatically, and how often. This command allows you to run tasks manually, for example if you disabled a task but want to run it occasionally.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    executeSynchronously

    Takes the string values true or false. Specifying this value is not required; the default is false. If this value is false, then the task executes asynchronously, meaning if the taskId is valid the command returns immediately and the execution continues in the background. If this value is true, it the command does not return until the task completes.

    For example:

    WikisScheduler.forceTaskExecution("DirectoryGroupSynch")

    WikisScheduler.getTaskDetails(string taskName)

    Displays status of a task. Returns detailed status message.

    Parameters:

    taskName

    Any one of these task names, as a string value:

    • DirectoryGroupSynch

    • FileActuallyDelete

    • SearchClearDeletionHistory

    • MetricsDailyCollection

    • TagUpdateFrequency

    For example:

    WikisScheduler.getTaskDetails("DirectoryGroupSynch")


    WikisPolicyService

    WikisPolicyService.add(string title, long maximumSize)

    Creates a policy with a specified title and maximum size. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    When a policy is created, an ID is created for it and returned to you. The ID is in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must provide policy IDs as parameters when running other WikisPolicyService commands.

    Policies can be applied to libraries using the WikisLibraryService.assignPolicy or WikisLibraryService.assignPolicyBatch commands.

    Parameters:

    title

    The policy title. A required value.

    maximumSize

    The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.add("My Policy", 2147483648L)

    WikisPolicyService.edit(string policyId, string title, long maximumSize)

    Edits the title and maximum size of a policy with a specified ID. If the ID is for a default policy, the title is not modified. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    policyID

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    title

    The policy title. A required value.

    maximumSize

    The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.edit("2d93497d-065a-4022ae25-a4b52598d11a", "My Policy", 2147483648L)

    WikisPolicyService.getById(string id)

    Returns information for a single policy specified by an ID. Policies set a maximum size limit on libraries.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    id

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

    • id: the ID

    • title: the policy title

    • maximumSize: the maximum size (in bytes) the library can be, or 0 for unlimited

    For example:

    WikisPolicyService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

    WikisPolicyService.browse(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

    Returns a list of policies with ID, title, and maximum size information, as described for the WikisPolicyService.getById(id) command. Policies set a maximum size limit on libraries.

    A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    Parameters:

    sortOption

    A string value that specifies how to sort the list. The default value is title, but you can also use maximumSize.

    sortAscending

    A string value that specifies whether the list sorts in ascending alphabetical order. This depends on sortOption. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

    pageNumber

    The number of the page to return. For example, if the itemsPerPage value is 40, and pageNumber value is 2, the command returns items 41 to 80 (page 2) instead of 1 to 40 (page 1).

    itemsPerPage

    The maximum number of policies to list per page. The default value is 20.

    For example:

    WikisPolicyService.browse("title", "true", 1, 25)

    WikisPolicyService.getCount()

    Returns the number of policies. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

    WikisPolicyService.editDefault(long maximumSize)

    Sets the maximum size, in bytes, for the personal wiki library default policy. Personal wikis are owned by a person.

    Parameters:

    maximumSize

    A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.editDefault(2147483648L)

    WikisPolicyService.editCommunityDefault(long maximumSize)

    Sets the maximum size, in bytes, for the community wiki library default policy. Community wikis are owned by a community.

    Parameters:

    maximumSize

    A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

    Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

    For example:

    WikisPolicyService.editCommunityDefault(2147483648L)

    WikisPolicyService.delete(string id)

    Deletes the policy specified by the ID. You cannot delete default policies or policies in use by any libraries.

    id

    The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisPolicyService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")


    WikisMetricsService

    WikisMetricsService.browse(string startDate, string endDate, string filePathWithFilterKeys)

    Returns metrics about wikis stored in the database. The same metrics are provided for each day in a specified period.

    If you do not specify dates, then the command uses the first available day with data for startDate, and the last available day with data for endDate.

    See the topic Wikis metrics for metrics and their descriptions.

    Parameters:

    startDate

    The start date for the period, in YYYY-MM-DD format. This date is included in the returns, for example a start date of "2009-01-01" will include metrics from January 1, 2009. It must be in quotes, for example "2009-01-01".

    endDate

    The end date for the period, in YYYY-MM-DD format. This date is included in the returns, for example an end date of "2009-01-10" will include metrics from January 10, 2009. It must be in quotes, for example "2009-01-10".

    filePathWithFilterKeys

    Optional: The full path to a text file in which each line contains a statistical key. If you specify a file, only metrics listed in the file are returned. If you do not specify a file, all data is returned.

    For example:

    WikisMetricsService.browse("2009-01-01", "2009-01-10", "C:/connections/wikis/metrics.txt")

    WikisMetricsService.saveToFile(string filePath, string startDate, string endDate, string filePathWithFilterKeys, string append)

    Returns metrics about wikis and exports them to a local file. The same metrics are provided for each day in a specified period.

    If you do not specify dates, then the command uses the first available day with data for startDate, and the last available day with data for endDate.

    See the topic Wikis metrics for metrics and their descriptions.

    Parameters:

    filePath

    Path to a file in which to export the metrics. Metrics are exported in comma separated value (CSV) format. If you specify a file name with a .csv extension, it is possible to open it as a spreadsheet. See Importing statistics and metrics into a spreadsheet.

    startDate

    The start date for the period, in YYYY-MM-DD format. This date is included in the returns, for example a start date of "2009-01-01" will include metrics from January 1, 2009. It must be in quotes, for example "2009-01-01".

    endDate

    The end date for the period, in YYYY-MM-DD format. This date is included in the returns, for example an end date of "2009-01-10" will include metrics from January 10, 2009. It must be in quotes, for example "2009-01-10".

    filePathWithFilterKeys

    Optional: The full path to a text file in which each line contains a metric key. If you specify a file, only metrics listed in the file are returned. If you do not specify a file, all data is returned. For example, if the file lists these three keys, then only these metrics are returned:

    wikis.metric.user.count
    wikis.metric.user.created.today.count
    wikis.metric.user.login.count

    append

    String whose default value is "true". Change to "false" to have the command overwrite the existing file instead of appending the data in the existing file.

    For example:

    WikisMetricsService.saveToFile("C:/connections/wikis/metrics.csv", "2009-01-01", "2009-01-10", "C:/connections/wikis/metric_keys.txt", "false")

    WikisMetricsService.getAvailableRange()

    Returns a string array

    ...where the first element is the first day data is available and the second element is the last day that data is available for wiki libraries. Typically, the current day's data is not available until 12:01 A.M. the following day.

    If metrics collection was disabled or did not occur because of some issue, there may be gaps in data available.


    WikisUtilService

    WikisUtilService.filterListByString(List listOfMaps, string filterKey, string regexstringCriteria)

    Returns maps from a specified list that have a specified key matching a specified regular expression. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    regexstringCriteria

    A regular expression represented as a string to match against the filterKey value. For example, "[0-9]+" to match only >= 1 numbers in a row.

    The command returns maps from the listOfMaps whose filterKey is the regexstringCriteria value. For example, this command shows only the returned maps whose title values match the expression "Development*":

    WikisUtilService.filterListByString(WikisLibraryService.browseWiki("title", "true", 1, 25), "title", "Development*")

    WikisUtilService.filterListByDate(List listOfMaps, string filterKey, expression)

    Returns maps from a specified list that have a specified key with a specified date. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    expression

    A string of the form <operator> <date> where <date> is in yyyy-MM-dd format and <operator> is one of the following: > >= == <= <

    The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose creation date is on or later than January 1, 2010:

    WikisUtilService.filterListByDate(WikisLibraryService.browseWiki("title", "true", 1, 25), "createDate", ">=2010-01-01")

    WikisUtilService.filterListByNumber(List listOfMaps, string filterKey, expression)

    Returns maps from a specified list that have a specified key with a specified number. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

    A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

    Parameters:

    listOfMaps

    A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

    filterKey

    A key in each map in the list, whose value is compared against the filter criteria.

    expression

    A string of the form <operator> <int> where <int> is an integer and <operator> is one of the following: > >= == <= <

    The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose percentUsed value (which reflects the percent of the library's available space that is currently used) is 20:

    WikisUtilService.filterListByNumber(WikisLibraryService.browseWiki("title", "true", 1, 25), "percentUsed", "==20")

    WikisUtilService.getFileById(string fileID)

    Returns the file path location of the wiki page file attachment identified by a provided file ID. Returns a path even if the file is not in use.

    Use this command to find the location of any file attachment stored in the shared file directory. This can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

    fileID

    The ID of a file in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

    For example:

    WikisUtilService.getFileById("2d93497d-065a-4022ae25-a4b52598d11a")

    Back up Wikis data

    Wikis stores data in both the database and a file system. This adds some complication when backing up data while keeping the application available to users.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Wikis stores a large amount of data. If it were only stored in a database, maintenance and backups would be complex and costly. To prevent this, Wikis only stores file meta-data in the database, and stores binary files in a data directory on a file system. You specify this directory during IBM Connections installation, and you can find it at any time in the wikis-config.xml properties file in the file.storage.rootDirectory element.

    The file.storage.rootDirectory element will contain either the path itself, or a WebSphere Application Server variable whose value is the path. If it contains a variable, you can find the path by opening the WebSphere Application Server console, clicking Environment > WebSphere Variables, and finding the variable. For example, if the element's value is ${WIKIS_CONTENT_DIR}, find WIKIS_CONTENT_DIR in the console to find the path. See the topic Changing configuration property values for information on opening the wikis-config.xml file.

    File data is actually stored in unique directories below a storage_root_directory/files/files directory. Each file's data is stored in a sub-directory below /files, generated from the file's randomly generated UUID. Part of the UUID is used to create a directory with a number between 0 and 127. Another part is used to create a directory below that, with another number between 0 and 127, and the UUID itself is located in that directory. For example:

    storage_root_directory/files/18/113/<file_UUID>

    Files are only written once, so their identities are clear if one is missing during a restore.

    This storage architecture means you must maintain consistency between the database and file system during backups. The simplest way to maintain consistency is to perform "off-line" backups, making the application inaccessible and then backing up both locations. But often you will want to perform "on-line" backups, keeping the application accessible. During an on-line backup, users can continue to add and delete content from the application.

    During on-line backups of Wikis, you must back up the database before the file system. The database enforces transactional integrity between the two locations. If you back up the file system first, files added between the time the file system backup starts and the database backup later completes will be missing from the file system on restoration. Back up the database first ensures that you capture all new files during backup.

    You must also stop a file-deletion task from running during on-line backup. When a user deletes a file it is removed from the user interface, but the application actually adds it to a queue of files that must be deleted from the file system. This task runs regularly to delete the first item from the queue. You can also increase the time files can sit in the queue before they are deleted, by adjusting the value in the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property in wikis-config.xml. This could give you enough time to run incremental backups and make sure your archive is never missing data. For information on editing wikis-config.xml, see the topic Changing configuration property values. For information on the scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins property see the topic Wikis configuration properties.

    To perform an on-line backup of Wikis complete the following steps:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Stop the task that deletes files from the queue with the following command:

      WikisScheduler.pauseSchedulingTask("FileActuallyDelete")

    4. Back up the database according to the database documentation.

    5. Back up the file system in whatever way makes sense in your environment. For example, for small deployments you can just zip the system, or for large deployments you can use a tool like Tivoli Storage Manager.

    6. Start the task that deletes files from the queue with the following command:

      WikisScheduler.resumeSchedulingTask("FileActuallyDelete")


    What to do next

    You can run a task that checks for inconsistencies between the database and the file system. It might be useful to compare database and file system images in a test environment before restoring them. See the topic Check Wikis data integrity for more information.


    Check Wikis data integrity

    The appropriate way to restore backed-up Wikis data is to restore versions of file system data and database data that match. You can check integrity between database data (metadata) and file system data (binary) by running the WikisDataIntegrityService.checkFiles command.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    The WikiDataIntegrityService.checkFiles command moves files found on the file system, but not in the database, to a file path location you specify in the command. You might want to delete these extra files, or back them up if you think you might need them for a future Files backup. Users cannot download files if they are missing from the database.

    Before running the WikisDataIntegrityService.checkFiles command, create the target path_to_extra_filesDirectory folder. This folder will be used to save unused files during the integrity check. Create the folder on the device from which you will run the command.

    If you are running the command on Linux or AIX, ensure that you have correct write permissions enabled for the folder.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Check the integrity of data in the database and file system directory with the following command: On

      Windows:

      WikisDataIntegrityService.checkFiles("C:\path_to_extra_wikisDirectory")
      On Linux or AIX:

      WikisDataIntegrityService.checkFiles("/opt/path_to_extra_wikisDirectory")


    Synchronize Wikis data with Communities data

    Use the WikisLibraryService.exportSyncedResourceInfo command to return a report of all of the communities that Wikis has interacted with. The information in this report can help you to synchronize Wikis data with the Communities database after a system crash that includes data loss.

    See the Communities topic Recovering from a database failure for information.

    Restrict attachment file types in Wikis

    Restrict the types of files that users can upload as attachments in wiki pages.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    You can create a list of denied file extensions and prevent users from uploading files with those extensions. Or you can create a list of allowed file extensions and only allow users to upload files with those extensions.

    Restrict file types affects users uploading new files, or changing the extensions of existing files. (Users cannot change existing files to a denied type.) But existing documents with denied extensions are not affected. For example, if you deny the .xls extension, users cannot upload .xls files or change existing files to have the .xls extension. But existing .xls files are not affected, and users can still upload new versions of them.

    This is not intended as a security application. Files are not analyzed to determine their type, only the file name is read to allow or deny (with an error) the upload. This is only to help you restrict the types of files you store in your environment.

    Perform the following steps to restrict file types in Wikis:

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Open wikis-config.xml.

    4. In the <restrictions> element in the <file> section, specify the enabled attribute as true.

    5. In the <restrictions> element in the <file> section, specify the mode attribute as one of the following values:

      • A value of allow means the extensions in the list are the only ones allowed to be uploaded.

      • A value of deny means the extensions in the list are the only ones not allowed to be uploaded.

    6. In the <restrictions> element, add an <extensions> element, and within the <extensions> element add one or more <extension> elements, each containing a file extension to allow or deny.

    7. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.


    Example

    <file>
     ....
     <restrictions enabled="true" mode="allow">
      <extensions>
    	 <extension>odt</extension>
    	 <extension>odp</extension>
    	 <extension>ods</extension>
      </extensions>
     </restrictions>
    </file>

    In the previous example, .odt, .odp, and .ods IBM Lotus Symphony extensions are the only extensions users can upload. Case is ignored, and you can use values with or without periods. For example, odt, .odt, and ODT are all valid.

    Use an empty <extension> element to allow or deny files without extensions, or with extensions that exceed the platform limit of 16 characters.

    Set maximum sizes on media, pages, and attachments

    You can set maximum sizes for media, pages, and attachments in the wikis-config.xml properties file.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    You may want to set maximum sizes on media, pages, and attachments to control the size of these individual objects within the larger library size setting. See the topic Set maximum sizes on libraries for more information.

    In Wikis, pages are a type of media, so the maximum setting for pages cannot be larger than the maximum setting for media. Attachments have no relationship to media or pages, and can be any maximum size, however if you let people attach very large files you must make sure that network and browser timeout settings allow users to download those large files.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view the current configuration settings use the following command:

      WikisConfigService.showConfig()

    4. To set a maximum size (in kilobytes) for media, pages, and attachments, use the following commands:

      WikisConfigService.updateConfig("file.media.maximumSizeInKb", "<number_of_kilobytes>")

      WikisConfigService.updateConfig("file.page.maximumSizeInKb", "<number_of_kilobytes>")

      WikisConfigService.updateConfig("file.attachment.maximumSizeInKb", "<number_of_kilobytes>")

      IBM recommends that the attachment maximum size be below 2GB. Files larger than that are likely to reach browser or server limitations.

    5. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.

    Set maximum sizes on libraries

    Use WikisLibraryService commands to set maximum sizes on libraries by assigning them a policy. A library is the pages, attachments, and other data that make up a wiki. A policy sets a maximum size for a library.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Create a policy to specify the library size, using steps in the topic Working with policies.

    4. Run the following commands to set maximum sizes on libraries:

      WikisLibraryService.assignPolicy(string libraryId, string policyId)

      Assigns a policy to a library. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments. A policy sets a maximum size for a wiki.

      No message is printed if the task succeeds.

      Parameters:

      libraryId

      The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      policyId

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisLibraryService.assignPolicy("f0d01111-9b21-4dd8-b8be-8825631cb84b", "2d93497d-065a-4022ae25-a4b52598d11a")

      WikisLibraryService.assignPolicyBatch(string filePath)

      Assigns policies to libraries as specified in a text file. The file must contain a list of library-policy ID pairs, one pair per line, values separated by a comma. For example: libraryId, policyId. Extra whitespace is ignored. You must create this text file and save it in a directory local to the server where you are running the wsadmin processor.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      filePath

      The full path to the text file, as a string.

      For example:

      WikisLibraryService.assignPolicyBatch("C:/connections/assign_policies.txt")

    Work with Wikis policies

    Use the WikisPolicyService commands to add, edit, count, and return information about policies. You apply policies to libraries to set a maximum size on those libraries. A library is a set of files owned by a person or community.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to work with policies:

      WikisPolicyService.add(string title, long maximumSize)

      Creates a policy with a specified title and maximum size. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      When a policy is created, an ID is created for it and returned to you. The ID is in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must provide policy IDs as parameters when running other WikisPolicyService commands.

      Policies can be applied to libraries using the WikisLibraryService.assignPolicy or WikisLibraryService.assignPolicyBatch commands.

      Parameters:

      title

      The policy title. A required value.

      maximumSize

      The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.add("My Policy", 2147483648L)

      WikisPolicyService.edit(string policyId, string title, long maximumSize)

      Edits the title and maximum size of a policy with a specified ID. If the ID is for a default policy, the title is not modified. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      policyID

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      title

      The policy title. A required value.

      maximumSize

      The maximum size allowed, in bytes. Must be zero or greater. A value of zero means the size is unlimited.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.edit("2d93497d-065a-4022ae25-a4b52598d11a", "My Policy", 2147483648L)

      WikisPolicyService.getById(string id)

      Returns information for a single policy specified by an ID. Policies set a maximum size limit on libraries.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      id

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

      • id: the ID

      • title: the policy title

      • maximumSize: the maximum size (in bytes) the library can be, or 0 for unlimited

      For example:

      WikisPolicyService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

      WikisPolicyService.browse(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

      Returns a list of policies with ID, title, and maximum size information, as described for the WikisPolicyService.getById(id) command. Policies set a maximum size limit on libraries.

      A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      sortOption

      A string value that specifies how to sort the list. The default value is title, but you can also use maximumSize.

      sortAscending

      A string value that specifies whether the list sorts in ascending alphabetical order. This depends on sortOption. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

      pageNumber

      The number of the page to return. For example, if the itemsPerPage value is 40, and pageNumber value is 2, the command returns items 41 to 80 (page 2) instead of 1 to 40 (page 1).

      itemsPerPage

      The maximum number of policies to list per page. The default value is 20.

      For example:

      WikisPolicyService.browse("title", "true", 1, 25)

      WikisPolicyService.getCount()

      Returns the number of policies. Policies set a maximum size limit on libraries. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      WikisPolicyService.editDefault(long maximumSize)

      Sets the maximum size, in bytes, for the personal wiki library default policy. Personal wikis are owned by a person.

      Parameters:

      maximumSize

      A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.editDefault(2147483648L)

      WikisPolicyService.editCommunityDefault(long maximumSize)

      Sets the maximum size, in bytes, for the community wiki library default policy. Community wikis are owned by a community.

      Parameters:

      maximumSize

      A number representing the maximum size allowed, in bytes, for wikis that the default policy is assigned to.

      Numbers 2GB or greater are long literals, and add an "L" to the end of the number, for example a policy of 2GB must be 2147483648L.

      For example:

      WikisPolicyService.editCommunityDefault(2147483648L)

      WikisPolicyService.delete(string id)

      Deletes the policy specified by the ID. You cannot delete default policies or policies in use by any libraries.

      id

      The policy ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisPolicyService.delete("f0d01111-9b21-4dd8-b8be-8825631cb84b")

    See Wikis library information

    Use the WikisLibraryService commands to see information on Wikis libraries. A library is the pages, attachments, and other data that make up a wiki.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to return information about libraries:

      WikisLibraryService.getById(string libraryId)

      Returns information about a single library specified by an ID. A library is the pages, attachments, and other data that make up a wiki. It includes all wiki page versions, but does not include metadata such as comments.

      Parameters:

      libraryId

      The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. The following information is returned:

      • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

      • type: The type of library. The only valid value is wiki.

      • label: A string of characters used to identify the library in a URL.

      • title: The library's title.

      • summary: A summary of library information.

      • size: The total size of the library binary data.

      • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

      • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

      • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • lastUpdate: The last time a significant user-driven update occurred to the metadata.

      • createDate: The library's creation date.

      • externalInstanceId: The widget ID if the library is owned by a community.

      • externalContainerId: The community ID if the library is owned by a community.

      • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

      • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

      For example:

      WikisLibraryService.getById("2d93497d-065a-4022ae25-a4b52598d11a")

      WikisLibraryService.browseWiki(string sortOption, string sortAscending, int pageNumber, int itemsPerPage)

      Returns a list of all wikis, with information about each wiki. The list includes wikis owned by communities, and wikis whose owners were removed from the user directory.

      Parameters:

      sortOption

      A string value that specifies how to sort the list. The default value is title, but you can use lastUpdate, size, createDate, or quotaPercentage.

      sortAscending

      A string value that specifies whether to sort the list in ascending alphabetical order. This depends on the sortOption value. If sortOption is title, then this value is true; if sortOption any other value, then this value is false.

      pageNumber

      The number of the page to display. For example, if you specify in the itemsPerPage parameter that each page will have 50 items, page 1 will contain items 1-50.

      itemsPerPage

      The maximum number of wikis to list per page. The default value is 20. The following information is returned:

      • id: The library ID in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • ownerUserId: The user ID of the library owner in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000..

      • type: The type of library. The only valid value is wiki.

      • label: A string of characters used to identify the library in a URL.

      • title: The library's title.

      • summary: A summary of library information.

      • size: The total size of the library binary data.

      • percentUsed: The percentage of the maximum allowable size used, according to the library's policy. Zero if not applicable.

      • maximumSize: The maximum size (in bytes) the library's policy allows. Zero for unlimited.

      • policyId: The ID of the policy that sets a maximum limit (in bytes) on the library's size, in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • lastUpdate: The last time a significant user-driven update occurred to the metadata.

      • createDate: The library's creation date.

      • externalInstanceId: The widget ID if the library is owned by a community.

      • externalContainerId: The community ID if the library is owned by a community.

      • themeName: The theme the community owner has selected in communities. Returned for community libraries only.

      • orphan: The value is true if the library owner is no longer active. Returned for personal libraries only.

      For example:

      WikisLibraryService.browseWiki("title", "true", 1, 25)

      WikisLibraryService.getWikiCount()

      Returns the total number of wikis.

      WikisLibraryService.exportSyncedResourceInfo (string fullpathForOutput, string type)

      Returns a report of all of the communities that the Wikis application has interacted with. After a system crash you can compare the report to the latest metadata in the Communities database to help synchronize and update any missing data. See the topic Comparing remote application data with the Communities database for more information.

      Note that in clusters, when you run the command from the deployment manager the path and file are created on the server running Wikis. In clusters

      ...where multiple nodes are running Wikis, you are asked choose a server to connect to and run the command on, and then the path and file are created on that server.

      Parameters:

      fullPathforOutput

      The full path location where you want the report, and the report filename, as a string in quotes. The report is an XML file. Use forward slashes ("/") in the path, even on Microsoft Windows computers.

      type

      This is always the string value, "community" (including quotes). An error is returned if this is anything except "community".

      For example:

      WikisLibraryService.exportSyncedResourceInfo("c:/connections/sync/community_output.xml", "community")

    Filter library lists

    Use the WikisUtilService commands to filter lists of library maps returned by the WikisLibraryService.browseWiki command. You can filter a list of library maps by a certain string value, a certain date value, or a certain number value.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    Browse commands, such as WikisLibraryService.browseWiki, return List<Map> java objects. A List<Map> object is a list of Map java objects. Maps are lists of key/value pairs. For example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values are information about the library, such as its title and creation date.

    You filter a list by specifying that it should only return maps that have a specified key with a specified string value, date value, or number value.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following commands to filter a list of library maps:

      WikisUtilService.filterListByString(List listOfMaps, string filterKey, string regexstringCriteria)

      Returns maps from a specified list that have a specified key matching a specified regular expression. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library in the list is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      regexstringCriteria

      A regular expression represented as a string to match against the filterKey value. For example, "[0-9]+" to match only >= 1 numbers in a row.

      The command returns maps from the listOfMaps whose filterKey is the regexstringCriteria value. For example, this command shows only the returned maps whose title values match the expression "Development*":

      WikisUtilService.filterListByString(WikisLibraryService.browseWiki("title", "true", 1, 25), "title", "Development*")

      WikisUtilService.filterListByDate(List listOfMaps, string filterKey, expression)

      Returns maps from a specified list that have a specified key with a specified date. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      expression

      A string of the form <operator> <date> where <date> is in yyyy-MM-dd format and <operator> is one of the following: > >= == <= <

      The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose creation date is on or later than January 1, 2010:

      WikisUtilService.filterListByDate(WikisLibraryService.browseWiki("title", "true", 1, 25), "createDate", ">=2010-01-01")

      WikisUtilService.filterListByNumber(List listOfMaps, string filterKey, expression)

      Returns maps from a specified list that have a specified key with a specified number. Use this command to filter List<Map> java objects that are returned by any of the browse commands, such as WikisLibraryService.browseWiki.

      A map is a list of key/value pairs, for example the WikisLibraryService.browseWiki command returns a list of libraries. Each library is a map with a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values contain information about the library, such as its title and creation date.

      Parameters:

      listOfMaps

      A list of maps, for example the result of WikisLibraryService.browseWiki(parameters).

      filterKey

      A key in each map in the list, whose value is compared against the filter criteria.

      expression

      A string of the form <operator> <int> where <int> is an integer and <operator> is one of the following: > >= == <= <

      The command returns maps from the listOfMaps value whose filterKey value is the expression value. For example, this command shows only the returned maps whose percentUsed value (which reflects the percent of the library's available space that is currently used) is 20:

      WikisUtilService.filterListByNumber(WikisLibraryService.browseWiki("title", "true", 1, 25), "percentUsed", "==20")

      WikisUtilService.getFileById(string fileID)

      Returns the file path location of the wiki page file attachment identified by a provided file ID. Returns a path even if the file is not in use.

      Use this command to find the location of any file attachment stored in the shared file directory. This can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

      fileID

      The ID of a file in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      For example:

      WikisUtilService.getFileById("2d93497d-065a-4022ae25-a4b52598d11a")

    Print library information

    Use the WikisPrintService.saveToFile command to print information returned by other commands.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    This command prints Map or List<Map> java objects returned by any of the following commands:

    • WikisMemberService.getById (returns a Map)

    • WikisMemberService.getByExtId (returns a Map)

    • WikisMemberService.getByEmail (returns a Map)

    • WikisLibraryService.getById (returns a Map)

    • WikisLibraryService.browseWiki (returns a List<Map>)

    • WikisPolicyService.getById (returns a Map)

    • WikisPolicyService.browse (returns a List<Map>)

    • WikisMetricService.browse (returns a List<Map>)

    A List<Map> object is a list of Map java objects. Maps are lists of key/value pairs. For example the WikisLibraryService.browseWiki command returns a list of library maps. (A library is the pages, attachments, and other data that make up a wiki.) Each map in the list has a set of keys, and each key is paired with a value. Every library has the same set of keys, but unique values. Values are information about the library, such as its title and creation date.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run one the following command to print library information returned by other commands:

      WikisPrintService.saveToFile(Object object, String filePath, String append)

      where object is a Map or List<Map> type of java object. You provide the command that returns the object, for example, WikisLibraryService.browseWiki(parameters), which returns a List<Map> object.

      The filePath parameter is the location where you want the data printed in a comma-separated value (.csv) file.

      The append parameter determines whether to append the returned information to information in an existing file. If true (the default), returned information is appended, if false the file is overwritten.

      For example:

      WikisPrintService.saveToFile(WikisLibraryService.browseWiki("title","true",1,20), "/opt/wsadmin/LibraryMap.csv")

      In this example the command runs WikisLibraryService.browseWiki with the given parameters, then prints the output to the LibraryMap.csv file. Because the append parameter is left at the default value of true, running the same command again will append the new data in the existing LibraryMap.csv. Here is an example of returned data printed to a file:

      "id","createDate","label","lastUpdate","maximumSize","orphan","ownerUserId",
      "percentUsed","policyId","size","summary","title","type","externalInstanceId","externalContainerId"
      "ef8ed3e2-22c0-4f20-aa53-bdc6b262abbd","2009-06-25 12:30:32.797","5adff8c0-7d67-102c-8452-e2ebc3ec5536","2009-06-25 12:30:32.797","524288000","false","9ddb97f0-cea5-49fd-9158-06e45b01cd46","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones1","personal","",""
      "30676b64-c792-46d1-9c21-bcea1f3350cf","2009-06-25 16:23:23.354","5b788f40-7d67-102c-8464-e2ebc3ec5536","2009-06-25 16:23:23.354","524288000","false","1c00bd59-20c1-48ea-857b-9c998670d715","8.170700073242188E-5","00000000-0000-0000-0000-000000000000","42838","","Amy Jones10","personal","",""
      "547b8f88-0cb9-4f84-95c2-382f235fe251","2009-06-26 10:57:57.384","5b788f40-7d67-102c-8468-e2ebc3ec5536","2009-06-26 10:57:57.384","524288000","false","a25fd14a-70d2-4978-b814-9e05f9b56503","3.90625E-5","00000000-0000-0000-0000-000000000000","20480","","Amy Jones12","personal","",""
      "605ff4d6-956a-446f-a393-4995057213c5","2009-06-26 16:15:58.778","5ca9bc40-7d67-102c-847c-e2ebc3ec5536","2009-06-26 16:15:58.778","524288000","false","5a79bd44-e5d1-4b4d-b51f-338eff519636","3.1642913818359376E-6","00000000-0000-0000-0000-000000000000","1659","","Amy Jones23","personal","",""
      "86aa4152-c661-4aae-ac7c-ca04da570715","2009-06-25 17:29:16.162","5ddae940-7d67-102c-849e-e2ebc3ec5536","2009-06-25 17:29:16.162","524288000","false","82252a4e-1355-4518-930c-983d7085ad6e","2.63214111328125E-7","00000000-0000-0000-0000-000000000000","138","","Amy Jones40","personal","",""
      "fb9f97fe-0c41-4276-96f0-f1c91478df68","2009-06-25 11:52:22.843","5e737fc0-7d67-102c-84b2-e2ebc3ec5536","2009-06-25 11:52:22.843","524288000","false","8daf28ad-f51e-4ef3-8990-283c9fd4574a","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones50","personal","",""
      "179be703-7e44-45f5-9fa8-eeab1f46e896","2009-06-25 18:17:38.639","5f0c1640-7d67-102c-84c6-e2ebc3ec5536","2009-06-25 18:17:38.639","524288000","false","3a99634c-fd29-4966-ae6f-217472f5439c","0.0","00000000-0000-0000-0000-000000000000","0","","Amy Jones60","personal","",""

    Disable wiki page versioning

    By default users can see all of the versions of a wiki page. You can disable versioning in the wikis-config.xml properties file.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    Disable versioning can help control the size of data storage. When you disable versioning before users start using Wikis, only one version of a page is ever stored, and all updates are reflected in that version.

    However, you can disable versioning at any time. If there are already multiple versions of a page when you disable versioning, the latest version becomes the "active" version, and all future updates are reflected in that version. The older versions are hidden from the user interface, but still exist and take up space in the database. If a user reaches their space quota, you can delete these older versions by enabling versioning again and having the user open the file page, click the Versions tab, and delete versions.

    You can also perform a manual database update to remove all versions of files prior to the current ones. You would execute a delete statement on your database for the MEDIA_REVISION table, but you must specify a constraint that the column IS_CURRENT_REVISION = 0, as a record still exists for the current version.

    Remember that in Wikis file attachments, which are not versioned, take up the most space. Only pages are versioned. So depending on your environment you may not need to disable versioning at all.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Optional: To view the current configuration settings use the following command:

      WikisConfigService.showConfig()

    4. To set the file.versioning.enabled property to false, use the following command:

      WikisConfigService.updateConfig("file.versioning.enabled", "false")

    5. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.

    Delete wikis from the system

    Use the WikisLibraryService delete commands to delete wikis.

    Use wikis administrative commands to see wiki library information to help you decide what wikis to delete, for example the WikisLibraryService.browseWiki command returns a list of wikis with information on each wiki. Use the returned information to see which wikis have not been updated in a long time. See the topic Wikis administrative commands for detailed information.

    To use administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    In the Wikis database context, a library contains the pages, attachments, and other data that make up a wiki. Wikis can be owned by a person or a community. However, you should delete community libraries following steps in the topic Deleting orphaned data.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run one of these commands to delete libraries:

      • Run this command to delete a single library:

        WikisLibraryService.delete(libraryId)

        where libraryId is the library id in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      • Run this command to delete multiple libraries:

        WikisLibraryService.deleteBatch(filePath)

        where filePath is the full path to a text file containing a list with a single library id per line in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000. You must create the file and save it in a directory local to the server where you are running the wsadmin processor.

    Find the location of a stored attachment

    Use the FilesUtilService.getFileById command to locate a file attachment stored in a directory on a file system.

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details.

    Many commands ask for IDs as input parameters, such as library IDs, user IDs, policy IDs, and file IDs. You can use commands that take parameters you do know to return data including the ID you are looking for. For example, run WikisMemberService.getByEmail(string email) providing a user's email address and among the data returned is the user's ID. You can also find IDs using feeds. See the Lotus Connections API documentation for information on getting ID information using feeds.

    In network deployments, files attached to wiki pages are stored on a shared file system, as described in the topic Install the first node of a cluster.

    This command can be useful when restoring backup versions of data. See the topic Back up Files data for more information.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter :

      execfile("wikisAdmin.py")

    3. Run the following command to locate a file attachment stored in the file directory:

      WikisUtilService.getFileById(fileId)

      where fileID is the ID of a file stored in the database. The ID must be a string in the following standard Universally Unique Identifier (UUID) format: 00000000-0000-0000-0000-000000000000.

      The command returns the file path as a string, even if the file is not in use.

    Display file attachments inline

    Configure Wikis to display file attachments inline instead of as attachments. This is useful when you download and display active content, such as Adobe Flash (.swf) files, in your own HTML pages. Enable inline display by changing a configuration property in the wikis-config.xml file. Then change the attachment URLs to use inline parameter.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for information about how to start the wsadmin command-line tool.

    By default, the IBM Connections server passes Wikis application file attachments to browsers with the header "Content-Disposition: attachment." This means files display as attachments; when users click the attachment they are prompted to open or download the file. It also prevents embedding files. If you want to embed files in your own HTML page using an <embed> tag, the content disposition must be inline. This affects active content, such as Adobe Flash (.swf), and HTML pages referenced with <iframe>.

    Configure a property in wikis-config.xml to change the content disposition from attachment to inline.

    Important: Wikis uses the attachment disposition for security reasons. Specifically, uploaded files could potentially contain malicious code that can exploit the cross-site scripting vulnerabilities of some browsers. If you switch to inline disposition, you should configure an alternate domain download for greater security. See Mitigating a cross site scripting attack.

    1. Start the wsadmin client.

    2. Start the Wikis Jython script interpreter.

      1. Use the following command to access the Wikis configuration files:

        execfile("wikisAdmin.py")
        If you are asked to select a server, you can select any server.

      2. Check out the Wikis configuration files :

        WikisConfigService.checkOutConfig("working_directory", "cell_name")

        where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        WikisConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    3. Change the content disposition to inline :

      WikisConfigService.updateConfig("security.inlineDownload.enabled", "true")

    4. You must check the configuration files back in after making changes, and they must be checked in during the same wsadmin session in which they were checked out for the changes to take effect. See the topic Applying Wikis property changes for details.

    5. Change your attachment URLs to use the inline parameter.

    Starting the wsadmin client - reuse

    This topic is just meant to be the source of the steps to be reused in an ordered list instead of substeps.

    Procedure

    Start the wsadmin client :

    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:

      app_server_root\profiles\dm_profile_root\bin

      ...where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on

      Windows:

      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin

      You must run the following command to start the wsadmin client from this specific directory because the Jython files for the product are stored here. If you try to start the client from a different directory, then the execfile() command that you subsequently call to initialize the administration environment for an IBM Connections component does not work correctly.

    2. Enter the following command to start the wsadmin client:

      • AIX or Linux:

        ./wsadmin.sh -lang jython -user admin_user_id -password admin_password -port SOAP_CONNECTOR_ADDRESS Port

      • Microsoft

        Windows:

        wsadmin -lang jython -user admin_user_id -password admin_password -port SOAP_CONNECTOR_ADDRESS Port

      where:

      • admin_user_id is the user name of a person in the Administrator role on the IBM WebSphere Application Server.

      • admin_password is the password of the WebSphere Application Server administrator.

      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server. The default value of the SOAP port is 8879. If you are using the default port value, you do not need to specify this parameter. If you are not using the default and you do not know the port number, you can look up its value in the WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:

        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.

        2. In the Additional properties section expand Ports, and then look for the SOAP_CONNECTOR_ADDRESS port entry to find the port number.

      For example:

      • AIX or Linux:

        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879

      • Microsoft

        Windows:

        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879

    Performance

    Get information about how to configure IBM Connections for optimal performance.


    About this task

    Refer to the IBM Connections wiki for information about how to improve the performance of IBM Connections.

    IBM Connections wiki > Tuning for performance

    Integrate with other products

    You can integrate IBM Connections applications with other products.

    Extend IBM Connections to work with the following products:

    IBM Connections Plug-in for IBM Sametime®

    Use the IBM Connections Plug-in for Sametime to bring powerful capabilities of the Activities and Profiles applications to your Sametime client.

    IBM Connections Plug-in for IBM Lotus Notes®

    The Activities sidebar has been expanded to provide additional applications within the Notes client. Just choose the Connections component during the Notes client installation.

    IBM Connections Status Updates Plug-in for Lotus Notes

    Keep up-to-date with your Connections network from your Notes client. Use this sidebar application to post your status and view status for your colleagues.

    IBM Connections Files Plug-in for Lotus Notes

    Upload and access Connections files from your Lotus Notes sidebar.

    IBM Connections Portlets for IBM WebSphere Portal

    Use the Connections portlets to bring the collaborative power of Blogs, Activities, Bookmarks, Profiles, Wikis and Tags to your WebSphere Portal environment.

    IBM Connections Business Card

    Replace the standard Sametime business card with a business card that displays content from the person's IBM Connections profile and includes links to Connections content they own.

    IBM Connections Plug-in for Microsoft Office and Microsoft Windows

    Use the IBM Connections Plug-in for Microsoft Office and Microsoft Windows to integrate your collaboration tools. You can post mail messages to activities or get the benefit of Profiles in your Outlook client. Bring the powerful capabilities of the Activities, Blogs, and Profiles applications to your office applications, such as Microsoft Word, and add files from Windows Explorer to an activity in seconds. Use the Microsoft Outlook Social Connector to interact with your Connections network.

    IBM Connections Plug-in for Microsoft SharePoint

    Use the IBM Connections Plug-in for Microsoft SharePoint to integrate IBM Connections collaboration services with Microsoft SharePoint.

    Use these other products from within IBM Connections:

    IBM Connections Widget for Microsoft SharePoint

    Use the IBM Connections Widget for Microsoft SharePoint to access Microsoft SharePoint documents from a community.

    IBM Lotus Quickr®

    Use the IBM Connections Connector for Quickr to integrate Lotus Quickr places with communities. Community members can use different types of Lotus Quickr places to organize and share project files, post comments to a blog, and work collaboratively on team documents.

    Notes:

    • Install IBM Connections before attempting to install and use the plug-ins. The plug-ins rely on the functionality of the applications provided in the IBM Connections application.

    • Do not configure IBM Connections to prevent email addresses from being displayed. If you hide email addresses, the extensions will not function, with the exception of the IBM Connections Portlets for IBM WebSphere Portal and the connectors for Communities. IBM Connections Connector for Quickr can be installed and will function in an IBM Connections deployment that is configured to prevent email addresses from being displayed:

    Install plug-ins to use IBM Connections in other applications

    Enhance the other products that you use every day by making IBM Connections applications available from them.

    You can access your IBM Connections data from within other products by adding plug-ins to those other products.


    IBM Connections Plug-in for IBM Sametime

    Bring a set of the powerful social networking applications of IBM Connections into the Sametime client.

    The IBM Connections Plug-in for Sametime is available in two forms:

    • The plug-in for Sametime embedded in the Notes client is available as an option during the Notes client installation.

    • The plugin for the stand-alone Sametime client is provided as an update site, available as a download from the IBM Connection plug-in catalog.
    The plug-in provides the following features:

    • Activities . Use this application to save chats to activities, open activities from your Sametime window, or find activities that you share with a contact.

    • Connections Business Card . Use this application to find out more about the people in your Sametime Contact list by viewing their business cards.

    • Communities . Save chats to a community forum. This feature is only available in the standalone version of Sametime, not in the embedded version.


    Install the IBM Connections Plug-in for Sametime

    As the administrator, you can download the IBM Connections Plug-in for Sametime and host it in a location from which your users can access it to upgrade their own Sametime clients.

    The IBM Connections Plug-in for Sametime requires Sametime version 8.0 or later. The following instructions are for downloading and installing the plug-in for the stand-alone Sametime client. The plug-in for use with the embedded Sametime client is available as a Notes installation option.

    In order for the plug-in to be available for users to install from their Sametime clients, Sametime must be configured to allow plug-ins, as described in the Plug-in Management section of this topic: http://publib.boulder.ibm.com/infocenter/sametime/v8r5/index.jsp?topic=/com.ibm.help.sametime.v85.doc/admin/admin_ssc_policies_comm_list.html if the setting "Allow user to install plug-in" is not enabled, users will be unable to access the plug-in. The IBM Connections plug-in for Sametime allows users to save chats to activities, open related activities from a Sametime chat window, or save chats to a community forum. In addition, users can display contact information that is pulled directly from the Profiles server. To install the plug-in:

    1. Download the plug-in from the IBM Connections catalog web site:

      https://greenhouse.lotus.com/catalog

    2. Save the update site files (site.xml file, plugins directory, and applications directory) to a location on your server. The location must be one that can be addressed by a web browser. Consult the IBM HTTP Server documentation for information on setting up addressable directories. The ht_docs directory is the default root directory of the HTML document repository.

    3. Let your users know the address from which the site is available so that they can specify it as the "New Remote Site" when they upgrade their clients to use the applications. For example, if you copied the update site files to an IBM HTTP Server directory called /opt/IBM/IHS61/htdocs/en_US/plugins, your users could use the following web address as the Remote Site:

      http://myserver/plugins

    4. On the Sametime 8.0 or later server, enable your users to save chat transcripts. Otherwise, they will not be able to save chat transcripts to activities.

    5. Instruct your users to follow the steps described in the topic, Add the IBM Connections Plug-in for Sametime to your client, to complete the installation.


    Add the IBM Connections Plug-in for IBM Sametime to your client

    Use the built-in upgrade facility of the Sametime client to install the features provided by the IBM Connections Plug-in for Sametime that your administrator has made available to you. If you do not have access to the plug-in, contact your site administrator.

    Your Sametime client must be version 8.0 or later. To add the IBM Connections features to your Sametime client, complete the following steps:

    1. From the Sametime client on which you want to implement the features, select Tools > Plug-Ins > Install Plug-ins from the menu.

    2. On the Install/Updates page, choose Search for new features to install, and then click Next.

    3. Select New Remote Site.

    4. Type a name, such as IBM Connections Plugin, in the Name field, and then type the web address provided by your administrator in the URL field.

    5. Click OK.

    6. In the Updates window, expand the site you selected, and then expand the IBM Connections folder.

    7. Select the check box next to IBM Connections if you want to install all plug-in features. If you want to only install certain features, select the check boxes for the components individually:

      • Activities Sametime Feature . Use this feature to save chats to activities, open activities from your Sametime window, or find activities that you share with a contact.

        To display the Save chat to activities icon, enable the Allow user to save chat log option on the Sametime server.

      • Connections Business Card . Use this feature to find out more about the people in your Sametime Contact list by viewing their business cards.

      • Communities Sametime Feature - Use this feature to save chats to communities forums.
      Click Next.

    8. Click each feature to read its license agreement, select I accept the terms in the license agreement, and then click Next to open the installation page.

    9. Review the features to be installed, and then click Finish.

    10. After the client restarts, select File > Preferences, and then click Connections.

    11. Fill out the fields in the Preferences page:

      • User name . Set the user name you use to log into IBM Connections.

      • Password . Set the password associated with the user name you use to log into IBM Connections.

      • Server URL . Server URL - Set the web address for the Connections server provided by your administrator. For example: http://enterprise.acme.com .
      Click Apply, and then click OK.


    IBM Connections Communities and Sametime Advanced Server Integration

    The IBM Sametime Advanced Server can be configured to load Broadcast Communities from your IBM Connections Community server.

    This application lets users save a broadcast chat to a community on the IBM Connections Communities server using the IBM Connections plug-ins for Sametime with Sametime clients configured to access the Sametime Advanced server. Refer to the Sametime Advanced documentation in the Sametime wiki for instructions.


    Configure the Sametime Advanced server

    After installing the Communities server and the required Sametime software, the next step is to configure the Sametime Advanced server to download communities from the Communities server.

    To integrate Connections with Sametime Advanced, you must give the Sametime Advanced administrator permissions to view all of the communities in Connections. Sametime Advanced then uses that administrator.s account to download the list of communities from Connections and display it in the Broadcast Communities panel in Sametime Advanced.

    Integration between IBM Sametime and IBM Connections products is one of the features of the IBM Connections Suite.

    1. 1.Create a dedicated Communities administrator. For more information, see Administering community content.

      You will use this account when synchronizing Connections with Sametime Advanced in a later step.

    2. Determine the name of the LDAP realm used by the Connections deployment:

      1. On the Connections deployment manager, log in to the WebSphere Integrated Solutions Console as the WebSphere administrator.

      2. In the navigation list, click Security > Secure Administration, applications and infrastructure > Federated Repositories.

      3. Click Configure.

      4. On the main Federated repositories page, note the value for the realm name used for the Connections deployment.

      5. Close the Federated repositories page by clicking Cancel.

    3. Move to the computer hosting the Communities application for Connections, and start the wsadmin client :

      1. Open a command prompt, and then change to the following directory:

        WAS_install_root\profiles\DM_profile\bin

        ...where WAS_install_root is the WebSphere Application Server installation directory and DM_profile is the Deployment Manager profile directory, typicallydmgr01. For example, on Microsoft

        Windows:

        C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin

        You must start the wsadmin client from this directory because the Jython files for the product are stored here. If you try to start the client from a different directory, the execfile() command that you subsequently call to initialize the administration environment for a Connections component does not work correctly.

      2. Start the wsadmin client with the following command:

        IBM AIX, Linux

        ./wsadmin.sh -lang jython -user was_admin_user_id -password was_admin_password -port SOAP_CONNECTOR_ADDRESS_port

        Windows

        wsadmin -lang jython -user was_admin_user_id -password was_admin_password -port SOAP_CONNECTOR_ADDRESS_port

        where:

        • was_admin_user_id is the user name of the WebSphere administrator account on the deployment manager.

        • was_admin_password is the password of the WebSphere administrator account.

        • SOAP_CONNECTOR_ADDRESS_port is the SOAP port for WebSphere Application Server. The default value of the SOAP port is 8879; if you are using the default port value, you do not need to specify this parameter.

          If you are not using the default port and you do not know the port number, you can look up its value in the WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:

          1. Open the Integrated Solution Console for the deployment manager, and select System Administration > Deployment Manager.

          2. Under "Additional properties" expand Ports, and then look for the SOAP_CONNECTOR_ADDRESS port entry to find the port number.
        For example:

        AIX, Linux

        ./wsadmin.sh -lang jython -user primaryAdmin -password p@assword -port 8879

        Windows

        wsadmin -lang jython -user primaryAdmin -password p@assword -port 8879

    4. Now access and check out the Communities configuration file:

      1. Access the Communities configuration files with the following command:

        execfile("communitiesAdmin.py")
        If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

      2. Check out the Communities configuration files :

        CommunitiesConfigService.checkOutPolicyConfig("working_directory", "Cell_name")

        ...where:

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.

          AIX and Linux only: The directory must grant write permissions or the command will not run successfully.

        • Cell_name is the name of the WebSphere Application Server cell hosting the Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:

          print AdminControl.getCell()
        For example:

        CommunitiesConfigService.checkOutPolicyConfig("/opt/my_temp_dir", "CommServerNode01Cell")

      3. Change to the working_directory where you stored the checked out files and open the communities-policy.xml file in a text editor.

      4. Make sure the file contains the following grant statement; if not, copy the code below and paste it into the section containing grant statements, and fill in the realm and Sametime Advanced administrator.s user name.

        Even if the file already contains the grant statement, you will need to add the first line, which specifies the user who is receiving permissions.

        <comm:grant>
         <comm:principal class="com.ibm.ws.security.common.auth.WSPrincipalImpl" name=" Connections_Realm/ST_Advanced_admin_user_name " />	<comm:principal class="com.ibm.tango.auth.principal.Role" name="admin" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityManagementPermission" communityType="*" action="*" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityMembershipPermission" communityType="*" action="*" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityAccessPermission" communityType="*" action="*" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityReferencePermission" communityType="*" action="*" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityBroadcastPermission" communityType="*" action="*" />
        	<comm:permission class="com.ibm.tango.auth.permission.CommunityInvitePermission" communityType="*" action="*" />
        </comm:grant>

        where:

        • Connections_Realm is the Connections LDAP repository realm name that you identified in step 1.

        • ST_Advanced_admin_user_name is the user name of the Sametime Advanced administrator who will have permissions to view Connections communities.

      5. Save and close the file.

      6. Check in the updated file using the following wsadmin client command:

        CommunitiesConfigService.checkInPolicyConfig("working_directory", "Cell_name")

    5. Exit the wsadmin client with the following command: exit.

    6. Stop and restart the server.

    7. Synchronize Connections and Sametime Advanced:

      1. Move to the Sametime System Console and log in as the Sametime administrator.

      2. Click Sametime Servers > Sametime Advanced Server.

      3. Click the name of the Sametime Advanced server.

      4. On the Administrative Sets tab, location "Connection settings".

      5. Select https protocol.

      6. Set the fully qualified host name in the Host name field.

      7. Set the port number in the Port field.

      8. Set the user name and password for the Communities administrative user created in step 1.

      9. Select the Enable Daily Community Synchronization check box.

        The servers will synchronize daily at 2 AM in the time zone of the Sametime Advanced server.

      10. Click Save.

      11. Click Synchronize Now to synchronize immediately rather than waiting for the scheduled synchronization.

        Sametime Advanced cannot access the list of broadcast communities until synchronization is complete.


    Enable SSL access to the Communities Server

    To secure access between the Communities server and the Sametime Advanced server, perform the following steps.

    1. From the Sametime Advanced server, select Security > SSL Certificate and key management > Key store and certificates > NodeDefaultTrustStore > Signer Certificates.

    2. Select Retrieve from Port.

    3. Enter the host and port details for the Communities server to connect to.

    4. Click OK.

    5. Save the results and reboot the server if needed.


    Remove the IBM Connections Plug-in for Sametime

    Remove the plug-in using the standard Sametime feature removal tools. To remove the IBM Connections Plug-in for Sametime, complete the following steps:

    1. From the Sametime client, select Tools > Plug-Ins > Manage Plug-ins.

    2. Click the Show Nested Features icon to display a list of the installed features.

      You may need to expand sections to find the features.

    3. Find Activities Sametime Feature in the list. Right-click the feature name, and then select Uninstall.

    4. When asked to confirm, click OK. When asked to restart, click No.

    5. Find Communities Sametime Feature in the list. Right-click the feature name, and then select Uninstall.

    6. When asked to confirm, click OK. When asked to restart the client, click No.

    7. Find Connections Business Card in the list. Right-click the feature name, and then select Uninstall.

    8. When asked to confirm, click OK. When asked to restart the client, click Yes.


    IBM Connections Portlets for WebSphere Portal

    Bring the power of IBM Connections to your portal applications.

    This section describes the 3.0.1.1 version of the IBM Connections Portlets for WebSphere Portal. The portlets do not currently support the IBM Connections 4 servers. This section will be updated when support for Connections 4 is certified.

    Install the 3.0.1.1 version makes the following portlets available to your portal users:

    • Activities . Collaboration tool for collecting, organizing, sharing, and reusing work related to a project goal.

    • Blogs . Online journals you can use to deliver timely information with a personal touch.

    • Bookmarks . Social bookmarking tool that you can use to save, organize, and share Internet and intranet bookmarks.

    • Tags . Meaningful keywords you can use to find associated content.

    • Profiles . Directory of colleagues you can use to build a network and locate expertise.

    • Wikis . Repository for sharing and collaborating on pages of interest to your group.

    • Forums . View and contribute to discussion topics.

    • Community Overview . View basic community information like the description, tags, and community owners. Perform basic community actions from the portlet.

    • Blogs Summary . Choose a view to see a snapshot of recent, latest, or featured blog activity

    • Profiles Summary . View a summary of information about your colleagues.

    • Forums Summary . View a list of forums that you can access.

    • Bookmarks Summary . View a list of bookmarks you can access.

    With the 3.0.1.1 version, you can also deploy community pages, which are portal pages associated with communities from IBM Connections communities. Portlets on community pages are automatically scoped to the community membership and display content from the community in the portlets. For example, if your community contains a forum, adding the forum portlet to a community page lets portal users view and interact with the forum content from a Portal application.

    If you are installing the 3.0.1.1 version of IBM Connections Portlets for IBMWebSphere Portal, you must uninstall any previous versions of the portlets before you install. Upgrading from previous versions is not supported.


    What's New in the IBM Connections Portlets for WebSphere Portal

    IBM Connections Portlets for WebSphere Portal includes some new and updated features.

    The IBM Connections Portlets for WebSphere Portal do not yet support the IBM Connections 4 servers. This section is a placeholder until support is enabled.


    Deploying the IBM Connections portlets

    Deploy the IBM Connections to bring social business to your portal applications.

    Follow these instructions to install, configure, and deploy the IBM Connections portlets for IBM WebSphere Portal.

    If you plan to deploy IBM Connections portlets on anonymous pages that do not require authentication, find out more in this article from the IBM Web Experiences wiki. Follow the steps for setting up anonymous access in the "Enabling session IDs for anonymous users" article from the IBM WebSphere Portal wiki.

    Restriction: In order to use common directory services, Portal must be configured to use a federated LDAP. Use of a stand-alone LDAP is not supported.


    Configure the resource environment provider

    You must add IBM Connections server URLs to the WebSphere Resource Environment provider as part of the configuration.

    Follow these steps to configure the environment variable to set the IBM Connections server URLs for the portlets.

    1. Log into the WebSphere Application Server Integrated Solutions Console.

    2. Navigate to Resources > Resource Environment > Resource Environment Providers.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. Click New and specify as name WP ConnectionsIntegrationService.

    5. Click Apply.

    6. Click Custom Properties.

    7. Click New and create the following attributes:

      These fields are mandatory:

      Name Description Type

      blogsHomepageHandle

      Set to the blogs Home page handle for your IBM Connections deployment. The default is Home.

      The homepage handle can be found under Apps > Blogs > Administration in the field Handle of blog to serve as Blogs Homepage when logged into the Connections server as a blogs administrative user.

      java.lang.String

      connVersion 3.0.1.1 java.lang.String

      tagSearchType Set to search or mysearch depending on whether you want the tag cloud to display tags only for public content or tags for public content as well as content the logged-in user has contributed. java.lang.String

      emailSet Set to email-exposed or email-hidden depending on whether or not the IBM Connections server is configured to expose user email addresses or to hide them. java.lang.String

      If you are using the same hostname for all Connections services and the default context roots for every service then you only need to set the following additional parameter and ignore the optional parameters for setting the individual service URLs and context roots:

      Name Description Type

      globalBaseURL Base URL to the Connections server. For example, https://connections.ibm.com java.lang.String

      All URL parameters should be set using the SSL (https) protocol and port.

      Optional: If you use a different hostname for each of your Connection services set the following parameters instead of globalBaseURL:

      Name Description Type

      activitiesURL Base URL to the Activities service. For example, https://connections-activities.ibm.com.. java.lang.String

      profilesURL Base URL to the Profiles service. For example, https://connections-profiles.ibm.com . java.lang.String

      communitiesURL Base URL to the Communities service. For example, https://connections-communities.ibm.com . java.lang.String

      blogsURL Base URL to the Blogs service. For example, https://connections-blogs.ibm.com . java.lang.String

      bookmarksURL Base URL to the Bookmarks service. For example, https://connections-dogear.ibm.com java.lang.String

      forumsURL Base URL to the Forums service. For example, https://connections-forums.ibm.com java.lang.String

      wikisURL Base URL to the Wikis service. For example, https://connections-wikis.ibm.com java.lang.String

      searchBaseURL Base URL to the SearchBaseURL service. For example, https://connections-search.ibm.com java.lang.String

      Optional: If you are not using the default context root to address each Connections service, set the following parameters to define the context roots used for your Connections deployment:

      Name Description Type

      activitiesContextRoot The context root for the Activities service. For example, /mycontext/activities. If this parameter isn't defined, the default context root will be used: /activities java.lang.String

      profilesContextRoot The context root for the Profiles service. For example, /mycontext/profiles. If this parameter isn't defined, the default context root will be used: /profiles. java.lang.String

      communitiesContextRoot The context root for the Communities service. For example, /mycontext/communities. If this parameter isn't defined, the default context root will be used: /communities. java.lang.String

      blogsContextRoot The context root for the Blogs service. For example, /mycontext/blogs. If this parameter isn't defined, the default context root will be used: /blogs. java.lang.String

      bookmarksContextRoot The context root for the Bookmarks service. For example, /mycontext/dogear. If this parameter isn't defined, the default context root will be used: /dogear. java.lang.String

      forumsContextRoot The context root for the Forums service. For example, /mycontext/forums. If this parameter isn't defined, the default context root will be used: /forums. java.lang.String

      wikisContextRoot The context root for the Wikis service. For example, /mycontext/wikis. If this parameter isn't defined, the default context root will be used: /wikis. java.lang.String

      searchContextRoot The context root for the Search service. For example, /mycontext/search. If this parameter isn't defined, the default context root will be used: /search. java.lang.String

      If you are configuring the portlets with a single sign on solutions, for example, Tivoli Access Manager, use the URL you use to access the IBM Connections server for single sign-on.

      (Optional) These variables control display features for the Connections portlets.

      Name Description Type

      showContentTitleInPortlet

      This is used to show/hide the Content title within the portlet. The default value is True, because by default the theme for Portal 7.0.0.2 and Portal 8 portlets deploys portlets without a skin. In those cases, it is important to display the content title in the portlet.

      java.lang.String

      showForumSummaryFiltersInCommunity This is used to show or hide options, for example, Open questions or Answered question for the Forums summary portlet, because there is no API support to filter topics in a community scope. The default value is False. java.lang.String

      (Optional) Some of the Connections portlets (Blogs, Bookmarks and Activities) use Dojo dialogs for creating and editing content. Theme resources are not available inside Dojo dialogs. To optimize the Dojo loading while working with Dojo dialogs, configure the following property. It contains the comma-separated list of Dojo layers to be loaded for optimizing the Dojo loading inside the dialogs. The defaults correspond to the Portal server.

      Name Description Type

      dojoLayers

      Default value for Portal 7: _dom_layer.js,dojo.js,_app_layer.js,dijit.js,_data_layer.js,_dijit_menu_layer.js,_fmt_layer.js,_fx_layer.js,_dijit_layout_basic_layer.js,_dojox_layout_basic_layer.js,_dnd_ext_layer.js

      Default value for Portal 8: _dom.js,_app.js,dijit.js,_data.js,_dijit_menu.js,_fmt.js,_fx.js,_dijit_layout_basic.js,_dojox_layout_basic.js,_dnd_ext.js,_dnd_basic.js

      java.lang.String

    8. Save the new settings.


    Configure the DynaCache

    Configure DynaCache to store community feeds in order to reduce server requests.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 to use this feature. The IBM Connections portlets use a DynaCache to store the initial service configuration URLs for the portlets and then to store the Community feed URLs and other information to optimize the page load performance for community pages. Storing the community feed URLs in the DynaCache reduces the number of server requests to the IBM Connections server to render the content in each of the portlets.

    To set up the Connections Portlets DynaCache instance for each node in you portal cluster, do the following:

    1. Open the WebSphere Application Server Admin Console and expand Cache Instances in the Resources section.

    2. Select Object Cache Instances.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. Click New to create a new cache instance.

    5. Set the JNDI Name to services/cache/LCPortletsObjectCache and set Name to something meaningful.

    6. Click OK to save your changes.


    What to do next

    The default value of 2000 is designed to handle the number of community feeds for an average deployment. You can edit this value. For example, you might set this value to 20 times the number of active communities that would be accessed in ten minute period.


    Set up an authentication alias for the portlets

    Set up an authentication alias with user credentials from the common LDAP shared between IBM Connections and Portal to manage VMM services. To set up an authentication alias with user credentials from the common LDAP between IBM Connections and Portal, follow these steps:

    In a network environment, you must create the alias in the WebSphere Application Server Integrated Solutions Console for the Deployment Manager.

    1. In the WebSphere Application Server Integrated Solutions Console, expand Security, and then select Global Security.

    2. Expand Java Authentication and Authorization Service.

    3. Select J2C authentication data.

    4. Click New and specify the alias name and the user credentials for a user from the common LDAP between IBM Connections and Portal. If you are deploying on Portal 7.0.0.2, make sure Prefix new alias names with the node name of the cell is checked before creating the alias. If you are deploying on Portal 8, Prefix new alias names with the node name of the cell can be de-selected. However, if it is de-selected, you must make sure that the alias name in the directory.services.xml does not have the prefix. For more information on configuring the directory.services.xml file, see the topic Configuring portlets to use common directory services.

      This user must be assigned the dsx-admin role in Connections for the Communities application. For more information, see the topic Roles.

    5. Click OK and Save.


    Results

    After you have created the authentication alias, you will see the alias prefixed with the WebSphere cell name. For example:

    <cellname>/dsxAdmin connectionsAdmin

    on a Portal 8 server, the alias is prefixed with the node name. for example, <nodename>/dsxAdmin.


    Configure portlets to use common directory services

    Configure the IBM Connections portlets to use the common directory services to enable directory lookup from IBM Connections in the IBM WebSphere Portal environment. This enables typeahead for finding names.

    For general information on enabling common directory services for IBM Connections applications, refer to the topic Using the Profiles database as the user directory. If you have not already done so, create an authentication alias, described in the topic Set up an authentication alias for the IBM Connections portlets.

    Restriction: In order to use common directory services, Portal must be configured to use a federated LDAP. Use of a stand-alone LDAP is not supported. Follow these steps to configure common directory services for the IBM Connections portlets.

    1. Stop WebSphere Portal Server. For a clustered deployment, stop all Portal servers.

    2. On the server hosting IBM Connections, open LotusConnections-config.xml for editing. This file is located in the {install.root}/config/cells/{local.cell}/LotusConnections-Config directory.

    3. Make sure the Profiles database is set up to be the user directory for IBM Connections by looking for the following setting:

      profiles_directory_service_extension_enabled="true"
      If this setting is not enabled, see Using the Profiles database as the user directory to find the steps you can follow to enable it.

      Make sure that the Profiles user directory includes the user dsxAdmin, which is used in Portal for creating the J2C authentication alias.

    4. Locate the <serviceReference> elements with the serviceName="communities" and serviceName="profiles" attributes and take note of the values of the <interService> and <hrefPathPrefix> elements.

      <sloc:serviceReference serviceName="profiles"
        <sloc:hrefPathPrefix>/profiles</sloc:hrefPathPrefix>
        <sloc:interService href="https://enterprise.example.com:9080"/>
      </sloc:serviceReference>
      <sloc:serviceReference serviceName="communities"
        <sloc:hrefPathPrefix>/communities</sloc:hrefPathPrefix>
        <sloc:interService href="https://enterprise.example.com:9081"/>
      </sloc:serviceReference>

    5. Do the following to copy the configuration files:

      • For a single server: On the IBM WebSphere Portal server, copy the following files:

        • directory.services.xml

        • directory.services.xsd

        • sonata.services.xml

        • sonata.services.xsd
        from the DirectoryServices directory from the IC Portlets 3.0.1.1 download package, <IC3011_portlets>\DirectoryServices, to: <portalInstallRoot>\wp_profile\config\cells\<cell>\ .

      • For a clustered deployment: On the primary IBM WebSphere Portal server, copy the files from the DirectoryServices directory from the IC Portlets 3.0.1.1 download package, <IC3011_portlets>\DirectoryServices, to the DMGR directory located at: <DMGR install root>\profiles\<dmgr profile name>\config\cells\<cell>\ .

    6. Edit directory.services.xml and set:

      Option Value

      com.ibm.connections.directory.services.waltz.profiles.integration.service.url [interService href] + [hrefPathPrefix] + /dsx/

      com.ibm.connections.directory.services.waltz.profiles.integration.service.auth.alias [cell name]/dsxAdmin

      com.ibm.connections.directory.services.waltz.communities.integration.service.url [interService href] + [hrefPathPrefix] + /dsx/

      com.ibm.connections.directory.services.waltz.communities.integration.service.auth.alias [cell name]/dsxAdmin

      The value for com.ibm.connections.directory.services.waltz.profiles.integration.service.auth.alias and com.ibm.connections.directory.services.waltz.communities.integration.service.auth.alias is the J2C authentication alias created in the Set up an authentication alias topic.

      The values for [interService href] and [hrefPathPrefix] for the Profiles and Communities integration service URL properties are the properties that were identified in the LotusConnections-config.xml configuration file in Step 4.

      For example, this is a sample code block from directory.services.xml after setting the parameters:

      <config version="3.0" id="directory.services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="directory.services.xsd">
        <profileProvider class="com.ibm.connections.directory.services.provider.WaltzServiceProvider">
          <property name="com.ibm.connections.directory.services.waltz.profiles.integration.service.enabled">true</property>
          <property name="com.ibm.connections.directory.services.waltz.profiles.integration.service.url">https://profiles.ibm.com/profiles/dsx/</property>
          <property name="com.ibm.connections.directory.services.waltz.profiles.integration.service.auth.alias">portalcell/dsxAdmin</property>
      
          <property name="com.ibm.connections.directory.services.waltz.communities.integration.service.enabled">true</property>
          <property name="com.ibm.connections.directory.services.waltz.communities.integration.service.url">https://communities.ibm.com/communities/dsx/</property>
          <property name="com.ibm.connections.directory.services.waltz.communities.integration.service.auth.alias">portalcell/dsxAdmin</property>
        <profileProvider/>
      </config>

    7. If you are using LTPA SSO, skip this step because no change is require. For other types of authentication, edit sonata.services.xml and change the sonataServices tag, <sonataServices name="DefaultAuthenticator">, to the appropriate value for the name attribute.

      • SPNEGO: <sonataServices name="KerberosAuthenticator">

      • TAM: <sonataServices name="TAMAuthenticator">

      • SiteMinder: <sonataServices name="SiteMinderAuthenticator">

      • TAM and SPNEGO: <sonataServices name="KerberosAuthenticator">

        On a Portal 8 server, use <sonataServices name="TAMAuthenticator">

      • SiteMinder and SPNEGO: <sonataServices name="KerberosAuthenticator+">

    8. (Clustered deployment only) Login to DMGR admin console and navigate to the System Administration - Nodes. Select both WebSphere Portal nodes and click Full Resynchronize.

    9. Restart the Portal server after updating directory.services.xml or restart all of the servers for a clustered deployment.


    Import a certificate to support SSL

    Import a certificate so that IBM Connections and WebSphere Portal can communicate over Secure Socket Layer (SSL). In order for WebSphere Portal to communication with IBM Connections over Secure Sockets Layer (SSL), the WebSphere Portal server must trust the signer of the SSL certificate for IBM Connections. This might be set up by default in your WebSphere infrastructure if you use SSL certificates issued by a commonly recognized authority. If you use self-signed certificates, the default certificate or a signer that is not recognized by your WebSphere Portal server, you will need to import the SSL certificate from IBM Connections to your WebSphere Portal server.

    Import the SSL keys into the Portal server as follows:

    1. Log into the WebSphere Application Server Integrated Solutions Console.

    2. Navigate to Security > SSL certificate and key management > Key stores and certificates.

    3. Add the certificates to the appropriate trust store as configured in SSL Configurations. To view the SSL configuration and determine the appropriate trust store, navigate to :Security > SSL certificate and key management > SSL configurations > NodeDefaultSSLSets > ['Trust Store Name'] For example, in a standalone deployment you navigate to NodeDefaultTrustStore > Signer certificates for adding certificates. If NodeDefaultSSL Sets points to 'CellDefaultTrustStore', you add a certificate to 'CellDefaultTrustStore'.

    4. Click Retrieve from port.

    5. Enter the host and SSL port used by your Connections server. The default SSL port is 443. Give the alias a name, for example, Connections. For example:

      Host:  connections.example.com
      Port:  443
      Alias:  connections

    6. Click Retrieve signer information.

    7. Click OK.

    8. Click Save.


    Configure authentication for the portlets

    Set up single sign-on integration between IBM Connections and WebSphere Portal using third-party security products, or configure basic authentication to enable access to the portlets.

    IBM Connections uses single sign-on (SSO) to secure the transfer of user ID and password information that is used to authenticate with the system. With SSO, users can switch to different applications without needing to authenticate again. SSO is automatically enabled when IBM Connections is installed on a single WebSphere Application Server profile or when different profiles are federated into the same cell.

    Configure basic authentication allows the manual entry of user credentials in the personalize mode of the portlets. Basic authentication for the portlets can only be supported if single sign-on is not already enabled between WebSphere Portal and IBM Connections. If single sign-on is enabled (through LTPA, Kerberos or another mechanism), it will take precedence. If single sign-on is enabled, the basic authentication credentials entered in the personalize mode of the portlets will be ignored.

    Configure single sign-on for end users is recommended over using basic authentication for end user interactions. When using basic authentication for the portlets, every user must type in their personal credentials manually in the personalize mode of the portlets or shared credentials can be supplied from the Credential Vault. Basic authentication can be especially useful for trials of the portlets before you have a chance to configure some form of single sign-on, but is not recommended for production use.


    Enable single sign-on for the portlets using a stand-alone LDAP server

    Before installing the IBM Connections Portlets for IBM WebSphere portal, enable single sign-on (SSO) between IBM Connections and WebSphere Portal..

    This task describes the steps required to enable SSO between IBM Connections and WebSphere Portal when they are on different WebSphere Application Server cells. Applications deployed on servers within the same WebSphere Application Server cell are enabled by default for SSO.

    You should set the realm name in the LTPA token to that of the LDAP server before you export the LTPA token. For example, if you connect to an LDAP server at ldapserver.example.com over port 389, then you must set the realm name to ldapserver.example.com:389. If you need to change the realm name, see the topic Changing the realm name.

    To allow SSO between IBM Connections and WebSphere Portal, complete the following steps:

    1. On the server where IBM Connections is installed, enable SSO:

      1. Log into the WebSphere Application Server Integrated Solutions Console as an administrator, expand Security > Global security.

      2. Expand Web and SIP security and then click Single sign-on (SSO).

      3. Enter the domain name .

        Ensure that the domain name you enter is valid: on the node where WebSphere Portal is installed, log into the WebSphere Application Server Integrated Solutions Console as an administrator, click Security > Global security > Web and SIP security > Single sign-on (SSO) and verify that the domain name is present.

    2. On IBM Connections deployment manager node:

      1. Log into the WebSphere Application Server Integrated Solutions Console as an administrator.

      2. Click Security > Global security > LTPA, and then in the Cross-cell single sign-on section, provide values for the following fields:

        • Password . Type a secure password that you will remember. You will need to provide this password later, when you export the key file

          Confirm the password.

        • Fully qualified key file name . Specify a valid path and a name for the file that will hold the exported keys

      3. Click Export keys.

    3. On the node where WebSphere Portal is installed:

      1. Log into the WebSphere Application Server Integrated Solutions Console as an administrator and click Security > Global security > LTPA.

      2. In the General properties section, provide values for the following fields:

        • Password . Set the password that you used for the IBM Connections key file that you exported

          Confirm the password.

        • Fully qualified key file name . Set the name of the IBM Connections key file that you exported

      3. Click Import keys

    4. Restart all the nodes.


    Configure single sign-on for portlets with TAM and SPNEGO

    Configure IBM Connections portlets to use single sign-on with IBM Tivoli Access Manager and SPNEGO.

    Single sign-on (SSO) enables users to log in to an IBM Connections application and switch to other applications within the product without having to authenticate again.

    There are several different ways to configure SSO. This procedure describes an approach that uses the Kerberos authentication protocol. This authentication method allows Tivoli Access Manager and users web browsers to prove their identities to one another in a secure manner. After users sign in to their Active Directory Windows client systems, they are automatically signed into both Tivoli Access Manager and IBM Connections.

    Configuring IBM Connections and WebSphere Portal to share a single Deployment Manager saves on administration time by combining administration tasks for the two applications. Establishing a single-sign on environment benefits the users by creating a more seamless environment between the two applications.

    Follow these steps to configure single sign-on.

    1. Before federating Portal as a managed node of the Deployment Manager of IBM Connections, make sure the realms match between Connections Deployment Manager and Portal. If change the realm names so they match, follow the steps in Changing the realm name.

    2. Perform the following steps to collect files from the primary node and copy them to the Deployment Manager:

      1. From the <wp_profile_root>/ConfigEngine directory of the primary node, run this task: ConfigEngine.bat collect-files-for-dmgr -DWasPassword=password . This creates a zip file containing all the files which need to be copied to the Deployment Manager. The zip file, named filesForDmgr.zip, will be placed in the <wp_profile_root>/filesForDmgr directory.

      2. Stop the Deployment Manager.

      3. Expand each of the files in the filesForDmgr.zip file into the proper location on the Deployment Manager based on the directory names within the zip file. The directory names in the zip file are based on the typical default directory names. The directory called AppServer/profiles/Dmgr01 is used to identify the Deployment Manager profile root, and the AppServer directory is used to identify the Deployment Manager installation root directory. If the Deployment Manager was installed into the default directory (AppServer) and the profile was created in the default directory (AppServer/profiles/Dmgr01), then the zip file can be expanded directly into the directory above the AppServer directory; for example /IBM/WebSphere.

      4. Start the Deployment Manager.

    3. To augment a Deployment Manager profile, run the following command from the <AppServer_root>/bin directory:

      manageprofiles.bat -augment -templatePath  c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01

    4. Restart the Deployment Manager.

    5. Add the same Portal administration group as an administrators group on the IBM Connections Deployment Manager.

    6. Run the following command from the <wp_profile_root>/bin directory to federate the primary node:

      addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
      -username was_admin_user
      -password was_admin_password
      For example:

      addNode.bat DMhost.cn.ibm.com 8879 -includeapps -includebuses -username adminuser -password adminpwd

    7. On the Portal server, run syncNode.bat and then restart the Deployment Manager and all node agents.

    8. To configure the IBM HTTP Server with Single Sign-On, delete and re-add the webserver on the WebSphere Application Server Integrated Solutions Console in order to re-map all applications including Portal, and import the Portal certificate into IBM HTTP Server.

    9. Skip this step if you are deploying on Portal 8. To Configure the same SPNEGO single sign-on for Portal and Connections:

      1. Create user for Portal host server on AD

      2. Create keytab file for Portal server on AD.

        ktpass -out path_to_keytab .princ SPN
        
        -mapuser account_name -mapOp set .pass account_password
        Where:

        • path_to_keytab is the file path where you want to store the generated keytab file.

        • SPN is the Kerberos service principal name.

        • account_name is the service account name.

        • account_password is the password associated with the service account.
        For example:

        ktpass -princ HTTP/portal.cn.ibm.com@cn.ibm.com -out c:\portal.keytab -mapuser portaluser -mapOp set -pass Passw0rd

      3. Merge the portal keytab into the merged Connections keytab by running the ktab command with the following switch:

        -m source_keytab_name destination_keytab_name
        Where:

        • source_keytab_name is the name of the keytab file on the source system.

        • destination_keytab_name is the name of the keytab file on the destination system.
        For example:

        c:\IBM\WebSphere\AppServer\java\jre\bin>ktab.exe -m y:\SPNEGO\portal.keytab y:\SPNEGO\merged.keytab

      4. Recreate the krb5.conf file using the new merged keytab file:

        $AdminTask createKrbConfigFile
        
        {
        
        -krbPath appserver\java\jre\lib\security\krb5.conf
        
        -realm REALM
        
        -kdcHost kdc_hostname
        
        -dns dns_hostname
        
        -keytabPath path_to_keytab
        }
        For example:

        wsadmin.bat -user adminuser -password adminpwd
        $AdminTask createKrbConfigFile {-krbPath y:\SPNEGO\krb5.conf -realm CN.IBM.COM -kdcHost AD.cn.ibm.com -dns cn.ibm.com -keytabPath y:\SPNEGO\merged.keytab}

      5. Enable SPNEGO single sign-on by configuring Kerberos in the WebSphere Application Server Integrated Solutions Console, following the steps in the Enabling single sign-on for Tivoli Access Manager with SPNEGO topic.

      6. Synchronize the node and restart the Deployment Manager node. If you can not manage the Portal node on the WebSphere Application Server Integrated Solutions Console , manually synchronize the node and restart the Deployment Manager node.

    10. Configure Tivoli Access Manager on the Portal server, following the directions in the topic Configure Tivoli Access Manager in the IBM WebSphere Portal product wiki. For example:

      server task default-webseald-TAMhost.cn.ibm.com create -t ssl -b filter -A -F C:\WASLTPA.key -Z password 
      -h DMhost.cn.ibm.com -c all -f -k -j -J trailer /wpsv70
      
      ConfigEngine.bat run-svrssl-config -Dwp.ac.impl.PDAdminPwd=password
      ConfigEngine.bat validate-pdadmin-connection -DWasPassword=password -Dwp.ac.impl.PDAdminPwd=password
      ConfigEngine.bat enable-tam-all -DWasPassword=password


    Configure single sign-on with TAM

    Configure IBM Connections portlets to use single sign-on with IBM Tivoli Access Manager.

    Single sign-on (SSO) enables users to log in to an IBM Connections application and switch to other applications within the product without having to authenticate again.

    There are several different ways to configure SSO. This authentication method allows Tivoli Access Manager and users web browsers to prove their identities to one another in a secure manner.

    Configuring IBM Connections and WebSphere Portal to share a single Deployment Manager saves on administration time by combining administration tasks for the two applications. Establishing a single-sign on environment benefits the users by creating a more seamless environment between the two applications.

    Follow these steps to configure single sign-on.

    1. Before federating Portal as a managed node of the Deployment Manager of IBM Connections, make sure the realms match between Connections Deployment Manager and Portal. If change the realm names so they match, follow the steps in Changing the realm name.

    2. Perform the following steps to collect files from the primary node and copy them to the Deployment Manager:

      1. From the <wp_profile_root>/ConfigEngine directory of the primary node, run this task: ConfigEngine.bat collect-files-for-dmgr -DWasPassword=password . This creates a zip file containing all the files which need to be copied to the Deployment Manager. The zip file, named filesForDmgr.zip, will be placed in the <wp_profile_root>/filesForDmgr directory.

      2. Stop the Deployment Manager.

      3. Expand each of the files in the filesForDmgr.zip file into the proper location on the Deployment Manager based on the directory names within the zip file. The directory names in the zip file are based on the typical default directory names. The directory called AppServer/profiles/Dmgr01 is used to identify the Deployment Manager profile root, and the AppServer directory is used to identify the Deployment Manager installation root directory. If the Deployment Manager was installed into the default directory (AppServer) and the profile was created in the default directory (AppServer/profiles/Dmgr01), then the zip file can be expanded directly into the directory above the AppServer directory; for example /IBM/WebSphere.

      4. Start the Deployment Manager.

    3. To augment a Deployment Manager profile, run the following command from the <AppServer_root>/bin directory:

      manageprofiles.bat -augment -templatePath  c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01

    4. Restart the Deployment Manager.

    5. Add the same Portal administration group as an administrators group on the IBM Connections Deployment Manager.

    6. Run the following command from the <wp_profile_root>/bin directory to federate the primary node:

      addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
      -username was_admin_user
      -password was_admin_password
      For example:

      addNode.bat DMhost.cn.ibm.com 8879 -includeapps -includebuses -username adminuser -password adminpwd

    7. On the Portal server, run syncNode.bat and then restart the Deployment Manager and all node agents.

    8. To configure the IBM HTTP Server with Single Sign-On, delete and re-add the webserver on the WebSphere Application Server Integrated Solutions Console in order to re-map all applications including Portal, and import the Portal certificate into IBM HTTP Server.

    9. Configure Tivoli Access Manager on the Portal server, following the directions in the topic Configure Tivoli Access Manager in the IBM WebSphere Portal product wiki. For example:

      server task default-webseald-TAMhost.cn.ibm.com create -t ssl -b filter -A -F C:\WASLTPA.key -Z password 
      -h DMhost.cn.ibm.com -c all -f -k -j -J trailer /wpsv70
      
      ConfigEngine.bat run-svrssl-config -Dwp.ac.impl.PDAdminPwd=password
      ConfigEngine.bat validate-pdadmin-connection -DWasPassword=password -Dwp.ac.impl.PDAdminPwd=password
      ConfigEngine.bat enable-tam-all -DWasPassword=password


    Configure single sign-on for portlets with Siteminder and SPNEGO

    Configure IBM Connections portlets to use single sign-on with Computer Associates' SiteMinder and SPNEGO.

    1. Enable Siteminder and SPNEGO for IBM Connections, following the steps in Enabling Siteminder and SPNEGO.

    2. Enable and configuring single sign-on for HTTP requests using SPNEGO following the steps in this topic.

    3. Configure SiteMinder following the steps in this topic.

    4. Merge all the keytab files to make the Deployment Manager aware of the SPNs for each node.

      The following example demonstrates the procedure for merging keytab files.

      Assuming that you have created the following keytab files:

      • krb5.keytab on the Deployment Manager

      • krb5NodeA.keytab on Node A

      • krb5NodeB.keytab on Node B

      Run the ktab command with the following switch:

      -m source_keytab_name> destination_keytab_name

      where source_keytab_name is the name of the keytab file on the source system and destination_keytab_name> is the name of the keytab file on the destination system.

      Step 1: merge the keytab file on Node A into the keytab file on the Deployment Manager:

      # ./ktab -m /etc/krb5NodeA.keytab /etc/krb5.keytab
      Merging keytab files:   source=krb5NodeA.keytab   destination=krb5.keytab
      Done! 

      Step 2: merge the keytab file on Node B into the keytab file on the Deployment Manager:

       # ./ktab -m /etc/krb5NodeB.keytab /etc/krb5.keytab
      Merging keytab files:   source=krb5NodeB.keytab   destination=krb5.keytab
      Done! 

      For more information, go to the Use the ktab command to manage the Kerberos keytab file topic in the IBM WebSphere Application Server 7 information center.

    5. Configure the Virtual Member Manager (VMM).

      1. If you haven.t already done so, follow the instructions in Configuring portlets to use common directory services, to copy sonata.services.xml to <wp_root>\config\cells\<cell name>\

      2. Edit sonata.services.xml to use KerberosAuthenticator+ instead of DefaultAuthenticator.

      3. Add all IIS, Portal and Connections servers SPN as attributes.
      For example:

      <sonataServices name="KerberosAuthenticator+">
        <attribute key="IISKerberosSPN" value="HTTP/wti-iis.spnego1.mul.ie.ibm.com@SPNEGO1.MUL.IE.IBM.COM"/>
        <attribute key="WebKerberosSPN" value="HTTP/dslvm326.spnego1.mul.ie.ibm.com@SPNEGO1.MUL.IE.IBM.COM"/>
        <attribute key="WebKerberosSPN" value="HTTP/dslvm442.spnego1.mul.ie.ibm.com@SPNEGO1.MUL.IE.IBM.COM"/>
        <attribute key="WASKerberosSPN" value="HTTP/dslvm443.spnego1.mul.ie.ibm.com@SPNEGO1.MUL.IE.IBM.COM"/>
        <attribute key="CookieTimeout" value="60"/>
      </sonataServices>


    Configure single sign-on for portlets with SPNEGO

    Configure IBM Connections portlets to use single sign-on with SPNEGO.

    Single sign-on (SSO) enables users to log in to an IBM Connections application and switch to other applications within the product without having to authenticate again.

    There are several different ways to configure SSO. This procedure describes an approach that uses the Kerberos authentication protocol. This authentication method allows users web browsers to prove their identities to one another in a secure manner. After users sign in to their Active Directory Windows client systems, they are automatically signed into IBM Connections.

    Configure IBM Connections and WebSphere Portal to share a single Deployment Manager saves on administration time by combining administration tasks for the two applications. Establishing a single-sign on environment benefits the users by creating a more seamless environment between the two applications.

    Follow these steps to configure single sign-on.

    1. Before federating Portal as a managed node of the Deployment Manager of IBM Connections, make sure the realms match between Connections Deployment Manager and Portal. If change the realm names so they match, follow the steps in Changing the realm name.

    2. Perform the following steps to collect files from the primary node and copy them to the Deployment Manager:

      1. From the <wp_profile_root>/ConfigEngine directory of the primary node, run this task: ConfigEngine.bat collect-files-for-dmgr -DWasPassword=password . This creates a zip file containing all the files which need to be copied to the Deployment Manager. The zip file, named filesForDmgr.zip, will be placed in the <wp_profile_root>/filesForDmgr directory.

      2. Stop the Deployment Manager.

      3. Expand each of the files in the filesForDmgr.zip file into the proper location on the Deployment Manager based on the directory names within the zip file. The directory names in the zip file are based on the typical default directory names. The directory called AppServer/profiles/Dmgr01 is used to identify the Deployment Manager profile root, and the AppServer directory is used to identify the Deployment Manager installation root directory. If the Deployment Manager was installed into the default directory (AppServer) and the profile was created in the default directory (AppServer/profiles/Dmgr01), then the zip file can be expanded directly into the directory above the AppServer directory; for example /IBM/WebSphere.

      4. Start the Deployment Manager.

    3. To augment a Deployment Manager profile, run the following command from the <AppServer_root>/bin directory:

      manageprofiles.bat -augment -templatePath  c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01

    4. Restart the Deployment Manager.

    5. Add the same Portal administration group as an administrators group on the IBM Connections Deployment Manager.

    6. Run the following command from the wp_profile_root>/bin directory to federate the primary node:

      addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
      -username was_admin_user
      -password was_admin_password
      For example:

      addNode.bat DMhost.cn.ibm.com 8879 -includeapps -includebuses -username adminuser -password adminpwd

    7. On the Portal server, run syncNode.bat and then restart the Deployment Manager and all node agents.

    8. To configure the IBM HTTP Server with Single Sign-On, delete and re-add the webserver on the WebSphere Application Server Integrated Solutions Console in order to re-map all applications including Portal, and import the Portal certificate into IBM HTTP Server.

    9. To Configure the same SPNEGO single sign-on for Portal and Connections.

      1. Create user for Portal host server on AD.

      2. Create keytab file for Portal server on AD:

        ktpass -out path_to_keytab .princ SPN
        
        -mapuser account_name -mapOp set .pass account_password
        Where:

        • path_to_keytab is the file path where you want to store the generated keytab file.

        • SPN is the Kerberos service principal name.

        • account_name is the service account name.

        • account_password is the password associated with the service account.
        For example:

        ktpass -princ HTTP/portal.cn.ibm.com@cn.ibm.com -out c:\portal.keytab -mapuser portaluser -mapOp set -pass Passw0rd

      3. Merge the portal keytab into the merged Connections keytab by running the ktab command with the following switch:

        -m source_keytab_name destination_keytab_name
        Where:

        • source_keytab_name is the name of the keytab file on the source system.

        • destination_keytab_name is the name of the keytab file on the destination system.
        For example:

        c:\IBM\WebSphere\AppServer\java\jre\bin>ktab.exe -m y:\SPNEGO\portal.keytab y:\SPNEGO\merged.keytab

      4. Recreate the krb5.conf file using the new merged keytab file:

        $AdminTask createKrbConfigFile
        
        {
        
        -krbPath appserver\java\jre\lib\security\krb5.conf
        
        -realm REALM
        
        -kdcHost kdc_hostname
        
        -dns dns_hostname
        
        -keytabPath path_to_keytab
        }
        For example:

        wsadmin.bat -user adminuser -password adminpwd
        $AdminTask createKrbConfigFile {-krbPath y:\SPNEGO\krb5.conf -realm CN.IBM.COM -kdcHost AD.cn.ibm.com -dns cn.ibm.com -keytabPath y:\SPNEGO\merged.keytab}

      5. Enable SPNEGO single sign-on by configuring Kerberos in the WebSphere Application Server Integrated Solutions Console, following the steps in the Enabling single sign-on for the Windows desktop topic.

      6. Synchronize the node and restart the Deployment Manager node. If you can not manage the Portal node on the WebSphere Application Server Integrated Solutions Console , manually synchronize the node and restart the Deployment Manager node.


    Change the realm name

    When you configure IBM Connections portlets to use single sign-on, you may need to change the Portal realm name to match the one used in IBM Connections.

    1. In the WebSphere Application Server Integrated Solutions Console, change the realm name. For example, from defaultWIMFileBasedRealm to AD.cn.ibm.com:389.

    2. Configure Portal to use the new realm name as the default realm:

      1. Use a text editor to open the wkplc.properties file, located in the <wp_profile_root>/ConfigEngine/properties directory.

      2. For defaultRealmName, type the realmName property value you want to use as the default realm.

      3. Save your changes to the wkplc.properties file.

      4. Run the following task from the <wp_profile_root>/ConfigEngine directory, to set this realm as the default realm:

        ./ConfigEngine.sh wp-default-realm -DWasPassword=password

      5. Stop and restart all necessary servers to propagate your changes.

    3. The default Portal administrator user ID is a file-based user ID which is unlikely to exist in your IBM Connections realm. Follow these steps to change the WAS/Portal administrator user ID to an available user ID in the IBM Connections realm.

      1. Run the following command from the <wp_profile_root>/ConfigEngine directory, to replace the existing WebSphere Application Server administrative user ID and group ID with the new user and group.

        ./ConfigEngine.sh wp-change-was-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        You must provide the full distinguished name (DN) for the newAdminId and newAdminGroupId parameters.

        The task is intended to run against a running server. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to skip the validation.

      2. Verify the task completed successfully. In a clustered environment, restart the deployment manager, the node agent(s), and WebSphere Portal servers. In a standalone environment, restart the server and WebSphere Portal servers.

      3. Run this task to replace the old WebSphere Portal administrative user ID and group ID with the new user and group:

        ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

        You must provide the full distinguished name (DN) for the newAdminId and newAdminGroupId parameters.

        The task is intended to run against a running server. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to skip the validation.


    Enable basic authentication

    Configure basic authentication for the IBM Connections portlets. Use basic authentication if you are not using single sign-on for authentication.

    Configure basic authentication allows the manual entry of user credentials in the personalize mode of the portlets. Basic authentication for the portlets is only supported if single sign-on is not already enabled between WebSphere Portal and IBM Connections. If single sign-on is enabled, the basic authentication credentials entered in the personalize mode of the portlets will be ignored.

    When using basic authentication for the portlets, every user must type in their personal credentials manually in the personalize mode of the portlets or shared credentials can be supplied from the Credential Vault.

    If a user changes a valid user ID and password, the user must log out of Portal and log in again to refresh the credentials. If a user enters credential incorrectly, or updates an expired password, logging out and logging back in is not required.

    1. Set the authenticationMethod property to basicAuth in the file \WEB-INF\lcaccelerator\properties\lcaccelerator.properties in the deployed portlets war.

    2. Make sure your changes are applied to all cluster members. Apply changes in the WAR file, redeploy the WAR and synchronize the changes to all cluster members from the WebSphere deployment manager.

    3. If making changes directly to deployed applications, after saving the file, restart the portlets application or the application server(s).


    What to do next

    After you configure basic authentication, you can enable the portlets in one of the following ways:

    • End users can log into portlets using the Personalize mode.

    • The Portal administrator can configure the portlets using the credential slot

    To configure the portlets through a system slot:

    1. In Portal Server Administration choose Administration > Access > Credential Vault.

    2. Click Add a vault slot.

    3. Choose a vault and vault segment from select dropdown.

    4. Choose a vault resource to associate with the system slot. If no vault resource is associated with the vault slot, create a new vault resource.

    5. Enter a vault slot name. This is the name that is seen in the configuration mode of the portlets.

    6. Check Vault Slot is shared.

    7. Enter a shared user ID and password to be stored in the system slot.

    8. (Optional) For Portal 8, the ADMIN_SLOTS virtual resource requires access permissions. Assign ADMIN_SLOTS "All Authenticated users" permissions. The ADMIN_SLOTS can be found under the virtual resource in the Resources Permissions Portlet

    The settings on the personalize mode of the portlets will override the settings in configuration mode. To enable the personalize mode in the portlets, the Portal administrator must perform step 1 and enable basic authentication.


    Update the portlet theme

    Update the theme profile for the Connections portlets to functions properly.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 refresh to use this feature. If you are deploying on WebSphere Portal 7.0.0.2, this assumes you have deployed the fast theme, as described in this wiki article.

    By design. the default themes for Portal 7.0.0.2 and Portal 8.0 do not load Dojo in view mode. This helps to render the theme faster. Because the Connections portlets use Dojo capabilities, you must update the default theme profile for the server you are using. If you do not, the Connections portlets will not work.

    If you do not deploy these modules, you can still deploy and configure the Connections portlets on a Portal 7 server, but some features will not work as expected. You will not be able to deploy and configure the Connections portlets on a Portal 8 server. An error will warn you that the modules are missing.

    1. Follow the steps in this article to add the following modules to the default theme profile (profile_deferred.json): Portal 7.0.0.2:

      • wp_liveobject_framework

      • dijit_form_16

      • dijit_theme_tundra_16
      Portal 8.0:

      • wp_liveobject_framework

      • dijit_form_17

      if you are using a custom profile, add the modules to that profile.

    2. Stop and restart the Portal server.

    3. To specify a theme profile at the page level you can override the default theme. For example, if the theme is using the profile_deferred.json profile, you can specify a custom profile for specific portal pages. Follow the steps for Set a profile override on a page.


    Install the IBM Connections Portlets for IBM WebSphere Portal

    Install the IBM Connections Portlets for IBM WebSphere Portal.

    Use the portlets, you can access only those IBM Connections offerings that you have already installed and configured.

    If you are installing the 3.0.1.1 version of IBM Connections Portlets for IBMWebSphere Portal, you must uninstall any previous versions of the portlets before you install. Upgrading from previous versions is not supported.

    If you want to enable LTPA single sign-on between an IBM Connections feature and a WebSphere Application Server configured for stand-alone LDAP, complete the steps to enable single-sign on before beginning this procedure in the topic Configuring single sign-on.

    When Single Sign-On is enabled between Portal and Connections, the Portal administrator who installs and configures the IBM Connections portlets should be a valid Connections user. For example the user you assign to manage the Virtual Member Manager, as described in the topic Set up an authentication alias for the IBM Connections portlets, can be made a Portal administrator following the steps in this topic. You can also create a Connections profile for the default Portal administrator in the IBM Connections profiles database by following the steps in the topic Add LDAP data to the Profiles database.

    Anonymous Portal users can access the IBM Connections portlets and are treated as anonymous Connections users. However, authenticated Portal users must also be valid Connections users or they will get an error when trying to access a Connections portlet.

    1. Download the plug-in from the IBM Connections catalog at the following web site:

      https://greenhouse.lotus.com/catalog.

    2. From your browser, log into IBM WebSphere Portal as an administrator. If the Portal server is part of a cluster, perform the installation on the primary node. If the server is stand-alone, use the Portal URL for the server. For example, http://HOST:10039/wps/portal.

    3. Click Administration > Portlet Management > Web Modules.

    4. Click Install.

    5. Extract the files from the snor.pf.portlets.zip file that you downloaded from the plug-in catalog.

    6. Browse to snor.pf.portlets.war.

    7. Click Next.

    8. Click Finish.

      Under certain conditions, completing the installation results in the error message Lost track of the selected WAR file from the Browse button. Make sure it is on the disk and try again. If you encounter this error, see this solution on the IBM Support Portal for instructions on how to resolve the problem.

    9. Verify the portlets are successfully installed.


    What to do next

    After installing the portlets, do the following:

    • Copy the Piece of Content (PoC) handler jar file ( com.ibm.lconn.lcaccelerator.poc.jar ) from <portlet install zip>/POCResolver to <PortalServer>/shared/app. You will need this file to establish communication between the portlets.

    • Copy the jar file in the REP folder (com.ibm.lconn.lcaccelerator.rep.jar) from <portlet install zip>/REP to the <PortalServer>/shared/app directory.

    • If your Portal server is deployed on a cluster, copy each jar to the Portal nodes.


    Configure the portlets on a page

    Configure the IBM Connections portlets on a WebSphere Portal page.

    Restriction: Do not place multiple instances of the same portlet on a page. For example, putting two blog portlets on a page might result in unexpected behavior and is not supported.

    IBM Connections portlets may be configured on multiple pages with different filtering and display options. Community Pages (see Community Pages) affect portlets configured on those pages. By default, IBM Connections portlets placed on a community page filter the user's view to display content from that community. A link to a piece of content from a community resolves to a community page if there is an appropriate portlet to display the content on a matching community page. For example, if the Blogs portlet is configured on a "New Employees" community page, the page renders a link in WebSphere Portal to blog entries from that community (see Addressing IBM Connections content). If an appropriate community page is not found, links to the content in WebSphere Portal use a set of default pages to display IBM Connections content.

    You can organize these pages any way you like and can even hide them from your Portal site's main navigation so that users can not directly navigate to them. The following procedure creates one page for each service under a label named "IBM Connections" under the pre-defined "Home" page in WebSphere Portal. You can move the Connections pages or create them elsewhere in your WebSphere Portal site structure. It is only important that the unique names for these pages remain the same.

    1. Define a label to contain the default pages.

      1. Define a label to contain the default pages.

      2. Click Administration > Portal User Interface > Manage Pages.

      3. Navigate to the page where you want to add a portlet. For example, navigate to Home.

      4. Click New Label. A label is a container for WebSphere Portal pages that does not itself contain content. Alternatively, create a page if you want to place portlets or content on this page.

      5.  Enter IBM Connections for the title.

      6. Click OK.

    2. Define page unique names that indicate the portal page users are directed to in order to view content from the Connections services. These unique names are used in the Content resolver component that handles the Portal page look up The lookup retrieves the appropriate page when a user selects Connections search results from the WebSphere Portal Search Center, selects items from the Connections summary portlets, or uses the URLs described in the Addressing IBM Connections content section. For each of the rows in the table, do the following:

      1. Define a page for each service to serve as a default page for content of that type.

      2. Click on the IBM Connections label you created in the prior step.

      3. Click New Page, enter the title and unique name and create the page by clicking OK. The are suggested names, but you can modify them for your deployment.

        Table 21. Suggested page and portlet titles

        Page Title Unique Name Portlet Title
        Profiles ibm.conn.profiles  Profiles
        Activities ibm.conn.activities Activities  
        Blogs ibm.conn.blogs Blogs
        Bookmarks ibm.conn.bookmarks Bookmarks
        Forums ibm.conn.forums Forums
        Wikis ibm.conn.wikis  Wikis

        Do not deploy an Activities portlet or a Forums summary portlet on an anonymous page. The portlet page must require users to authenticate.

      4. Optional: You may need to use different unique names than the ones specified. Using different unique names might be useful if you want to deploy multiple detail portlets to the same page, or if you have existing unique names assigned to pages for other reasons. If you do, copy com.ibm.lconn.lcaccelerator.poc.properties from the /POCResolver folder from the location where you extracted the Connections Portlets download package and place the file in <wp_profile>/properties. To override the unique name expected for a specific portlet, edit the property that corresponds to the detail portlet on the page. For example, blogs=blogs.example.page indicates that users should be navigated to this page to view content from Blogs

      5. Optional: Using the com.ibm.lconn.lcaccelerator.poc.properties file from step d, you can also specify an error page. The error page is used if the portlets cannot find an appropriate Portal page to display a piece of content. Use the key error.page in the properties file to indicate the unique name for your error page. The default value of the unique name of the error page is ibm.conn.navigation.error.

        This error page is used when a page cannot be found to display a piece of content or community, such as when no community page exists for some community but a link to that community is clicked. This might happen from search results if community pages do not exist for all communities.

      6. Optional: Using the com.ibm.lconn.lcaccelerator.poc.properties file from step d, you can also specify a different application ID for the portlet application using the key ibm.conn.portlets.app.id. If not specified, the default value is com.bowstreet.portlet.WebAppRunner2_snor.pf.portlets.

    3. Add portlets to corresponding pages:

      1. Click on the pencil icon (Edit Page Layout) next to a page.

      2. Click Add Portlets.

      3. Set the portlet title in the Search box and click Search.

      4. Select the check box next to the appropriate portlet, then click OK.

      5. Click Done.

    4. Follow these steps to give users access to the page.

      1. Navigate to Administration > Access > Resource Permission > Pages > Content Root. Navigate to the first page that contains an IBM Connections Portlet.

      2. Click the Assign Access button for the entry. For example, to allow non-admin users to access the portlets, set the role "Privileged User" to "All authenticated users." To allow anonymous access, set the role "User" to "Anonymous Portal User."

      3. Click on Apply and then Done.

      4. Repeat Steps a-d for each page that contains an IBM Connections Portlet.

      Page access may be inherited. If page access is not inherited in your site structure, click on the key icon (Edit access) next to each page and add at least user access for each user or group that will need to view Connections content in WebSphere Portal.

    5. Follow these steps to give users access to the portlets.

      1. Navigate to Administration > Access > Resource Permission > Portlet Applications.

      2. Search for com.bowstreet.portlet.WebAppRunner2_snor.pf.portlets or the name of the portlet application if you have customized.

      3. Click Assign Access for the entry and assign users, groups or virtual groups to the portlet application. For example, to allow non-admin users to access the portlets, set the role Privileged User to All authenticated users.

        You may use groups other than all authenticated users if you want only a subset of site users to access the Connections portlets. Even if a user cannot access the portlets directly, the user may be able to access Connections content through service APIs from IBM Connections and WebSphere Portal and via other interfaces including but not limited to search and mobile clients. If you do not want a user to use Connections or see certain Connections content, set up Connections security on the Connections server to exclude that user.

      4. To allow anonymous access, set the role User to Anonymous Portal User.

      5. Click on Apply and then Done.


    Set public render parameter-sharing for the IBM Connections portlets

    If you are using the 3.0.1.1. Version of the IBM Connections portlets, you can set public render parameter sharing for the IBM Connections Portlets. These parameters communicate what content to render when navigating between portlets and from IBM Connections content accessed from the search center portlet.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 to use this feature.

    The IBM Connections detail portlets use public render parameters to communicate what content to render when navigating between the portlets and from IBM Connections content accessed from the Search Center portlet. The default sharing scope for all public render parameters is the global scope. To prevent sharing of public render parameters between pages and to avoid undesirable behavior in rendering content in the portlets, define a unique scope for each page that contains an IBM Connections detail portlet.

    For information on defining scopes for public render parameters, see this article on Public Render parameters in the IBM WebSphere Portal wiki.


    Configure the application-specific AJAX proxy to support authentication

    Configure the application-specific AJAX proxy to manage authentication for the IBM Connections portlets.

    IBM Connections portlets now use an application-specific AJAX proxy as the mechanism for forwarding security headers and cookies with each REST service call to authenticate the request with the Connections server. You can configure the AJAX Proxy to forward LTPA token and the appropriate headers for an environment configured to use a Tivoli Access Manager or SiteMinder security proxy.

    This task presents the steps to enable the default setting to forward the LTPA. For more information on configuring a proxy, see the following articles in the IBM WebSphere Portal product documentation:

    If you use customized cookie names for single sign-on (this is not common), refer to the WebSphere Portal documentation for altering AJAX proxy policies to include additional cookies.

    You must list the IBM Connections server to be accessed as an allowed request target in the AJAX proxy configuration. The recommended way of enabling this access is to map the URL pattern for the IBM Connections server to ibm_connections_policy dynamic policy using the WP ConfigService configuration service.

    1. List the IBM Connections server you plan to access as an allowed request target in the AJAX proxy configuration. The recommended way of enabling this access is to map the URL pattern for the Lotus Connections server to ibm_connections_policy dynamic policy using the WP ConfigService configuration service.

      1. Log into the WebSphere Application Server Integrated Solutions Console.

      2. Navigate to Resources > Resource Environment > Resource Environment Providers.

      3. Click WP ConfigService.

      4. Under Additional Properties, click Custom Properties.

      5. Click New, and enter the property name wp.proxy.config.urlreplacement.ibm_connections_policy.default.connections.server.http, and set the string value to the HTTP URL pattern of the IBM Connections server. For example:

        http://connections_hostname:http_port_number/*

      6. Click New, and enter the property name wp.proxy.config.urlreplacement.ibm_connections_policy.default.connections.server.https and set the string value to the HTTPS URL pattern of the IBM Connections server.

        https://connections_hostname:https_port_number/*

      7. Save the property changes.

    2. Map the security roles for everyone and all authenticated users on the proxy servlet.

      1. Log into the WebSphere Application Server Integrated Solutions Console.

      2. Navigate to Applications > Application Types > WebSphere enterprise applications.

      3. Click PA_WPF or the name of your portlet Web application if you changed the name.

      4. Click Security role to user/group mapping.

      5. Check Everyone Role and click Map Special Subjects > Everyone.

      6. Check All Role and click Map Special Subjects > All Authenticated in Application.s Realms.

      7. Click OK.

      8. Save the changes.

    3. Restart the WebSphere Portal Server.

      The URL patterns used in this step must match those used in the topic Configuring WebSphere environment variables.


    What to do next

    Use the following test URLs to verify that the application-specific proxy configuration is working.

    If you are in an SSO environment you must first open a new browser window and log into Portal as a Connections user.

    • If you have a web server configured for Portal as well as Connections, use: http://<WP_Server>/wps/<CONNECTIONS_PORTLETS_CONTEXT_ROOT>/proxy/https/<CONNECTIONS_SERVER_BASE_URL>/profiles/atom/profileService.do

      For example http://myportalwebserver/wps/PA_WPF/proxy/https/myconnectionswebserver/profiles/atom/profileService.do

    • If you have a web server configured for Connections but not for Portal, use: http://<WP_Server:Port>/wps/<CONNECTIONS_PORTLETS_CONTEXT_ROOT>/proxy/https/<CONNECTIONS_SERVER_BASE_URL>/profiles/atom/profileService.do

      For example http://myportalserver:10039/wps/PA_WPF/proxy/https/myconnectionswebserver/profiles/atom/profileService.do

    • If you do not have web servers configured for either Portal or Connections, use: http://<WP_Server:Port>/wps/<CONNECTIONS_PORTLETS_CONTEXT_ROOT>/proxy/https/<CONNECTIONS_SERVER_BASE_URL:port>/profiles/atom/profileService.do

      For example http://myportalserver:10039/wps/PA_WPF/proxy/https/myconnectionsserver:9444/profiles/atom/profileService.do

    In an SSO environment:

    • If you are prompted to save or open a document or a feed renders in the browser, then the proxy has been properly configured.

    • If you are prompted to enter a user name and password, then the proxy has been properly configured but SSO is not enabled.

    • If you receive a 403 error in response then the proxy is not properly configured.

    • If you receive a 500 or any other response code, this means the proxy was properly configured but something else is not working.

    In a non-SSO environment:

    • Enter the user name and password of a Connections user.

    • If you are prompted to save or open a document or a feed renders in the browser, then the proxy has been properly configured

    • If you receive a 403 error in response then the proxy is not properly configured.

    • If you receive a 500 or any other response code, this means the proxy was properly configured but something else is not working.

    If you receive a 404 or Page Not Found error, check the context root of the Connections portlets. If you have other Web Experience Factory portlets installed, you might need to change from PA_WPF to PA_WPF_1 or PA_WPF_X where X is some number.


    Uninstall the IBM Connections portlets

    OPTIONAL: If you no longer want the Portlets installed, you can remove them from IBM WebSphere Portal. For information on uninstalling portlets, see the following topic in the IBM WebSphere Portal information center: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/admin/adpltadmwork.html.

    If you are removing all of the IBM Connections portlets, you will remove the snor.pf.portlets.war file installed as part of the deployment.


    Optional and recommended configuration

    Depending on your deployment, follow these steps to optimize the IBM Connections portlets.

    The following are some optional configuration steps you can take to enhance the deployment of IBM Connections portlets for IBM WebSphere Portal.


    Community Pages

    In 3.0.1.1, you can integrate Connections Communities into your Portal site to enhance your portal's social collaboration capabilities.

    You integrate Communities by associating a set of portal pages with a community. These types of portal pages are called Community Pages. By associating a set of portal pages with a community in Connections, all of the Connections portlets on those pages will automatically render their content within the context of that Community. One or more communities can be integrated into your portal site. You can associate different sets of pages in your portal site with the appropriate community. The community can be public, moderated or private.

    Before you add portlets to a community page, make sure that the corresponding widget exists in the community. For example, before you add a Blogs portlet to a community page, make sure the IBM Connections community contains a blog. If not, add the Blogs widget to the IBM Connections community using the browser interface.

    Restriction: Ideation blogs are not supported for community pages. If your IBM Connections community contains an Ideation blog widget, it will not display if the Blogs portlet is deployed on a community page.

    Some of the ways the portlets on a Portal community page interact with an IBM Connections community include:

    • Clicking on a profile user name or photo in a Profiles summary portlet displays profile detail in the target portlet.

    • Clicking on a View all link in a Profiles summary portlet displays a list of community members in the target portlet. Note that this link only works if there is a Profiles detail portlet on the page.

    • Clicking the View all link in a Blogs summary portlet displays all entries in a community blog in the Blogs detail portlet on a community page.

    • Clicking on the entry in a Blogs summary portlet displays the detail of that entry in the Blogs detail portlet on a community page.

    • When a user hovers over an entry in a Blogs summary portlet, a pop-up displays, with a link allowing a user to read the entry.

    • Clicking Read for an entry in the Blogs summary portlet shows the selected entry details in the Blogs detail portlet.

    Follow the steps for configuring and mapping community pages for your version of IBM WebSphere Portal.


    Map a community page to a community

    Map a community page to an IBM Connections community so the portlets can interact with community content.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 to use this feature.

    Follow the steps to map the community pages to a community based on what WebSphere Portal Server you are using.

    1. To map community pages to a community on a WebSphere Portal 7 server:

      1. Log into Portal as an administrator.

      2. Navigate to the page to map to a community.

      3. Click Actions > Edit Page Properties.

      4. Expand the Advanced options section and click I want to set parameters.

      5. Add the following new parameters:

        Parameter Key Parameter Value
        ibm.community.id The ID of the connections community. To get this value, open the Connections community in a browser and copy the ID following communityUid= in the community URL.
        ibm.community.home Set to TRUE if the page is identified as the home page for the community. There can be only one home page. In the case where there are multiple homepages set, the first page is selected.
        ibm.community.page Set to FALSE if this is the home page; otherwise, set to TRUE.

        If you are creating a page which has a parent page that is mapped to a community, follow steps c and d , but you must explicitly set the parameters set in step e. To do this, click the Edit icon for each parameter, click OK, then explicitly set the parameters.

    2. To map community pages to a community on a WebSphere Portal 8 server, create a community association using the XML configuration interface (xmlaccess command). When defining the association in the XML import file, use the <content-mapping-info> element, and specify a content mapping scope of ibm.connections for an individual nested <content-mapping> element. For details and an example, refer to the topic on Manage community associations in the WebSphere Portal product wiki.

    3. Assign access to the page. If the community has restricted membership, you can secure the page so that only members of the community can see the page in the Portal navigation. You can also access assign on community pages mapped to public or moderated communities, but doing so does not restrict access to the content in the community. There are other mechanisms, including APIs, mobile clients, connectors and search and portlets on other pages which may expose the content outside the community page. Membership lists in Connections communities should have the correct level of access to community content and Portal pages should reflect that level . Before you use communities for access control on pages, follow the steps in Integrating community membership with Portal security.

      1. Navigate to Administration > Manage Pages and find the community page for which you want to set access.

      2. Click Set Page Permission (lock icon).

      3. Uncheck Allow Inheritance for all rows and click Apply.

      4. Click on the Edit Role button in the Privileged User and User columns and make sure no users or groups are added that you do not want to access this page.

      5. Click on the Edit Role button in the Privileged User or User column, depending on what level of access you want to grant to community members. See the Roles topic for a description of roles in WebSphere Portal.

      6. Click Add.

      7. Change Search by to displayName.

      8. Enter the name of the community in the search box and click Search.

      9. Check the box next to the group representing the community and click OK. If successful, the group appears in the list of members in the role and a message indicates that the members were successfully added to the role.

    4. Before adding portlets to your community page, make sure that the corresponding widget exists in the community. For example, before you add a Blogs portlet to the community page, make sure the IBM Connections community contains a blog. If not, add the Blogs widget to the IBM Connections community using the browser interface.


    What to do next

    If the portal administrator configures a portlet with a new connections server URL for a community page, then the changes will take effect only after the community page is configured with a valid community ID for the new connections server, by editing the portal page parameters settings to include the new community ID.


    Integrate community membership with Portal security

    Configure the Virtual Member Manager to integrate information from IBM Connections communities with your WebSphere Portal environment.

    Starting with version 6.1, IBM WebSphere Application Server uses a component called Virtual Member Manager (VMM) to manage information about community membership. VMM provides an interface that enables communication between WebSphere Portal and any repository, whether federated repositories, a stand-alone repository, or your own custom user registry. You can configure VMM to recognize IBM Connections as a repository so that Portal can access community user and group information from IBM Connections communities. For example, once this is configured, users will be able to select IBM Connections private or public communities as groups when assigning security roles or access rights.

    For more information about the architecture of VMM, see this article from the IBM WebSphere Portal wiki.

    For more information about configuring a user repository for VMM, see this white paper from IBM Developer Works.

    After configuring IBM Connections to work with VMM, user can:

    • Search for IBM Connections public and private communities by name (represented as groups in WebSphere)

    • Resolve public and private community membership for particular users (represented as group membership in WebSphere)

    • Display the WebSphere users that are members of a particular IBM Connections public or private community

    The following are some known limitations:

    • When using the VMM get operation to get a single identifier and querying by name, instead of using the unique externalID, nothing will be returned if more than one community name matches the query.

    • The operation to display WebSphere users that are members of a particular IBM Connections community can have a perfromance impact for large groups.

    • Tivoli Directory Integrator is recommended for populating user data into Connections. When using the profile data population wizard, a user's email may not be populated into the Communities database. Consequently, a user may not appear in the proper communities until they have logged into Communities, used a feature from the Communities service, or their profile has been synchronized with Tivoli Directory Integrator.


    Prerequisites

    In order to configure the VMM to recognize an IBM Connections repository, the following must be true:

    • IBM WebSphere Portal must be completely installed and verified

    • IBM Connections must be completely installed and Search has to be verified to work

    • IBM Connections must have email enabled if you are using IBM Connections Portlets for Portal 3.0.1.1. If you have upgrade to the 3.0.1.1 refresh, you do not need to have email enabled. Hidden email is supported.

    • Single sign-on should be configured between Connections and Portal. Follow the steps in Configuring single sign-on.

    • IBM Connections and WebSphere Portal must share a common LDAP.

    • Import the SSL certificate from WebSphere Portal server to IBM Connections. Follow the steps in Importing a certificate to support SSL with the following differences:

      • Log into the WebSphere Application Server Integrated Solutions Console for the Connections server, rather than the Portal server.

      • Enter the host, port and alias for the Portal server. For example:

        Host : portal.example.com
        Port : 10025 (SOAP default port on Portal. Please specify appropriate port if non default is used)
        Alias : Portal Certificate (Admin can choose any appropriate alias)

    • If you are deploying on WebSphere Portal 7.0.0.2, install Fixpack PM51981 to avoid problems with private community pages. You can download the Fixpack from Fix Central.

    • Update the VMM schema so that PersonAccount includes ibm-entryUuid <personCorrelationAttribute>. To open the scripting interface , refer to "Opening a console window for interactive scripting" in this article. In the scripting interface , enter the following commands

      $AdminTask addIdMgrPropertyToEntityTypes {-name ibm-entryUuid -dataType string -entityTypeNames PersonAccount} $AdminConfig save

      Portal must be running while you execute this command. Restart the server to apply the changes.


    Configure the IBM Connections repository to work with VMM

    Complete these tasks to configure the IBM Connections User Repository Adapter. When configuration is complete, you can verify that it is working by logging in to WebSphere Portal as an administrator. Open the Users and Groups portlet from the Administration tab. Search for groups that should be present as communities in your IBM Connections deployment. If you find the correct groups and the members of the groups are listed, the deployment is successful.


    Deploying libraries for the IBM Connections portlets

    Deploy libraries required to integrate information from IBM Connections profiles and communities with your WebSphere Portal environment.

    Follow these steps for deploying libraries.

    In a cluster environment, copy libraries on the Deployment Manager and on every node.

    1. For Portal 7.0.0.2 with a separate Deployment Manager:

      • Copy jars from CommunitiesVMM/vmmAdapterMain to AppServer/lib/ext directory

      • Copy jars from CommunitiesVMM/vmmAdapterFilter to PortalServer/shared/app

    2. For Portal server 6.1.5.3 with a separate Deployment Manager:

      • Copy jars from CommunitiesVMM/vmmAdapterMain to AppServer/lib/ext directory

      • Copy jars from CommunitiesVMM//vmmAdapterPortal6AdditionalLibs to AppServer/lib/ext directory

      • Copy jars from CommunitiesVMM/vmmAdapterFilter to PortalServer/shared/app

      For Portal nodes, follow the steps for separate Deployment Manager, even if a common Deployment Manager is configured.

    3. For Portal server 7.0.0.2 with a common Deployment Manager, copy jars as follows on the Connections and Deployment Manager nodes:

      • AppServer/lib/ext:

        • com.ibm.ws.wim.adapter.base.jar [location: CommunitiesVMM/vmmAdapterMain]

        • com.ibm.ws.wim.adapter.connections-forwarding.jar [location: CommunitiesVMM/vmmAdapterForwarding]

      • AppServer/lib/ext/vmm:

        You must manually create the vmm directory.

        • Jars from CommunitiesVMM/vmmAdapterMain [exclude: com.ibm.ws.wim.adapter.base.jar ]

      • PortalServer/shared/app

        • Jars from CommunitiesVMM/vmmAdapterFilter to PortalServer/shared/app

    4. For Portal server 6.1.5.3 with a common Deployment Manager, copy jars as follows on the Connections and Deployment Manager nodes:

        • AppServer/lib/ext:

          • com.ibm.ws.wim.adapter.base.jar [location: CommunitiesVMM/vmmAdapterMain]

          • com.ibm.ws.wim.adapter.connections-forwarding.jar [location: CommunitiesVMM/vmmAdapterForwarding]

        • AppServer/lib/ext/vmm:

          You must manually create the vmm directory.

          1. Jars from CommunitiesVMM/vmmAdapterMain [exclude: com.ibm.ws.wim.adapter.base.jar ] -

          2. Jars from CommunitiesVMM//vmmAdapterPortal6AdditionalLibs

      • PortalServer/shared/app

        • Jars from CommunitiesVMM/vmmAdapterFilter


    Configure a Resource Environment Provider for IBM Connections portlets

    You must add IBM Connections server URLs to the WebSphere Resource Environment provider before you can add an IBM Connections repository to the Virtual Member Manager.

    Copy the com.ibm.ws.wim.adapter.connections.filter.jar file to the \\Portalserver\shared\app folder.

    Ensure you have followed the previous steps in Deploying libraries for the IBM Connections portlets before performing this configuration or your server may fail to start after setting these parameters.

    Add any allowed IBM Connections server URLs. For example, if the server allows http and https URLs, add both.

    1. Log into the WebSphere Application Server Integrated Solutions Console.

    2. Navigate to Resources > Resource Environment > Resource Environment Providers.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. If the WP ConnectionsIntegrationService already exists, click on it. If not, click New, specify WP ConnectionsIntegrationService, and click Apply.

    5. Click Custom Properties.

    6. Click New and configure the following attributes:

      Name Description Type

      personCorrelationAttribute (formerly personRdnAttribute) Set the corresponding person relative distinguished name attribute. In case the personCorrelationAttribute is of type uniqueId, its value should be the ldap attribute which is mapped to the Profile Database field that represents the unique id. For example, if the unique id is represented by the guid profile database field, and this field is mapped to the ibm-entryUuid LDAP attribute, then use ibm-entryUuid as the value for the personCorrelationAttribute. java.lang.String

      personCorrelationAttributeType Assign a value of mail or uniqueId to specify whether the correlation attribute represents an email address or unique identifier. java.lang.String

      communityRdnAttribute Set the corresponding community relative distinguished name attribute. For example, cn. java.lang.String

      maxSearchResults A maximum of results the connections repository will return on a single query. For example, 120. java.lang.String

      J2CAuthAlias The auth alias name as noted in Step Authentication Alias Configuration. For example, cell/dsxAdmin java.lang.String

      ldapTypeTDS Specify True if you are using TDS as your LDAP, or specify False if you are using a different LDAP, for example, Microsoft ADS or Novell DS java.lang.String

      mailProperties (No longer needed. Maintained for backward compatibility.) Specify all possible mail properties. For example, mail,ibm-primaryEmail java.lang.String

    7. Optional: Optionally alter the default cache settings and add these to the configuration of the environment variable you configured in the topic Configuring the resource environment provider as part of the installation process. If a user is added to a community through the IBM Connections user interface, the user may need to wait for caches to time out before seeing private community pages or other effects of joining the community in WebSphere Portal. IBM Connections uses three different caches:

      • Communities: caches communities from IBM Connections based on the unique ID

      • Members: caches members of a community from IBM Connections based on the unique ID

      • Entities: caches repository entities (either group or person) based on their unique ID
      The possible configuration options are:

      Name Type Default

      communitiesCache.size java.lang.String 1024

      communitiesCache.lifetime java.lang.String 600

      membersCache.size java.lang.String 1024

      membersCache.lifetime java.lang.String 600

      entitiesCache.size java.lang.String 1024

      entitiesCache.lifetime java.lang.String 86400

      All lifetime values are specified in seconds. The cache size indicates number of elements.

    8. Save the new settings.


    What to do next

    Stop the server so that you can deploy the libraries and make changes to the XML configuration files.


    Configure for impersonation: protecting user access

    The impersonation feature lets you access another user's system as though you are that user so that you can test user access. .

    If you haven.t already done so, copy the com.ibm.ws.wim.adapter.connections.filter.jar file to the \\Portalserver\shared\app folder.

    Ensure you have followed the steps in Deploying libraries for the IBM Connections portlets before performing this configuration or your server may fail to start after setting these parameters. The impersonation feature lets you access another user's system as though you are that user.

    1. Log into the WebSphere Application Server Integrated Solutions Console.

    2. Navigate to Resources > Resource Environment > Resource Environment Providers.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. If the WP ConnectionsIntegrationService already exists, click on it. If not, click New, specify WP ConnectionsIntegrationService, and click Apply.

    5. Click Custom Properties.

    6. Configure the following attributes:

      Name Description Comment

      runAsAdmin false Values are true or false. The default is false. This attribute determines if adapter runs in admin mode or non admin In admin mode, whenever any (admin/non admin) logged-in user looks up a community, the user sees all communities from the Connections server. In non-admin mode, logged-in users will see only those communities which they have explicitly joined.

    7. Navigate to Resource Environment > Resource Environment Providers.

    8. Select All as the scope.

    9. Click WP PumaStoreService. You might need to page through results or apply a filter.

    10. Click Custom Properties.

    11. Click New and configure the following attributes:

      Name Description Type

      store.puma_default.filter.principalFilter.classname com.ibm.connections.vmm.adapter.filter.VMMPrincipalFilter .

      Make sure you specify the class name or you will get errors when starting up Portal.

      java.lang.String

      store.puma_default.filter.principalFilter.position 120 java.lang.String

    12. Restart the IBM Connections portlets application from the WebSphere Application Server console or restart the Portal server.


    What to do next

    To verify that impersonation is configured correctly:

    1. Login as any non-admin user

    2. Create a page, for example, JonesxxPage.

    3. Click Actions > Share page.

    4. Select Group search from drop down

    5. Enter a search string and verify that the results come from communities the user belongs to rather than from all communities.

    6. Perform a similar test for each node.


    Configure the IBM Connections repository for VMM

    This task is done when the server is stopped. In a cluster, you can change the configuration files directly on the deployment manager and then synchronize the changes to all cluster nodes. The wimconfig.xml file governs a single ID attribute for all supported objects such as users, groups, and organizations in WebSphere Application Server. You can use LotusConnections-config.xml to override the ID attribute in the wimconfig.xml file. For example, you could use the wimconfig.xml file to specify the ibm-entryUUID attribute as the ID Key attribute for users and groups in all applications running on WebSphere Application Server, and then modify LotusConnections-config.xml to specify the employeeID as the ID Key attribute for IBM Connections applications.

    1. Add the repository configuration to the wimconfig.xml in the<profile_directory>/config/cells/local.cell/wim/config directory. Insert the following lines below the config:configurationProvider level:

      <!-- Connections Repositories -->
      
      <config:repositories adapterClassName="com.ibm.ws.wim.adapter.connections.ConnectionsAdapter"
              id="connections" isExtIdUnique="true" supportExternalName="false"
              supportPaging="false" supportSorting="false" supportTransactions="false">
            <config:baseEntries name="o=connections" nameInRepository="o=connections"/>
          </config:repositories>
      
      <!-- Connections Repositories End -->

    2. The same base entry must also be added to the default realm, and optionally, to all the user realms that contain softgroups: The base entry specification defines the base distinguished name/suffix for the connections communities inside VMM and may be set to a different value. The name and the nameInRepository should be the same. The same base entry must also be added to all the user realms that should contain softgroups, at least the default realm:

      <config:realmConfiguration defaultRealm="defaultWIMFileBasedRealm">
            <config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active">
              <config:participatingBaseEntries name="o=defaultWIMFileBasedRealm"/>
              <config:participatingBaseEntries name="o=connections"/>
              <config:uniqueUserIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
              <config:userSecurityNameMapping propertyForInput="principalName" propertyForOutput="principalName"/>
              <config:userDisplayNameMapping propertyForInput="principalName" propertyForOutput="principalName"/>
              <config:uniqueGroupIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
              <config:groupSecurityNameMapping propertyForInput="cn" propertyForOutput="cn"/>
              <config:groupDisplayNameMapping propertyForInput="cn" propertyForOutput="cn"/>
            </config:realms>
          </config:realmConfiguration>

    3. For the other configured repositories such as the main LDAP repository, add the Connections repository as a group repository with the following line:

      ...
      <config:repositoriesForGroups>connections</config:repositoriesForGroups>
      ...


    What to do next

    To verify that the adapters started correctly, do the following:

    1. Look for the following type of informational message in the SystemOut.log:

      ConnectionsLo I   CLVPA0006I: Successfully initialized Connections Lookaside Adapter for IBM Connections Profiles
                        (implementation version = 1.0.0, build date = 2011/02/02 23:44:24)
      ConnectionsAd I   CLVCG0005I: Successfully initialized Connections Adapter for IBM Connections Communities
                        (implementation version = 1.0.0, build date = 2011/02/02 23:44:24)
      If there are warning messages, such as:

      ConnectionsLo W   CLVPA0005W: Could not access IBM Connections Communities server with the given URL https://connections-server:9449/communities!
                        Reason = ...
      verify that the IBM Connections server is started and available from the Application Server with the given URL and credentials.

    2. Log in to WebSphere Portal as administrator and open the Users and Groups portlet from the Administration tab. Search for groups that should be present as communities in the IBM Connections installation. The adapter is working if you can confirm that the correct groups are listed and the members of the groups are also listed. If there are groups or members missing, verify the SystemOut.log for error messages. Usually this is a configuration issue (for example, a problem with the name attribute) or the user repository of WebSphere does not contain all the users registered in Profiles.


    Configure search integration

    IBM Connections search integration in IBM Websphere Portal allows users to perform search queries and view query results for IBM Connections content within the context of their portal environment.

    This feature requires the 3.0.1.1 version of IBM Connections Portlets for IBM Websphere Portal.

    This integration point is enabled by configuring the portal search center component to include IBM Connections content as part of the related search results. You also need to configure a component to allow the navigation from the portal search center to the portlets so that users can view the Connections related search results.


    Understand the search architecture

    Portal currently provides the following two search frameworks. The one you use depends on whether you value performance or ease of maintenance.

    • Search Service

      Search Service is a live search and leverages REST (along with other technologies ) to search on a target information source and fetch the matching results. Connections/Portal integration uses the "Remote Content Server Search Service Type" (referred to as RCSS type), leveraging the ATOM/REST APIs exposed by Connections. This approach would tag relevance score of connections content, in isolation, to the portal relevance score. It is a federated approach in which the search is federated between Portal and Connections instances.

    • Search Collections

      Search Collections uses a seedlist framework to crawl and index all of the Connections data locally on a Portal server. The advantage of this approach is that it removes extra network traffic to the Connections server during the search process, making information retrieval fast. One disadvantage is that the crawler needs to run frequently to synchronize local content with all the latest content on the Connections server. It can do a better relevance ranking of search results, as search results (including Portal and Connections) are served by the Portal engine only.

    When you are configuring Search, note the following repositories

    ...where files are stored:

    • Icons ( DisplayProvider/icons ) must be copied to <wp_profile>/installedApps/NODE_NAME/wps.ear/wps.war/images/icons

    • Display provider plug-in (DPP) jar file ( com.ibm.lconn.lcaccelerator.dpp.jar ) from <portlet install zip>/DisplayProvider must be placed in <PortalServer>/shared/app

    • Piece of Content (PoC) handler jar file ( com.ibm.lconn.lcaccelerator.poc.jar ) from <portlet install zip>/POCResolver must be placed in <PortalServer>/shared/app .


    Excluding Connections Portlets from Portal default search indexing

    Exclude the Connections portlets from the default Portal search indexing.

    If you are integrating with WebSphere Portal 8.0, portlets are excluded from portal search by default and you do not need to specifically exclude them.

    By default, on WebSphere Portal 7.0 servers, the Portal search crawler crawls all the portal pages and active portlets lying on them. Since IBM Connections uses its own seedlists for search, you can exclude the Connections portlets from the default portal indexing. The default crawler user is the default Portal admin user. This user might not be a Connections user, so in order to exclude the IBM Connections Portlets from the Portal indexing; this user should not have access to Connections portlets. To achieve this, create a separate group which lists all Connections users who should have access to IBM Connections portlets. Make sure that the crawler user is not part of this group. IBM Connections portlets should be assigned access permission to this group instead of to the 'All Authenticated Portal users group'. This way when the crawler runs, the default portal indexing will exclude IBM Connections portlets.


    Configure search using Remote Content Server Search Service Type (RCSS)

    Use the Remote Content Server Search Service Type (RCSS) to implement live search for IBM Connections content from an IBM WebSphere Portal application.

    Consider these issues before you configure RCSS:

    • RCSS search is not supported when your deployment is configured to use Tivoli Access Manager and SPNEGO or Computer Associates' SiteMinder and SPNEGO.

    • Users who are registered in an LDAP that is common between IBM Connections and WebSphere Portal should be granted administration rights in Portal to configure RCSS using scopes API over http.
    Search Service is a live search and leverages REST to search on a target information source and fetch the matching results. IBM Connections and WebSphere Portal integration uses RCSS to leverage the ATOM/REST APIs exposed by IBM Connections. This approach correlates a relevance score for IBM Connections content with the Portal relevance score. It is a federated approach where the search is federated between Portal and IBM Connections instances.

    1. Click the Administration link in the header of the portal page.

    2. In the Manage Search section, click New Search Service.

    3. Name the service appropriately so that it is easily identifiable, provide this value in the Service Name field.

    4. Configure the search service using the following parameters. Possible values for the parameters are provided in the Parameter Value column.

      Parameter Key Parameter Value
      SearchRequestUrl /atom/search/results
      RestServiceUnSecureUrl /search
      ContentType RemoteContent
      QueryParam includeportalcustomizations=true&query
      IgnoreAllSourcesSearch false
      RestServiceSecureUrl /search
      StartParam start
      AllSourcesParam scope
      QueryLangParam queryLang
      DisplayProviderId ConnRCSS
      RequestLocaleParam locale
      LocationParam scope
      RequestLocationType /atom/scopes

    5. Log out and log in again before creating scopes for the RCSS service you configured.


    What to do next

    Troubleshoot: The RCSS component doesn't use the key store managed by WebSphere Application Server. If you try to set the RestServiceSecureProtocol property to https and the RestServiceSecurePort property to the SSL port for the Connections server when configuring the RCSS search service, you will not be able to retrieve the search scopes from Connections and thus will not be able to complete the search configuration. You will see SSL handshake errors in the WebSphere Portal SystemOut logs even though you imported the Connections SSL certificate into the WebSphere Application Server SSL certificate trust store. If you encounter this problem, follow the additional configuration steps documented in this tech note.


    Configure a search collection

    Search Collections uses a seedlist framework to crawl and index all of the IBM Connections data locally on a WebSphere Portal server.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 to use this feature.

    Ensure these IBM Connections seedlists are available with basic authentication. Depending on your security configuration, this may be the default or may be accomplished with an additional virtual host in your HTTP server, by addressing a WebSphere node directly, or by altering Tivoli Access Manager or SiteMinder configuration to open a basic authentication protected endpoint. To configure a search collection, you specify one content source for each Connections seed list. Each Connections service (for example, Profiles, Communities, or Blogs) exposes its own seed list so there is one content source per Connections service.

    1. Click the Administration link in the header of the portal page.

    2. In the Manage Search section, click Search Collection.

    3. Click New Collection.

    4. Define the location of the collection on the portal file system and name it with an easily identifiable value.

    5. Click OK to create the collection and create the associated folders and files on the file system.

      The path should not point to an existing directory.

    6. Click Collection to view the metadata of the collection created.

    7. Select Seedlist Provider as the Content source type.

    8. Provide the name and the seedlist URL of the Connections service. A Seedlist URL has the form: https://<connection_server_name>:port/<service_name>/seedlist/myserver For example: https://connections.ibm.com:9444/activities/seedlist/myserver.

      If IBM Connections is configured to use Tivoli Access Manager and SPNEGO security, or just SPNEGO, configure the seedlist URL and host without TAM, using IHS host only.

    9. Click the Security tab and enter your Connections administrator credentials, so that you can access the specific service seedlist URL.

    10. Click Create to create the corresponding Content Source to enable crawling over the service defined.

    11. Create other Connections services Activities, Blogs by repeating steps 1 - 10.

      You can either select to run the crawler on the complete set or on individual service

    12. Ensure these seedlists are available with basic authentication. Depending on your security configuration, this may be the default or may be accomplished with an additional virtual host in your HTTP server, by addressing a WebSphere node directly, or by altering Tivoli Access Manager or SiteMinder configuration to open a basic authentication protected endpoint.


    Set the Search Scope

    Define search scopes for the content from IBM Connections that is returned from a search in IBM WebSphere Portal applications. Once the service/collection is defined, search scopes can be optionally defined. This search scope is available to the end user, after the setup and primarily facilitate defining different level of granularity at which the search is executed from the Portal user interface.

    1. Click the Administration link in the header of the portal page.

    2. In the Manage Search section, click on Search Scope.

    3. Click New Scope.

    4. Specify a name for the scope and click Select Location, to select the services and collections to include. This view allows you to mix and match various services and content sources and to define the granularity of the search scope being defined.


    Display action buttons and links for anonymous users

    Edit style sheets to display action buttons and links for anonymous users.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 refresh to use this feature. By default, some action buttons or links in anonymous view, such as Login to Start a Wiki, Login to Start a Forum or Login to Flag as Inappropriate do not display for anonymous users. If you want anonymous users to see these buttons and links, you must edit the style sheets to display the action buttons. After changing the styles in the style sheet, the following actions display in portlets for users who access the portlets anonymously:

    • Wikis . Login to Start a Wiki

    • Forums . Login to Start a Forum

    • Forums . Login to Start a Topic

    • Blogs . Login to Flag as Inappropriate

    1. Open the stylesheet connectionsportlet.css or connectionsportletRTL.css from the lcaccelerator\css folder where the Connections portlets are installed.

    2. For any component to display action buttons for anonymous users, change the attribute display from none to inline. The choices are:

      .activitiesAnonymous{
      	display:none;
      }
      
      .wikisAnonymous{
      	display:none;
      }
      
      .blogsAnonymous{
      	display:none;
      }
      
      .dogearAnonymous{
      	display:none;
      }
      
      .forumsAnonymous{
      	display:none;
      }
      
      .profilesAnonymous{
      	display:none;
      }
      
      .copAnonymous{
      	display:none;


    Conditional Loading of the Lotus CSS bundle

    If you are using 3.0.1.1, load the IBM Connections portlets CSS bundle to properly render the user interfaces for the IBM Connections portlets.

    If you are using the 3.0.1.1 refresh version, disregard this topic. The portlets display correctly using the Portal style sheets. The IBM Connections portlets bundle their own Lotus CSS package containing all of the style definitions and images required to properly render the UI. This CSS package is based on the same CSS package contained in the WebSphere Portal 6.1.5 Page Builder theme. Because of this, the portlet application contains logic to determine whether or not to load the CSS package bundled with the portlets depending on whether or not the theme used by the portal environment has already loaded the Lotus CSS as part of the theme. This is done to avoid loading of duplicate style definitions during page load. Follow these steps to specify a loading option.

    1. Depending on your server configuration, open the lcaccelerator.properties file in an editor as follows:

      • For a Windows-based non-clustered Portal server, open: [portalInstallRoot]\wp_profile\installedApps\[cell]\PA_WPF.ear\snor.pf.portlets.war\WEB-INF\lcaccelerator\properties\lcaccelerator.properties

      • For a Linux/AIX-based non-clustered Portal server, open: [portalInstallRoot]/wp_profile/installedApps/[cell]/PA_WPF.ear/snor.pf.portlets.war/WEB-INF/lcaccelerator/properties/lcaccelerator.properties

      • For a Windows-based clustered portal Server, open the file on each application server node: [portalInstallRoot]\wp_profile\installedApps\[cell]\PA_WPF.ear\snor.pf.portlets.war\WEB-INF\lcaccelerator\properties\lcaccelerator.properties

      • For a Linux/AIX-based clustered portal server, open the file on each application server node: [portalInstallRoot]/wp_profile/installedApps/[cell]/PA_WPF.ear/snor.pf.portlets.war/WEB-INF/lcaccelerator/properties/lcaccelerator.properties

    2. Specify one of the following options for the oneui_css_loadrule configuration setting:

      • oneui_css_loadrule=portal This is the default setting. This setting causes the portlets to not load the bundled Lotus CSS but rely on the portal theme to provide the style definitions.

      • oneui_css_loadrule=portlet This setting causes the portlets to always load the Lotus CSS bundled with the portlets regardless of whether its already available in portal environment or not. This is the suggested option if the portal theme has been heavily customized where a lot of style definitions that the portlets would depend on in the portal theme have been changed. This will ensure that the integrity of the Connections Portlet UI is preserved. This setting also may be used in the scenario where the portlets are deployed in an advanced or back level version of Portal that's not officially supported. In this situation, the newer Portal theme may contain an updated version of the Lotus CSS that's not supported by the Connections Portlets.

    3. Save your changes to the file.


    Configure the Connections business card

    Enable the IBM Connections Business Card so that your users can access Connections data such as a person's profile information. Follow the steps in the

    The IBM Connections business card used by the portlets now supports the configuration where the email address is hidden in IBM Connections. Follow the steps in the IBM WebSphere Portal product documentation for enabling the business card:

    To verify that the IBM Connections Business Card is enabled:

    1. Open one of the Lotus Connections portlets on WebSphere Portal and search for a person.

    2. Hover on the user's name to make sure the business card displays for this user. If not, the Connections business card is not configured properly.


    What to do next

    When the Connections business card is integrated in Portal, it affects the styles of the skin of the portlets. For example, the width of the area where the portlet title is shown is decreased. To resolve this issue, install iFix PM24072 on the Portal server. You can download the Fixpack from Fix Central.


    Configure links to open Connections in the same browser window

    You can configure the portlets so that when a user clicks a Connections link it opens Lotus Connection in the same browser window rather than the default, which is to open in a new window. When you configure the portlets you can enable an option that allows users to access the full IBM Connections application from a portlet. Follow these steps to configure the option to open Connections in the same browser rather than opening a new window.

    1. Open the lcaccelerator.properties file, located at: <portal-profile-home>\installedApps\<node>\PA_WPF.ear\snor.pf.portlets.war\WEB-INF\lcaccelerator\properties.

    2. Set the openExternalLinksInNewWindow property to false.

    3. Save your change and restart WebSphere Portal.


    Enable logging for the portlets

    In order to diagnose and resolve errors that occur with the IBM Connections Portlets, you must enable logging.

    When you configure WebSphere Portal to write the trace and message logging for the Connections portlets, the messages are logged in the trace.log. The file is updated when an error occurs or if trace logs are created. The file is created in the following directory: <portal_server_root>\log. You can enable tracing for each portlet separately. The log classes used for the portlets are as follows:

    Activities portlet:

    • com.ibm.lconn.activities.detail

    • com.ibm.lconn.activities.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Blogs portlet:

    • com.ibm.lconn.blog.detail

    • com.ibm.lconn.blog.summary

    • com.ibm.lconn.blog.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Bookmarks portlet:

    • com.ibm.lconn.dogear.detail

    • com.ibm.lconn.dogear.summary

    • com.ibm.lconn.dogear.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Profiles portlet:

    • com.ibm.lconn.profiles

    • com.ibm.lconn.profiles.summary

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Tags portlet:

    • com.ibm.lconn.tagsi.service

    • com.ibm.lconn.common

    Wikis portlet:

    • com.ibm.lconn.wiki

    • com.ibm.lconn.wiki.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Forums portlet:

    • com.ibm.lconn.forum.detail

    • com.ibm.lconn.forum.summary

    • com.ibm.lconn.forum.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    Community Overview portlet:

    • com.ibm.lconn.communityOverview

    • com.ibm.lconn.communityOverview.service

    • com.ibm.lconn.profiles.service

    • com.ibm.lconn.common

    VMM adapter:

    • com.ibm.ws.wim.adapter.connections.network.*

    • com.ibm.ws.wim.adapter.*

    • com.ibm.connections.vmm.adapter.filter.*

    The recommended logging level is all.

    For additional information on debugging issues with the Virtual Member Manager adapter, see this tech note.

    VMM adapter - Sonata Trace specification for sonata/authentication :

    Connections Server:

    • com.ibm.connections.httpClient.*

    • com.ibm.connections.directory.services.*

    • com.ibm.ws.security.*

    • org.apache.commons.httpclient.*

    • SonataHttpHeader

    • SonataHttpBody

    
    
    
    
    
    
    

    Portal Server:

    • com.ibm.connections.httpClient.*

    • org.apache.commons.httpclient.*

    • SonataHttpHeader

    • SonataHttpBody

    
    
    
    
    
    
    

    The recommended logging level is all.

    Inter-portlet Navigation (Piece of Content handler)

    • com.ibm.lconn.lcaccelerator.search.resolver.*

    The recommended logging level is all.

    Search center portlet (display provider):

    • com.ibm.lconn.lcaccelerator.search.display.*

    The recommended logging level is all.

    Configuration Properties Helper:

    The Configuration Properties Helper retrieves all of the configuration settings from the Resource Environment Provider and makes them available to the portlets.

    com.ibm.lconn.lcaccelerator.profiles.rep.*

    Type-ahead:

    The type-ahead builder is used to manage the members/owners. This uses the directory services to function.

    • com.ibm.connections.directory.services.*

    • com.ibm.connections.httpClient.*

    • com.ibm.websphere.wim.*

    • com.ibm.ws.wim.*

    The recommended logging level is all.

    REST Call logging:

    This will enable logging of details of the REST service calls to a separate log file

    1. Open the file <installed war>\WEB-INF\lcaccelerator\properties\loggerServiceMapping.properties

    2. Set the property TPA_REST_LOG_FLAG to true.

    3. Restart the Application war from the WAS admin console.
    These logs will get generated at <installed war>/WEB-INF/logs/RESTCallLogs.log.
     

    You can specify the following log levels: info, fine, finer, finest, and all. To enable logging for one or more of the Connections portlets, do the following:

    1. Log into WebSphere Portal as the Administrator

    2. Navigate to Administration > Portal Analysis > Enable Tracing .

    3. In the Append these trace settings field, specify the log level for the desired log class and click the add button (+): For example, com.ibm.lconn.activities.summary=fine

    4. Repeat step 3 for each log class to log.

    5. Log out of portal and log back in.


    Example

    For example, if you wanted to enable the finest log level for the Activities Detail portlet, you would add these three logging settings:

    • com.ibm.lconn.activities.detail=finest

    • com.ibm.lconn.activities.service=finest

    • com.ibm.lconn.profiles.service=finest
    If you wanted to enable the fine log level for the Bookmarks Summary portlets, you would add these logging settings:

    • com.ibm.lconn.dogear.summary=fine

    • com.ibm.lconn.dogear.service=fine


    Pinning portlet content to a tag

    Specify a tag to pin for an IBM Connections portlet to show content associated with that tag.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 to use this feature. If you want the content of a portlet scoped to a specific tag, you can set a page parameter to the tag.

    Each portlet can be pinned only to a single tag.

    1. Edit the portal page containing the IBM Connections portlets. For details on editing page parameters, see this Portal wiki article.

    2. Set the page parameter for each portlet to pin to a tag.

      Table 22. Tag pin parameters

      Portlet Parameter
      Activities Detail ibm.tag.pin.activities.detail
      Blogs Detail ibm.tag.pin.blogs.detail
      Blogs Summary ibm.tag.pin.blogs.summary
      Bookmarks Detail ibm.tag.pin.bookmarks.detail
      Bookmarks Summary ibm.tag.pin.bookmarks.summary
      Forums Detail ibm.tag.pin.forum.detail
      Forums Summary There is no page parameter for this portlet. You can set a pin option from the Edit Shared Sets panel.
      Wikis Detail ibm.tag.pin.wikis.detail
      Global Page Pin ibm.tag.pin.all

      Use the global tag pin to specify a common tag to use as a filter for all IBM Connections portlets on the page. Tags you specify for individual portlets override this global tag pin.

    3. Save the page changes.

    4. Log out of WebSphere Portal and then log back in to refresh the portlets so that you can see content pinned to the specified tag.


    Configure and wiring the Tags portlet

    After installing and deploying the IBM Connections portlets, configure and wire the Tags portlet so it works in concert with other portlets in an IBM WebSphere Portal application.

    When you are deploying the Tags portlet, note that if you are also deploying a Bookmarks portlet there is a difference in how tags display. The Bookmarks portlet by default returns active tags for the last 30 days. If this does not match what displays in the Tags portlet you can change the configuration settings for Bookmarks. For example, you can increase the setting from 30 days to 180 days to display more tags. For information on changing the Bookmarks configuration, follow the steps in the topic Changing view and link thresholds and change the value of the sinceWhen.activeTags.

    Follow these steps to configure and wire the IBM Connections Tags portlet.


    Wiring the Tags portlet

    The Tags portlet allows users to view content tagged with the tag selected from the portlet to aid in the discovery of content.

    You should already have added the IBM Connections portlets to a Portal page before you proceed with wiring. The Tags portlet must be deployed on the same page with at least one other IBM Connections portlet. Read How the Tags portlet interacts with the other IBM Connections portlets for information on how the Tags portlet communicates with the other IBM Connections portlets. Follow these steps to wire the Tags portlet to other IBM Connections portlets so that the Tags portlet can filter IBM Connections content displayed in the other IBM Connections portlets.

    Only the detail portlets can be wired to the Tags portlet. The summary portlets cannot be wired to the Tags portlet.

    1. From the Edit Layout page of the page containing the Tags portlet and at least one other IBM Connections detail portlet, click the Wires tab.

    2. Set the following wire(s) from the Tags portlet to the corresponding IBM Connections portlets on the page:

      Source Portlet Send Target Page Target Portlet Receive Wire Type
      Tags Selected Tag {current page} {Blogs|Profiles|Wikis|Bookmarks|Forums|Activities} Selected Tag Public

    3. Click Add.

    4. If you have the Tags portlet deployed on a page with one IBM Connections detail portlet and want the Tags portlet to show tags associated with the view in the details portlet, set the following wire:

      Source Portlet Send Target Page Target Portlet Receive Wire Type
      {Blogs|Profiles|Wikis|Bookmarks|Forums|Activities} Tags Payload {current page} Tags Tags Payload Public

    5. Click Add.

    6. Click Done.


    How the Tags portlet interacts with the other IBM Connections portlets

    This topic describes how the Tags portlet interacts with the other IBM Connections portlets.

    The IBM Connections Tags portlet allows users to locate content in the other IBM Connections portlets (Activities, Blogs, Bookmarks, Wikis and Profiles). Selecting a tag from the Tags portlet causes the Connections portlets to reload to display the content from the Connections applications tagged with the selected tag. This interaction between the Tags portlet and other Connections portlets is enabled through portlet wiring to send the information that the Connections portlets need to request the proper feeds filtered by the selected tag.

    There are two modes of operation with regards to the interaction between the tags and the other Connections portlets: one-way and two-way communication mode. In one-way communication mode, the Tags portlet sends a wire to the other Connections portlets to update their view according to a selected tag. In two-way communication mode, the other Connections portlets can also send a wire to the Tags portlet to update its view as well according to the view being displayed.

    Tags are not supported for Forums or Profiles deployed on a community page.


    One-way Communication Mode

    One-way communication mode is enabled when the Tags portlet is set to communicate with multiple instances of the Connections application portlets. This is enabled when more than one application is selected in the Shared Sets panel of the Tags portlet. In this mode, the Tags portlet uses the IBM Connections Homepage Search API to obtain an aggregated tag feed of the selected applications using the search URL set in the Tags portlet configure panel. To properly configure one-way communication mode for tag filtering, the following items are required:

    1. The search URL is properly configured in the Tags portlet configuration panel.

    2. At least two applications that you want represented in the Tags must be selected in the Tags portlet shared settings panel.

    3. The wiring must be configured to send a wire from the Tags portlet to the applications selected in step 2. See Wiring the IBM Connections portlets for instructions on how to set up portlet wiring.


    Two-way Communication Mode

    Two-way communication mode is enabled when the Tags portlet is set to communicate with a single Connections application portlet. This is enabled when only one application is selected in the Shared Sets panel of the Tags portlet. In this mode, the Tags portlet uses the corresponding application api to obtain an the tag feed of the selected application using the application URL set in the Tags portlet configure panel. Like the one-way communication mode, the Tags portlet sends a wire to the Connections application portlet when a tag is selected. In addition, the Connections application portlet sends a wire to the Tags portlet to refresh the tags to show the tags relevant for the view selected. An example of this is when you drill down into an activity from the .My Activities. view in the Activities portlet, a wire is sent to the tags with information to show the tags specific to the activity selected. To properly configure two-way communication mode for tag filtering, the following items are required:

    1. The application URL of the Connections application you want to represent in the tags must be set in the Tags portlet configuration panel.

    2. The single application that you want represented in the tags must be selected in the Tags portlet shared settings panel.

    3. The wiring must be configured to send a wire from the Tags portlet to the Connections application selected in step 2 and the wiring from the Connections application portlet must be configured to send a wire to the Tags portlet to render tags for the view selected in the application portlet. See Wiring the IBM Connections portlets for instructions on how to set up portlet wiring.


    Optimizing the page layout for the Tags portlet

    On WebSphere Portal 6.1.5.x, optimize the page layout to use a smaller column width for the Tags portlet.

    WebSphere Portal 6.1.5.x allows administrators and page editors to control the page layout for every page in the Portal environment. If the page layout includes a multi-column format, the size of each column can be set to optimize the layout to best accommodate the portlets on the page. The best layout of a page containing the IBM Connections tags portlet uses a smaller column width for the tags portlet leaving more screen real estate for the main content portlets with which it interacts.

    1. Enable the Edit Layout portlet to display the option to control the column size.

      1. Log in to WebSphere Portal as the administrator

      2. In the Administration section, go to Portlet Management > Portlets.

      3. Locate the Edit Layout portlet. Search by title using "edit layout" as the search text.

      4. Click the "Configure Portlet" icon.

      5. Set the "showAdvancedOption" to yes.

      6. Click OK to save the changes.

    2. Set the column size:

      1. Log in to WebSphere Portal as the administrator

      2. In the Administration section, go to Portlet Management > Manage Pages.

      3. Open a page containing the Tags portlet.

      4. Browse to the page containing the portlets and click on the "Edit Page Layout" option for the page.

      5. Click the "Show layout tools" link.

      6. In the header of the column containing the Tags portlet, click the two-sided arrow with the label "Not Set."

      7. Enter the pixel size for the width of the portlet. We recommend 180 pixels. This provides the optimal width.

      8. Click OK to save your settings.


    Addressing IBM Connections content from a portlet

    Use custom URIs to identify, access, and display IBM Connections in a portlet.

    You must be running the 3.0.1.1 version of the IBM Connections Portlets of IBM WebSphere Portal to use this feature.

    Beginning with version 6.0.1, IBM WebSphere Portal uses Piece of Content (POC) URIs to identify and address specific pieces of content in IBM Connections. Using a POC URI, you can precisely identify what content you want to display in a portlet. For example, when a user clicks a link in a blogs summary portlet, the POC URI identifies the blog content and displays it in the Blogs detail portlet. In earlier versions of Portal, this connection would be made using a standard URL to identify the target page of the content. URLs were limited and did not allow access to precise information about the state of a piece of content. The evolution to POC URIs provides a greater precision for identifying, retrieving, and displaying content. The URI specifies the identity of the content, not the location of the view of the document. The location of the view to the document is called the portal URL, or simply URL and the information contained in this URL is the navigational state, or simply state.

    For detailed information on the creating and using custom URIs to access content, see the article Leveraging WebSphere Portal V6 programming model: Part 5. Accessing portal content with custom URLs on IBM developerWorks®.


    Configure 3.0.1.1 to address content

    To configure 3.0.1.1 so you can address content between portlets, edit the properties in the properties.poc file.

    Use URIs to identify, access, and display IBM Connections content and profiles in a portlet. IBM WebSphere Portal uses Piece of Content (POC) URIs to identify and address specific pieces of content in IBM Connections independent of the page used to display the content. Using a POC URI, you can precisely identify what content you want to display without knowing where it should be displayed in your WebSphere Portal server at the time you generate a link. For example, when a user clicks a link in a blogs summary portlet, the POC URI identifies the blog content. Clicking on a link that uses a POC URI displays the blog entry in the Blogs detail portlet on the appropriate page. The evolution to POC URIs provides a greater precision for identifying, retrieving, and displaying content. The URI specifies the identity of the content, not the location of the view of the document. The location of the view to the document is called the portal URL, or simply URL and the information contained in this URL includes the navigational state, or simply state.


    Configure navigation between portlets in the 3.0.1.1 release

    Use URIs to identify, access, and display IBM Connections content and profiles in a portlet.

    You must be running the 3.0.1.1 version of the IBM Connections Portlets of IBM WebSphere Portal to use this feature.

    When working with a POC URI, you do not need to be aware of the page in Portal where a piece of content should be displayed, you only need to know some identifying data about the piece of content to create the URL. The correct WebSphere Portal page to display the content is retrieved after the user clicks on a link using a POC URI format.

    The POC resolver handles navigation in following manner.

    • If the piece of content is community content:

      • Search the community page for a detail portlet to render the content.

      • If no static community page is found , search for a stand-alone page.

      • If no stand-alone page is found, navigate to an error page.

    • If the piece of content is from a stand-alone page rather than from a community:

      • Search the standalone page for a detail portlet to render the content.

      • If no standalone page is found , navigate to an error page.

    For detailed information on the creating and using custom URIs to access content, see the article Leveraging WebSphere Portal V6 programming model: Part 5. Accessing portal content with custom URLs on IBM developerWorks. The following steps are an example of how you can wire portlets in an application. You can apply these steps to wiring any of the IBM Connections portlets in an application.

    1. Ensure you have followed the install instructions completely. The JAR for the POC handler must be installed as described in Installing the IBM Connections Portlets for IBM WebSphere Portal.

    2. To configure navigation to community pages, ensure you have set the correct properties when defining the community page as described in Mapping a community page to a community.

    3. To configure navigation for content not inside a community, or for which a community page does not exist, ensure you have create default pages for each service as described in Configuring the portlets on a page.


    What to do next

    You can configure and customize certain aspects related to navigation by editing the default values in the configuration file com.ibm.lconn.lcaccelerator.poc.properties in the directory <portlet_build>/POCResolver. For example, you can customize:

    • Portlet IDs

    • Page names for stand-alone pages

    • Default page to display when a target page is not available

    After customizing the file, you must move it to the <wp_profile>/properties directory.


    Configure 3.0.1.1 Refresh to address content

    To configure 3.0.1.1R so you can address content between portlets, edit environment variables.

    Use URIs to identify, access, and display IBM Connections content and profiles in a portlet. IBM WebSphere Portal uses Piece of Content (POC) URIs to identify and address specific pieces of content in IBM Connections independent of the page used to display the content. Using a POC URI, you can precisely identify what content you want to display without knowing where it should be displayed in your WebSphere Portal server at the time you generate a link. For example, when a user clicks a link in a blogs summary portlet, the POC URI identifies the blog content. Clicking on a link that uses a POC URI displays the blog entry in the Blogs detail portlet on the appropriate page. The evolution to POC URIs provides a greater precision for identifying, retrieving, and displaying content. The URI specifies the identity of the content, not the location of the view of the document. The location of the view to the document is called the portal URL, or simply URL and the information contained in this URL includes the navigational state, or simply state.


    Configure a resource environment provider for POC

    You must configure the WebSphere Resource Environment provider in order to address content in the portlets using POC.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 refresh to use this feature. Add any allowed IBM Connections server URLs. For example, if the server allows http and https URLs, add both.

    1. Log into the WebSphere Application Server Integrated Solutions Console.

    2. Navigate to Resources > Resource Environment > Resource Environment Providers.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. If the WP ConnectionsIntegrationService already exists, click on it. If not, click New, specify WP ConnectionsIntegrationService, and click Apply.

    5. Click Custom Properties.

    6. Click New and configure the following attributes:

      These attributes are optional. If you do not specify values, the default values are used.

      Name Description Default Value Type

      pocRedirectToNativeUIOnError The default value of true enables redirection to the Connections native UI in case of error. The value of false redirects user to the configured portal error page. true java.lang.String

      portletsAppId Set the <portlet app id> for a customized portlet. . The default is com.bowstreet.portlet.WebAppRunner2_snor.pf.portlets java.lang.String

      pocErrorPageUN Specify an <error_page_UniqueName> as the error page. The default value is ibm.conn.navigation.error. java.lang.String

      <service name>StandalonePageUN

      This enables support for multiple detail portlets on a single standalone page. For example,

      blogsStandalonePageUN=ibm.conn.common.standalone.page
      wikisStandalonePageUN=ibm.conn.common.standalone.page
      profilesStandalonePageUN=ibm.conn.common.standalone.page 
      indicates that blogs, wikis and profiles detail portlets are deployed on a page with the unique name ibm.conn.common.standalone.page.

      The default value is ibm.conn<service>.

      For example:

      • ibm.conn.profiles

      • ibm.conn.blogs

      • ibm.conn.activities

      • ibm.conn.forums

      • ibm.conn.bookmarks

      • ibm.conn.wikis
      java.lang.String

    7. Save the new settings.


    What to do next

    If you deployed an earlier version of the Connections portlets that used the poc.properties file to configure POC settings, the following properties from the poc.properties file correspond to the environment variables:

    Property in the poc.properties file Environment variable name

    ibm.conn.portlets.app.id portletsAppId

    error.page pocErrorPageUN

    <service> <service>StandalonePageUN


    Configure the cache for POC

    Configure a cache to store a collections of web URLs to optimize the page load performance when resolving requests to address a piece of Connections content.

    You must be using IBM Connections Portlets for IBM WebSphere Portal 3.0.1.1 refresh to use this feature. The IBM Connections portlets use a cache to store a collections of web URLs to optimize the page load performance when resolving requests to address a piece of Connections content.

    To set up the Connections Portlets DynaCache instance for each node in you portal cluster, do the following:

    1. Open the WebSphere Application Server Admin Console and expand Cache Instances in the Resources section.

    2. Select Object Cache Instances.

    3. Select Server or Cluster as the scope, depending on whether you are deploying on a single server or on a cluster.

    4. Click New to create a new cache instance.

    5. Set the JNDI Name to services/cache/LCPocCache and set Name to something meaningful.

    6. Click OK to save your changes.


    Results

    The default value of 2000 is designed to handle the number of URLs for an average deployment. You can edit this value.


    Configure a global proxy for POC

    Configure a global proxy for POC to handle URL redirections.

    This procedure only applies if you are deploying the IBM Connections portlets 3.0.1.1 refresh edition on Portal 7 servers. Skip these steps if you are using 3.0.1.1 or are deploying on Portal 8 servers.

    You must configure a global proxy in order to address content in the Connections portlets.

    To set up the global proxy, do the following:

    1. Follow the instructions in this article to configure a global proxy.

    2. When you configure the global proxy, add the following line to the proxy definition:

      <proxy:policy url="{$ibm_connections_policy}" acf="none" basic-auth-support="true">
              <proxy:actions>
                  <proxy:method>GET</proxy:method>
                  <proxy:method>HEAD</proxy:method>
                  <proxy:method>POST</proxy:method>
                  <proxy:method>PUT</proxy:method>
                  <proxy:method>DELETE</proxy:method>
              </proxy:actions>
              <proxy:cookies>
                  <proxy:cookie>LTPA</proxy:cookie>
                  <proxy:cookie>LTPA2</proxy:cookie>
                  <proxy:cookie>LtpaToken</proxy:cookie>
                  <proxy:cookie>LtpaToken2</proxy:cookie>
                  <proxy:cookie>JSESSIONID</proxy:cookie>
                  <proxy:cookie>PD-H-SESSION-ID</proxy:cookie>
                  <proxy:cookie>PD-S-SESSION-ID</proxy:cookie>
                  <proxy:cookie>SMSESSION</proxy:cookie>
              </proxy:cookies>
          </proxy:policy>


    Configure navigation between portlets

    Use URIs to identify, access, and display IBM Connections content and profiles in a portlet.

    You must be running the 3.0.1.1 version of the IBM Connections Portlets of IBM WebSphere Portal to use this feature.

    Use URIs to identify, access, and display IBM Connections content and profiles in a portlet. IBM WebSphere Portal uses Piece of Content (POC) URIs to identify and address specific pieces of content in IBM Connections independent of the page used to display the content. Using a POC URI, you can precisely identify what content you want to display without knowing where it should be displayed in your WebSphere Portal server at the time you generate a link. For example, when a user clicks a link in a blogs summary portlet, the POC URI identifies the blog content. Clicking on a link that uses a POC URI displays the blog entry in the Blogs detail portlet on the appropriate page. The evolution to POC URIs provides a greater precision for identifying, retrieving, and displaying content. The URI specifies the identity of the content, not the location of the view of the document. The location of the view to the document is called the portal URL, or simply URL and the information contained in this URL includes the navigational state, or simply state. When working with a POC URI, you do not need to be aware of the page in Portal where a piece of content should be displayed, you only need to know some identifying data about the piece of content to create the URL. The correct WebSphere Portal page to display the content is retrieved after the user clicks on a link using a POC URI format.

    The POC resolver handles navigation in following manner.

    • If the piece of content is community content:

      • Search the community page for a detail portlet to render the content.

      • If no static community page is found , search for a stand-alone page.

      • If no stand-alone page is found, navigate to an error page.

    • If the piece of content is from a stand-alone page rather than from a community:

      • Search the standalone page for a detail portlet to render the content.

      • If no standalone page is found , navigate to an error page.

    For detailed information on the creating and using custom URIs to access content, see the article Leveraging WebSphere Portal V6 programming model: Part 5. Accessing portal content with custom URLs on IBM developerWorks. The following steps are an example of how you can wire portlets in an application. You can apply these steps to wiring any of the IBM Connections portlets in an application.

    1. Ensure you have followed the install instructions completely. The JAR for the POC handler must be installed as described in Installing the IBM Connections Portlets for IBM WebSphere Portal.

    2. To configure navigation to community pages, ensure you have set the correct properties when defining the community page as described in Mapping a community page to a community.

    3. To configure navigation for content not inside a community, or for which a community page does not exist, ensure you have create default pages for each service as described in Configuring the portlets on a page.


    Custom URI syntax

    Understand the syntax for creating a custom URI to access a piece of content.


    POC URI Syntax

    Construct a POC URI to address Connections content. The syntax has this form:

    connections:<atom_uri>&commID=<community_id>&service=<service_name>&type=<content_type>

    commID, service, and type must be specified as parameters. Parameter names are case sensitive.


    Parameters

    connections

    connections is the scheme that identifies the type of content the URI is locating.

    atom_uri

    The path portion of the URI used to fetch the atom document for the content.

    commID

    (optional) Community ID. Needs to be specified if the content is community-based.

    service

    Identifies the Connections service.

    type

    Identifies the content type. For example, an activity or a wiki page.

    Table 23. Connections services and types

    Service Type Type specific parameters Description
    activities activity   Opens a particular activity, showing the outline page in the appropriate activities detail portlet
      item   Opens the activity outline page for the activity containing this item in the activities portlet. The atom_uri may refer to an activity todo, entry, section, comment, chat communication, or email communication.
    blogs blog   Opens particular blog in the appropriate blog details portlet
      entry   Opens a particular blog entry in the appropriate blog details portlet
    communities community   Opens the community page for this community if one is available, otherwise directs to the configured error page.
    forums forum   Opens a particular forum in the appropriate forum details portlet
      topic

    forumUuid (optional)

    Opens a particular forum topic entry in the appropriate forums details portlet
    profiles profile   Opens the profile detail in the profiles portlet
    wikis wiki   Opens a particular wiki in the appropriate wiki details portlet
      page   Opens a particular wiki page in the appropriate wiki details portlet
      file

    wikiLabel

    pageLabel

    Opens the attachments listing page for the parent wiki page in the wikis portlet. The atom_uri may be the URI of any attachment on the page, obtained from the attachment Atom entry. The portlet will list all attachments for that wiki page.


    POC Servlet

    The piece of content (POC) servlet checks for authentication. The /poc mapping does not require authentication but recognizes if valid authentication or single-signon information is present. If that case, the resolver framework will redirect to /myportal; otherwise, it redirects to /portal. In many usage scenarios it is appropriate to address the /poc mapping, because it detects potential authentication information automatically. In any case, access control to the actual page and portlets to which the POC URI resolves is enforced by the portal. The POC servlet default path is

    http://<server>:<port>/wps/poc?uri= 

    Use the POC Servlet with the POC URI to access content as follows:

    POC URI:http://<server>:<port>/wps/poc?uri=connections:<atom_uri>&commID=<community_id>&service=<service_name>&type=<content_type>


    Sample URI

    POC URI to address a forum topic:

    http://<server>:<port>/wps/poc?uri=connections:forums/atom/topic?topicUuid=da99c49f-d2d0-47d9-9f18-1f32cf9e108c&type=topic&service=forums&commID=9425353dfea-484c-1234-1f2f7d51e517&forumUuid=6864a28b-dfea-484c-9fd8-1f2f7d51e517

    
    
    
    
    
    
    


    IBM Connections Business Card

    The IBM Connections Business Card integrates the applications of IBM Connections with Sametime.

    The IBM Connections Business Card replaces the standard business card in products with Sametime enabled. In addition to a person's contact information, you can view their IBM Connections profile, and see other content such as what blogs they own.


    Configure the IBM Connections Business Card

    As the administrator, you can configure the IBM Connections Business Card plug-in to provide IBM Connections contact information in products with IBM Sametime awareness enabled. The IBM Connections business card plug-in allows users to display contact information that is pulled directly from the Profiles server combined with information from IBM Sametime. You can edit the plugin_customization.ini file as described in Use INI settings to configure the IBM Connections features that are available in the IBM Lotus Notes client to enable the Connections Business Card to work with Sametime awareness.

    To understand how to integrate the IBM Connections Business Card with the IBM Lotus Notes Activities sidebar refer to this article on Notes Integration.


    What to do next

    To uninstall this plug-in:

    1. Uninstall the IBM Connections Business Card using the Add/Remove programs service from the Control Panel.

    2. Manually remove the Business Card related accounts from the Accounts Preferences panel. Delete all accounts that have the description .IBM Connections.. The account named .Connections. should be the final account deleted.

      Only do this if you are NOT using the Activities sidebar. If this is the case leave all accounts in place.


    IBM Connections Desktop Plug-ins for Microsoft Windows

    Use the plug-ins to share files and information between Microsoft Windows applications and IBM Connections.

    The IBM Connections Desktop Plug-ins Microsoft Windows supports:

    • IBM Connections 4.0

    • IBM Connections 3.0.1.1

    • Microsoft Windows XP SP3 (32-bit)

    • Windows Vista (32-bit)

    • Windows 7 SP1 (32-bit, 64-bit) 

    • Microsoft Office 2007 Standard or higher (32-bit)2010 Standard or higher (32, 64-bit)

    • Microsoft Outlook 2007 Standard or higher (32-bit), 2010 Standard or higher (32, 64-bit)

    The IBM Connections Desktop Plug-ins for Microsoft Windows provides the following features from Microsoft Windows Explorer:

    • Upload local files to IBM Connections from Windows Explorer or from your desktop

    • Share uploaded files with people, communities, or folders in IBM Connections

    • Work on files locally and publish them to IBM Connections

    • View people's contact details and get in touch with them

    • Pin, follow, or like IBM Connections files and folders

    • View or contribute comments for a file

    • Lock a file when you are editing it to prevent file conflicts

    • View and restore files from IBM Connections Trash

    • Share folders with IBM Connections Communities

    The IBM Connections Desktop Plug-ins for Microsoft Windows provides the following features from Microsoft Office (Word, Excel, PowerPoint):

    • Features added to Word:

      • Add a document to IBM Connections Files or Communities

      • Attach a document to an Activity or Wiki page

      • Publish a document to a Blog entry

      • Add someone's profile information from IBM Connections into a document

      • Add a bookmark from IBM Connections into a document

      • Add a URL from a document as a bookmark in IBM Connections

      • Search for content in IBM Connections

    • Features added to PowerPoint:

      • Add a presentation to IBM Connections Files or Communities

      • Attach a presentation to an Activity or Wiki page

      • Search for content in IBM Connections

    • Features added to Excel:

      • Add a spreadsheet to IBM Connections Files or Communities

      • Attach a spreadsheet to an Activity or Wiki page

      • Search for content in IBM Connections

    The IBM Connections Desktop Plug-ins for Microsoft Windows provides the following features from Microsoft Outlook:

    • Add an email to IBM Connections Files or Communities

    • Attach an email to an activity or wiki page

    • Search for content in IBM Connections

    • View social activities for email recipients and people in your network

    • Invite people to your IBM Connections network

    • View IBM Connections business card for email senders and recipients in Outlook 2010

    If you previously installed any version of the IBM Connections Plug-in for Microsoft Office and Microsoft Windows, installing this plug-in silently removes the Microsoft Explorer features from the older plug-ins.

    You have two options for installing the plug-in. Individual users can install the plug-in, or you can perform a silent installation to install the plug-in for a group of users.


    Performing a user installation

    Users can install the IBM Desktops Plug-ins for Microsoft Windows following these steps.

    1. Download the plug-in from the IBM Connections catalog at the following web site:

      https://greenhouse.lotus.com/catalog

    2. Unzip the file.

    3. Double-click IBMConnectionsDesktop.exe to launch the installation program.

    4. Optional: Choose not to install the Microsoft Office or Microsoft Outlook plug-ins. In the Custom Setup panel, click the icon next to Microsoft Office or Microsoft Outlook, and then click This feature will not be available to not install those plug-ins. The Microsoft Explorer plug-in is always installed.

    5. Click Finish to complete the installation.

    6. If prompted, reboot your computer.


    Performing a silent installation

    Administrators can silently upgrade or install the IBM Connections Desktop Plug-ins for Microsoft Windows from the command prompt. User notification is disabled during the silent installation, except in error cases such as notification of failed prerequisites. A silent installation uses the same installation program that the graphical user interface (GUI) version uses. However, instead of displaying a wizard interface, the silent installation reads all of your responses from parameters that you pass to the command line. In order for the installation to work successfully, you must run the silent installation from the directory where you unzipped the plug-in files.

    1. Download the plug-in from the IBM Connections catalog at the following web site:

      https://greenhouse.lotus.com/catalog

    2. Unzip the file.

    3. cd directory where you saved IBMConnectionsDesktop.exe.

    4. Type IBMConnectionsDesktop.exe /Options(s) [PROPERTY=Value] The optional parameters and public property settings are listed in the following tables:

      Table 24. Optional parameters

      Optional parameters Description
      /install Installs the plug-in.
      /uninstall Uninstalls the plug-in.
      /quiet Establishes Silent mode requiring no user interaction.
      /norestart Prevents restart after the installation is complete.
      /promptrestart Prompts the user for restart if necessary.
      /forcerestart Always restarts the computer after installation.

      Table 25. Public properties

      Public property Description
      INSTALLDIR Directory that plug-ins will be installed in. For example,

      INSTALLDIR=C:\Progra~1\IBM\Connections Desktop Plugins
      ADDLOCAL Optionally install components. If this is not specified, all components are installed. The Windows Explorer feature is required and is always installed. Examples:

      • To silently install just the Microsoft Windows Explorer feature:

        IBMConnectionsDeskTop.exe /install /quiet ADDLOCAL=WindowsExplorer

      • To silently install the Microsoft Office feature:

        IBMConnectionsDeskTop.exe /install /quiet ADDLOCAL=WindowsExplorer,MicrosoftOffice

      • To silently install the Microsoft Outlook feature:

        IBMConnectionsDeskTop.exe /install /quiet ADDLOCAL=WindowsExplorer,MicrosoftOutlook

      • To disable Connections 3.0 or 3.01 features on Microsoft Window Explorers desktop:

        IBMConnectionsDeskTop.exe /install /quiet DSB_MS30X_EXPLORER

      • To disable Connections 3.0 or 3.01 features on Microsoft Window Explorers and install the Connections 4.0 plug-ins features for Windows Explorer:

        IBMConnectionsDeskTop.exe /install /quiet ADDLOCAL=WindowsExplorer DSB_MS30X_EXPLORER
      DSB_MS30X_EXPLORER If you previously installed an earlier version of the IBM Connections 3.0.1 Plug-in for Microsoft Office and Microsoft Windows, this option disables rather than uninstalls plug-in features. If this option is not specified, the earlier features will be uninstalled silently.

      • To disable Windows Explorer features of the IBM Connections 3.0.1 Plug-in for Microsoft Office and Microsoft Windows and install all components of the Connections 4.0 plug-in:

        IBMConnectionsDeskTop.exe /install /quiet DSB_MS30X_EXPLORER
        

      • To disable Windows Explorer features of the IBM Connections 3.0 or 3.0.1 Plug-in and install the Windows Explorer feature of Connections 4.0 plug-in:

        IBMConnectionsDeskTop.exe /install /quiet ADDLOCAL=WindowsExplorer DSB_MS30X_EXPLORER

      Table 26. Samples of silent install commands

      description Example
      Silent install with restart and INSTALLDIR property

      IBMConnectionsDesktop.exe /install /quiet /forcerestart
      INSTALLDIR=C:\Progra~1\IBM\Sample
      Silent uninstall with no restart

      IBMConnectionsDesktop.exe /uninstall /quiet /norestart 

    5. Reboot the machine.


    Repairing or removing the IBM Connections Desktop plug-ins

    Users experiencing problems with the plug-in can use the Repair function to correct it or use the Remove feature to uninstall the plug-in.

    1. Navigate to the Add/Remove Programs panel from your Microsoft Windows control panel.

    2. Select IBM Connections Desktop Plug-ins for Microsoft Windows and choose one of the following:

      1. Select Change , then Next, and finally Repair to correct an installation.

      2. Select Remove to remove the plug-in from your system.

    3. Confirm your choice and complete the operation.

    4. Reboot your computer.


    Preferences and policies for the IBM Connections Desktop Plug-ins for Microsoft Windows

    Set preferences and policies to control how users interact with the IBM Connections Desktop Plug-in for Microsoft Windows.

    The following table shows preference and policy settings that control the behavior of the IBM Connections Desktop Plug-in for Microsoft Windows. These registry values are not created during install. You must create these keys/values as needed. If a key/value does not exist the appropriate default is assumed. Set values to anything other than the values listed below will produce unpredictable results.

    For 64-bit machines, the registry settings are stored in HKLM/SOFTWARE/Wow6432Node/IBM instead of in HKLM/SOFTWARE/IBM (used for 32-bit machines).

    Table 27. Registry keys for IBM Connections Desktop Plug-in for Microsoft Windows.

    Enter registry keys with no line breaks. They are formatted for readability in the tables below.

    Key/SubKey (HKLM/SOFTWARE/IBM) or (HKLM/SOFTWARE/Wow6432Node/IBM on 64-bit) Name (Type = String) Values Description

    Social Connectors/Sets

    Hide ShellExt

    0 . Display Context Menu (Default)

    1 . Do not display Context Menu

    Controls the default visibility preference of the Windows Explorer context menu extension.

    Set this value will override a user preference if the policy is also set to Disable (value=1)

    Social Connectors/Sets

    Hide ShellExt Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Controls whether users can modify the preferences value.

    HKCU/SOFTWARE/Microsoft/Windows/CurrentVersion/
    Explorer/HideDesktopIcons/ClassicStartMenu

    32-bit OS

    {A0D85EDF-50B5-4B12-9D74-0D69E6729A11}

    64-bit OS

    {21034BDC-B57E-400b-A5D5-2B1E98502805}

    Type = DWORD

    0 . Show (Default)

    1 . Hide

    Controls hiding of the Desktop Icon when using the classic Start Menu. This must be set per user (HKCU).

    HKCU/SOFTWARE/Microsoft/Windows/CurrentVersion/
    Explorer/HideDesktopIcons/NewStartPanel

    32-bit OS

    {A0D85EDF-50B5-4B12-9D74-0D69E6729A11}

    64-bit OS

    {21034BDC-B57E-400b-A5D5-2B1E98502805}

    Type = DWORD

    0 . Show (Default)

    1 . Hide

    Controls hiding of the Desktop Icon when using the default Start Menu. This must be set per user (HKCU).

    Social Connectors/Sets

    Hide Desktop Icon Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Controls whether users can modify the value via the General Tab of the preferences dialog.

    Social Connectors/Sets

    SendLink MailApp

    mailto . Use mailto: protocol (Default)

    <MAPI program> - Registered name of email program

    Example: Lotus Notes

    Sets the default email application in the General tab of the preferences dialog.

    If set to mailto:, the mailto: protocol will be used instead of MAPI.

    Social Connectors/Sets

    SendLink MailApp Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Controls whether users can modify the E-mail Sets value via the General tab of the preferences dialog.

    Social Connectors/Sets

    UnpublishedPrompt

    0 . Do not display prompt

    1 . Display prompt (Default)

    Controls the default setting of the unpublished draft warning.

    Set this value will override the user's preference if the policy is also set to Disabled.

    Social Connectors/Sets

    UnpublishedPrompt Policy

    0 . Allow Hide (Default)

    1 . Disable Hide

    Controls whether end users can elect to hide the unpublished draft warning.

    Social Connectors/Sets

    ShowInfoBubbles

    0 . Do not show Alerts

    1 . Show Alerts (Default)

    Controls the default setting for alerting that local drafts need to be saved.

    Social Connectors/Sets

    ShowInfoBubbles Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Controls whether users can change the ShowInfoBubbles preference.

    Social Connectors/Sets

    MonitorWarnOnClose

    0 . Do not warn on close

    1 . Warn on close (Default)

    Controls display of warning message when drafts monitor is closed:

    Social Connectors/Sets

    MonitorWarnOnClose Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Controls whether warning dialog can be suppressed by users.

    Social Connectors/Sets

    EnableCacheCleanup

    0 . Disable Cache Cleanup (Default)

    1 . Enable Cache Cleanup

    Default setting for enabling/disabling cache cleanup.

    Overrides user preference if policy is also set.

    Social Connectors/Sets

    EnableCacheCleanup Policy

    0 . Enable Preferences (Default)

    1 . Disable Preferences

    Controls whether users can change any of the Cache settings.

    Social Connectors/Sets

    CacheAge

    <days> - number of days

    Min . 1

    Max . 100

    Default - 1 (Default)

    Files not accessed within the specified number of days will be deleted.

    Social Connectors/Sets

    CacheFrequency

    <minutes> - number of minutes

    Min . 5

    Max . 1,440

    Default - 120 (Default)

    Controls how often to run cache cleanup

    Social Connectors/Sets

    ScanIgnoreExtensions

    <comma separated extensions>

    List of extensions to ignore changes on. This list will be merged with any user preferences unless the policy is set to Disable.

    Example: gif, jpeg, mpg

    Modifying this setting requires you to reboot.

    Social Connectors/Sets

    ScanIgnoreExtensions Policy

    0 . Enable Preference (Default)

    1 . Disable Preference

    Set the policy to disable will prevent users from adding file extensions to the ignore list.

    Social Connectors/Servers

    Password Save Policy

    0 . Allow Saving (Default)

    1 . Do not Allow Saving

    Controls whether users can persist passwords locally.

    Passwords are stored in the Windows Credential Store.

    Social Connectors/Sets

    Default Auth Type

    0 . Basic Authentication (Default)

    1 . Custom

    Controls the default authentication type in the Add Site dialog.

    Social Connectors/Sets

    Default Auth Ext

    {EA483EAD-9E-4ECC-BDDD-BF8B1D72A1C6} - SiteMinder Authentication

    {4B9448AB-DF3D-4859-A3CA-3653890997} - Integrated Windows Authentication

    {B5BAD66C-CF6F-4FA5-9BC7-EF36C76D331A} - TAM Authentication

    {FB5CF435-95ED-4FE6-BB7D-95F82DB65C5C} - Integrated Windows Authentication (TAM)

    {CCD9158D-BCD9-4DCD-81B2-48E21D670F5C} - Integrated Windows Authentication (SiteMinder)

    When Default Auth Type is set to Custom this setting controls which custom authentication module will display by default. For example to use Tivoli Access Manger authentication set this to {B5BAD66C-CF6F-4FA5-9BC7-EF36C76D331A} and then set Default Auth Type to Custom.

    Social Connectors

    BasicAuthEncoding

    (Type is DWORD)

    28591 - (ISO8895-1) (Default)

    65001 - (UTF8)

    Select encoding type for credentials when using basic authentication.

    Social Connectors

    LFFilesRoot

    <path to existing directory>

    %HOMEPATH%\ LFFiles (Default)

    Default root directory for downloaded files. This must be set to a non-shared local directory on the client system. Once set it will only affect newly added servers, communities, or people

    Modifying this setting requires you to reboot.

    Social Connectors/Sets

    DefaultConnectURL

    <server url>

    Enter the URL to use as the default site URL in the "Connect to a Site" dialog.

    Social Connectors/Sets

    DefaultConnectName

    <server display name>

    This display name is the default server display name in the "Connect to a Site" dialog.

    Social Connectors/Sets

    Help URL

    http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Using_the_IBM_Connections_Desktop_Plugins_for_Microsoft_Windows_ic40 (Default)

    .http://. or .https://. is required as part of the url

    The url for help for the entire product.

    Social Connectors/Sets

    HelpConnectURL

    http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Using_the_IBM_Connections_Desktop_Plugins_for_Microsoft_Windows_ic40 (Default)

    .http://. or .https://. is required as part of the url

    The URL for help on the Connect to Site dialog. This will override the setting for HelpURL

    Table 28. Outlook Social Connector Sets Default settings

    Key/SubKey (HKLM/SOFTWARE/IBM) or (HKLM/SOFTWARE/Wow6432Node/IBM on 64-bit) Name (Type = String) Values Description

    Social Connectors/Office/OSC

    MaxFriends

    <friends> - number of friends Min . 100 Max . 9999 Default - 500

    Maximum number of friends that can be downloaded from the users network. These will create outlook contacts. Values entered will be rounded up to the next hundred (e.g. 111 would be treated as 200)

    Social Connectors/Office/OSC

    MaxNews

    <items> - number of news items Min . 100 Max . 9999 Default - 500

    Maximum number of activities that will be downloaded from the news feed. These will be stored in the outlook cache via OSC framework. Values entered will be rounded up to the next hundred (e.g. 111 would be treated as 200)

    Social Connectors/Office/OSC

    DaysSince

    Min . 1 Max . 14599 (year 1970) Default - 14

    When getting news activities, this is how many days to go back in time from the current day.

    Social Connectors/Office/OSC

    HashedSearchParm

    hashEmail

    The name of the property in a users profile to compare with the HashEmail. Can be used to test hash email lookup is working when server cannot be configured

    Social Connectors/Office/OSC

    HashFunction

    Default . SHA1 Other values are MD5 or CRC32MD5

    The hash algorithm used to compare the email addresses. This is passed to Outlook and it will return a hashed value of the email address using this type.

    Social Connectors/Office/OSC

    EnableDynamicActivities

    0 . Disable DynActivities (Default)

    1 . Enable DynActivities

    Enable getting dynamic news items for users. This requires the server be configured to handle the Hashed SearchParam

    Social Connectors/Office/OSC

    EnableDynamicContacts

    0 . Disable DynContacts (Default)

    1 . Enable DynContacts

    Enable getting dynamic contacts. This requires the server be configured to handle the Hashed SearchParam

    Social Connectors/Office/OSC

    EnableContacts

    0 . Disable Contacts (Default)

    1 . Enable Contacts

    Get contacts for Profiles Network and create Outlook contacts

    Table 29. Outlook Social Connector Sets per hostname (Provider) overrides of Default values. This allows per server settings.

    Key/SubKey (HKLM/SOFTWARE/IBM) or (HKLM/SOFTWARE/Wow6432Node/IBM on 64-bit) Name (Type = String) Values Description

    Social Connectors/Office/OSC

    MaxFriends

    <friends> - number of friends Min . 100 Max . 9999

    Default - 500

    Maximum number of friends that can be downloaded from the users network. These will create outlook contacts. Values entered will be rounded up to the next hundred (e.g. 111 would be treated as 200)

    Social Connectors/Office/OSC

    MaxNews

    <items> - number of news items Min . 100 Max . 9999

    Default - 500

    Maximum number of activities that will be downloaded from the news feed. These will be stored in the outlook cache via OSC framework. Values entered will be rounded up to the next hundred (e.g. 111 would be treated as 200)

    Social Connectors/Office/OSC

    DaysSince

    Min . 1 Max . 14599 (year 1970)

    Default - 14

    When getting news activities, this is how many days to go back in time from the current day.

    Social Connectors/Office/OSC

    HashedSearchParm

    Default - hashEmail

    The name of the property in a users profile to compare with the HashEmail. Can be used to test hash email lookup is working when server cannot be configured.

    Social Connectors/Office/OSC

    HashFunction

    Default . SHA1 Other values are MD5 or CRC32MD5

    The hash algorithm used to compare the email addresses. This is passed to Outlook and it will return a hashed value of the email address using this type.

    Social Connectors/Office/OSC

    EnableDynamicActivities

    0 . Disable DynActivities (Default)

    1 . Enable DynActivities

    Enable getting dynamic news items for users. This requires the server be configured to handle the Hashed SearchParam.

    Social Connectors/Office/OSC

    EnableDynamicContacts

    0 . Disable DynContacts (Default)

    1 . Enable DynContacts

    Enable getting dynamic contacts. This requires the server be configured to handle the Hashed SearchParam.

    Social Connectors/Office/OSC

    EnableContacts

    0 . Disable Contacts

    1 . Enable Contacts (Default)

    Get contacts for Profiles Network and create Outlook contacts.

    Table 30. Registry settings to enable the dynamic features of the IBM Connections OSC provider

    Key/SubKey (HKLM/SOFTWARE/IBM) or (HKLM/SOFTWARE/Wow6432Node/IBM on 64-bit) Name (Type = String) Values Description

    HKLM\Software\IBM\Social Connectors\Office\OSC\EnableDynamicContacts

    REG_STRING

    0 . Disable lookup

    1 . Enable lookup (Default)

    Dynamic Contact Lookup . This dynamic feature will allow the authenticated user to lookup the picture, name, and job title for the OSC user.

    HKLM\Software\IBM\Social Connectors\Office\OSC\EnableDynamicActivities

    REG_STRING

    0 . Disable

    1 . Enable (Default)

    Dynamic Contact Activites . This dynamic feature will allow the authenticated user to retrieve the activities for the OSC user.

    HKLM\Software\IBM\Social Connectors\Office\OSC\ HashFunction

    REG_STRING

    SH1

    MD5

    CRC32MD5

    Email address hash for the dynamic lookup. This hash is configurable incase the desired type of hash on the server is not the default value of MD5. This is a function provided by the OSC framework, not the OSC provider. This tells the OSC provider to request the particular hash type.


    Manage policies and preferences with a group policy

    Use a group policy administrative template to manage preferences and policies across an enterprise. If you want to set policies and preferences for a group of users, use the Group Policy Administrative Template. This console provides a single user interface through which to manage Group Policy across an enterprise. To use the template, load it into the Group Policy Management Console snap-in.

    1. To start the Group Policy Management Console, open a command line window and enter gpedit.msc .

    2. Select Computer Configuration > Administrative Templates.

    3. Right-click on the Administrative Templates node and select Add/Remove Templates.

    4. Select Add.

    5. Navigate to the installation directory for the plug-ins. For example, C:\Program Files (x86)\IBM\Connections Desktop Plugins.

    6. Select the appropriate template for your Windows version (For example, IBMConnections.adm or IBMConnections64.adm).


    Results

    There will be two newly created nodes with the following new entries:

    • Computer Configuration > Administrative Templates > Classic Administrative Templates (ADM) > IBM Connections Desktop Plug-ins for Microsoft Windows

      • Temporary File Cleanup - Enable/Disable Cleanup

      • Temporary File Cleanup - Policy

      • Temporary File Cleanup - Minimum File Access Time

      • Temporary File Cleanup - Cleanup Frequency

      • Hide Shell Extension

      • Hide Shell Extension - Policy

      • Hide Desktop Icon - Policy

      • Hide Desktop Icon - New Start Panel

      • Hide Desktop Icon - Classic Start Menu

      • SendLink MailApp

      • SendLink MailApp - Policy

      • Unpublished Prompt

      • Unpublished Prompt - Policy

      • Show Information Bubbles

      • Show Information Bubbles - Policy

      • Monitor Warn On Close

      • Monitor Warn On Close - Policy

      • Scan Ignore Extensions

      • Scan Ignore Extensions - Policy

      • Password Save - Policy

      • Default Authentication Type

      • Default Authentication Extension

      • Basic Authentication Encoding Type

      • Cache Directory Root

      • Help URL

      • Connect to Site Help URL

      • Connect to Site Server URL

      • Connect to Site Server Name

      • OSC - Maximum Number of Friends

      • OSC - Maximum Number of News Items

      • OSC - Period of Time for News Feed

      • OSC - Hash Search Parameter

      • OSC - Hashed Email Function

      • OSC - Enable Dynamic Activities

      • OSC - Enable Dynamic Contacts

      • OSC - Enable Contacts

    • User Configuration > Administrative Templates > Classic Administrative Templates (ADM) > IBM Connections Desktop Plug-ins for Microsoft Windows

      • Hide Desktop Icon - New Start Panel

      • Hide Desktop Icon - Classic Start Menu


    Configure dynamic feeds for the Outlook Social Connector

    Configure the IBM Connections Profiles server and the IBM Connections Outlook Social Connector provider to support dynamic feeds to bring data from Connections to the outlook client via the Microsoft Outlook Social Connector.

    By default, the IBM Connections OSC provider does not have the dynamic contacts capabilities enabled. This is because the IBM Connections server must be configured to support this feature. Dynamic contacts capability can potentially make many server requests and so server load is reduced by disabling the capability until the server supports the required information.

    Dynamic contacts are those members not in the authenticated user.s network. As Microsoft Outlook switches emails, the sender.s email address is sent to the OSC providers to check whether that email address exists on the server. The IBM Connections server must do an additional step to populate its repository with a hash of the Profiles members email address. For security purposes, the OSC does not provide the email address in plain text. Instead, it is hashed according to your specified function, either as MD5 or SHA1. To improve efficiency, the IBM Connections OSC provider designates any hashed email address as not available when the server returns no information for that address. This hashed email address is kept in memory for the life of the Microsoft Outlook process and is not requested again until Microsoft Outlook restarts.

    To enable the dynamic features for the IBM Connections OSC provider create the following registry settings described in detail in the topic IBM Connections 4 IBM Preferences and policies for the IBM Connections Desktop Plug-ins for Microsoft Windows.

    • Dynamic Contact Lookup . This dynamic feature will allow the authenticated user to lookup the picture, name, and job title for the OSC user.

    • Dynamic Contact Activites . This dynamic feature will allow the authenticated user to retrieve the activities for the OSC user.


    Configure the Profiles server to support feeds

    Configure the IBM Connections Profiles server to support dynamic feeds in Microsoft Outlook Social Connector.

    To configure support for dynamic feeds for an IBM Connections 4 server, you must edit properties in the profiles-types.xml and profiles-config.xml files.

    1. Navigate to the configuration files in the following location: WebSphere/AppServer/profiles/<AppSrv>/config/cells/<serverNodeCell>/LotusConnections-config.

    2. Edit the file profiles-types.xml in a text editor and add a <property> for the attribute hashEmail:

      <property>
      		<ref>hashEmail</ref>
      		<updatability>readwrite</updatability>
      		<hidden>false</hidden>
      		<fullTextIndexed>true</fullTextIndexed>
      	</property>

    3. Edit the file profiles-config.xml file in a text editor and Add a <simpleAttribute> to the <profileExtensionAttributes> element.

      <simpleAttribute extensionId="hashEmail" length="40"/>

    4. Save your changes and close the configuration files.

    5. Restart the connections server so the changes will take effect.

    6. Populate the new attribute. This is a sample of how to produce the hash with a simple Java method:

      String hash = hashString(email,"MD5");  // SHA-1 
      
         public static String hashString(String text, String alg) 
      throws NoSuchAlgorithmException, UnsupportedEncodingException
         {
            MessageDigest md = MessageDigest.getInstance(alg);
            md.update(text.getBytes("iso-8859-1"), 0, text.length());
            // convert the byte-array into a hex-string
            byte[] hash = md.digest();
            StringBuffer buf = new StringBuffer();
            for( int i=0; i < hash.length; i++ )
            {
               int b = hash[i];
               if( b < 0 )
                  b = 256 + b;
               if( b < 16 )
                  buf.append("0");
               buf.append(Integer.toHexString(b));
            }
            return buf.toString();
         }

      The result should be a web page with only the hashed email returned.


    IBM Connections Plug-in for Microsoft SharePoint

    The IBM Connections Plug-in for Microsoft SharePoint brings IBM Connections applications such as searching by tag, searching by profile, and viewing business cards, into the SharePoint environment. Install the IBM Connections Widget for Microsoft SharePoint so that Connections users can access documents from a SharePoint server.

    The IBM Connections Plug-in for Microsoft SharePoint provides the following applications:

    • Profiles search for finding people in your organization. If colleagues you find with a Profiles search are in your SharePoint directory, you can add them to your SharePoint group or site.

    • Business card for getting contact and social networking information about users in your organization. From the business card, you can create a mail message to this colleague or open their blog, bookmarks or full profile.

    • Tag cloud for finding content stored on IBM Connections servers. Clicking a tag launches a search that matches against all Connections services. For example, clicking a new-hire tag could return a community and a blog posting.

    • The IBM Connections Widget for Microsoft SharePoint is a widget you install separately on an IBM Connections server so that community members can upload, view and share documents stored on a Microsoft SharePoint server.

    To get started, download the plug-in from the IBM Connections catalog web site: https://greenhouse.lotus.com/catalog.


    Install the IBM Connections plug-in for Microsoft SharePoint 3.0.1.1

    The IBM Connections plug-in for Microsoft SharePoint brings IBM Connections features such as searching by tag, searching by profile, and viewing business cards, into the SharePoint environment.

    The IBM Connections plug-in for Microsoft SharePoint release 3.0.1.1 requires Microsoft SharePoint 2010.

    Install language packs for Microsoft SharePoint to the server farm before you install this plug-in. This allows the plug-in to automatically install language pack solutions for all the supported languages