IBM Connections 4: Administer Common Areas, Activities, Blogs, Bookmarks, Communities, Files



Administer common areas

Administer the common areas of IBM® Connections.


Administrator checklist

Consider tasks you might want to complete after installing IBM Connections and before users start using it.


Database and file system backup and maintenance


Recommended tasks to schedule

  1. No tasks can run while the search index is being built. You do not need to take action to create the initial search index; it is scheduled automatically as part of the installation program; just wait for one of the default indexing tasks to run. If you want to recreate the search index, you must stop all scheduled tasks first, and then you can recreate the index using one of these procedures:

    Recreating the Search index

    Users cannot use search while you recreate the index using this method.

    Create a background index

    Users can continue to use search while you recreate the index using this method.

  2. Schedule the following tasks:

    • Schedule PowerCube refreshes for the Metrics application.

    • For user directory maintenance:

      • To keep the Profiles data in sync with the source from which you populated it, schedule the sync_all_dns script to run nightly. See Synchronize source changes such as LDAP with Profiles for more details.

        If you made any customizations to the population process, schedule your custom synchronization script to run nightly instead.

      • If, when populating the database, you chose to identify managers, run the mark_managers program after synchronizing the information to keep manager/managed relationship information up-to-date. This information is reflected in the report-to chain that is displayed in the user interface.


Manage content

Consider enabling the following features:


Integrate with other products

.Consider integrating the following features:


Security considerations

Consider configuring the following features:


Customize the product

Consider adding the following customizations:


Testing the environment for production readiness


Administration tools

Use the wsadmin utility to edit configuration properties or run administrative commands.

The wsadmin utility is a tool provided with WebSphere Application Server that you can use to manage applications hosted by the WebSphere Application Server, including IBM Connections.

The wsadmin tool runs IBM Connections script-based commands that you enter into a wsadmin command session. Behind the scenes, these scripts are based on the Jython scripting language, and they invoke WebSphere Application Server and IBM Connections commands that do the actual work. These scripts can both change XML-based file values that control an application's configuration and run IBM Connections-supplied MBean commands, which are grouped into services that perform related tasks, such as managing application membership.

You can change the behavior of IBM Connections by using the wsadmin client to perform one of the following actions:

Edit configuration properties

These properties control configurable aspects of the applications and are stored in XML-formatted configuration files. When you change these types of properties, you must use scripts that check out the configuration file, make the change, and then check the configuration file back in. After checking in your changes, you must restart the servers for the changes to take effect. In a network deployment, you must also synchronize the nodes to propagate the changes across a cluster.

Run administrative commands

Run administrative commands to invoke MBean commands associated with the product applications. MBeans control the applications that run on the server. When you run an administrative command, you must start the Jython script interpreter, but you do not have to check out any configuration files nor restart the server. Your changes take effect immediately.

For more detailed information about the wsadmin tool, go to the IBM WebSphere Application Server information center at the following web site: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.base.doc/info/aes/ae/txml_scriptingep.html


Start the wsadmin client

Use the wsadmin client to make configuration changes to common IBM Connections settings and individual application settings.

The wsadmin client is a scripting environment that gets installed with IBM WebSphere Application Server. You can use Jython language scripts, that are installed with IBM Connections, to access and change properties that govern the IBM Connections configuration. You can configure common properties that apply across all applications, and you can configure properties that apply only to an individual application.

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


What to do next

See the common IBM Connections section and individual application sections for information about the properties that you can change.


Edit configuration files

You can edit configuration files in two ways: by editing configuration settings in the wsadmin client, or by editing the configuration XML files directly. In both cases, you must first check out the configuration files and later check them back in using the wsadmin client.

  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. Access the application configuration files:

    execfile("application_py_file")

    ...where application_py_file is one of the following:

    • IBM Connections-wide: connectionsConfig.py

    • Activities: activitiesAdmin.py

    • Blogs: blogsAdmin.py

    • Bookmarks: dogearAdmin.py

    • Communities: communitiesAdmin.py

    • Files: filesAdmin.py

    • Forums: forumsAdmin.py

    • Home Page: homepageAdmin.py

    • News: newsAdmin.py

    • Profiles: profilesAdmin.py

    • Search: searchAdmin.py

    • Wikis: wikisAdmin.py

    • Metrics: 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. This information is not used by the wsadmin client when you are making configuration changes.

  3. Check out the configuration file for the application using the following command:

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

    ...where:

    • service_name is one of the following:

      • IBM Connections-wide: LCConfigService

      • Activities: ActivitiesConfigService

      • Blogs: The configuration settings for the Blogs application are not made in a configuration file, so no files need to be checked out, updated, and checked back in for Blogs. Unlike the other applications, when you edit Blogs configuration properties, the changes are written directly to the Blogs database tables.

      • Bookmarks: DogearCellConfig

      • Communities: CommunitiesConfigService

      • Files: FilesConfigService

      • Forums: ForumsConfigService

      • Home Page: HomepageCellConfig

      • News: NewsCellConfig

      • Profiles: ProfilesConfigService

      • Search: SearchCellConfig

      • Wikis: WikisConfigService

      • Metrics: MetricsConfigService

    • working_directory is the temporary working directory to which the configuration XML and XSD files are copied by the checkOutConfig command. The XML file contains the configuration settings and the corresponding XSD files is used to validate the XML file. The files are kept in this working directory while you make changes to them using the updateConfig command. When you run the checkInConfig command, the updated configuration file is copied from the temporary directory to where these files are located and overwrites the existing XML file. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

      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, type the following command while in the wsadmin command processor:

        print AdminControl.getCell()

      This input parameter is case-dependent.

    For example:

    • Common IBM Connections properties:

        LCConfigService.checkOutConfig("C:/temp","foo01Cell01")

    • The events-config.xml file:

        LCConfigService.checkOutEventsConfig("/temp","foo01Cell01")

      This command is part of the LCConfig service and only checks out the events-config.xml file. See the topic Editing events-config.xml.

    • Activities:

      ActivitiesConfigService.checkOutConfig("/temp","foo01Cell01")

    • Bookmarks:

      DogearCellConfig.checkOutConfig("C:/temp","foo01Cell01")

    • Communities:

      CommunitiesConfigService.checkOutConfig("/temp","foo01Cell01")

    • Files:

      FilesConfigService.checkOutConfig("C:/temp","foo01Cell01")

    • Forums:

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

    • Home Page:

      HomepageCellConfig.checkOutConfig("/temp","foo01Cell01")

    • News repository:

      NewsCellConfig.checkOutConfig("/temp","foo01Cell01")

    • Profiles:

      ProfilesConfigService.checkOutConfig("C:/temp","foo01Cell01")

    • Search:

      SearchCellConfig.checkOutConfig("/temp","foo01Cell01")

    • Wikis:

      WikisConfigService.checkOutConfig("C:/temp","foo01Cell01")

    • Metrics

      MetricsConfigService.checkOutConfig("/temp","foo01Cell01") 

  4. Optional: If you want to see what the current values of the configuration properties are, use the following command to retrieve a list of them:

    service_name.showConfig()

    ...where service_name is one of the service names defined in step 4.

  5. Edit the values of the configuration properties that you want to change. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly.

    For example:

    service_name.updateConfig("property_name","new_value")
    See the documentation for the individual application sections to see a list of the configuration properties you can edit for that application.

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

  7. After making edits, check the configuration files back in :

    service_name.checkInConfig()

    ...where service_name is one of the service names defined in step 4. You do not need to perform this step for the Blogs application. To check in the events-config.xml file the command is LCConfigService.checkInEventsConfig().

    You must run the checkin during the same wsadmin session in which you ran the checkout command.

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

    synchAllNodes()

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

  10. Stop and restart the servers hosting the edited IBM Connections applications.

    If you changed any Blogs configuration settings, the changes were written directly into the Blogs database tables. Therefore, you do not need to stop and restart the server hosting the Blogs application for the changes to take effect.


Related tasks

  • Start the wsadmin client
  • Turning off active content filtering
  • Use the Profiles database as the user directory
  • Install and configuring the Lotus Quickr library widgets
  • Restrict forum topic editing to creators
  • Required post-customization step


    IBM Connections configuration property values

    Find out what configuration properties you can edit for each application. To figure out which properties are editable, do one of the following:

    • Refer to the topic which lists all of the configuration properties for an application.

    • Find the topic that describes the task to complete. Many of the tasks you can perform involve editing a configuration property; the rest are completed using administrative commands.
    Follow the related reference links to find a list of the configuration properties for each application.


    Related tasks

  • Access the News configuration file

  • Communities configuration properties
  • Profiles configuration properties
  • Common configuration properties
  • Activities configuration properties
  • IBM Connections configuration files
  • Files configuration properties
  • Wikis configuration properties
  • Administer Blogs using the wsadmin Client
  • Bookmarks configuration properties
  • Forums configuration properties
  • SearchCellConfig commands
  • SearchService commands


    IBM Connections configuration files

    Configuration files are XML-formatted files that store configuration information for IBM Connections.

    The following table lists the configuration files that are provided with IBM Connections and describes what they do.

    Table 1. IBM Connections configuration files

    Configuration file Description
    calendar-config.xml Stores properties that control the behavior of the Events widgets.
    communities-config.xml Stores properties that control the behavior of the Communities application.
    communities-policy.xml Defines the permission levels of different roles in the Communities application. For example, it might specify that owners in a public community can modify the community description or members in a private community can add bookmarks.
    contentreview-config.xml Defines settings for content moderation in the Blogs, Files, and Forums applications.
    directory.services.xml Stores properties that control the behavior of common directory services.
    dogear-config-cell.xml Stores properties that affect Bookmarks at the cell level, such as differentiating between intranet and internet sites.
    events-config.xml Stores properties that control how events are collected and managed.
    files-config.xml Stores properties that control the behavior of the Files application.
    forum-config.xml Stores properties that control the behavior of the Forums application.
    forum-policy.xml Defines the permission levels of different roles in the Forums application.
    gettingstarted-config.xml Stores properties that define the content of the Get Started tab in the home page.
    library-config.xml Stores properties that control the behavior of library widgets in the Communities application.
    LotusConnections-config.xml Stores properties that control common IBM Connections applications, such as the navigation bar links.
    media-gallery-config.xml Stores properties that control the behavior of the Media Gallery widget in the Communities application.
    metrics-config.xml Stores properties that control the behavior of the Metrics application.
    mime-files-config.xml Stores Multipurpose Internet Mail Extensions (MIME) type assignments for file extensions and icons in the Files application.
    mime-wikis-config.xml Stores Multipurpose Internet Mail Extensions (MIME) type assignments for file extensions and icons in the Wikis application.
    mobile-config.xml Stores properties that control the behavior of the IBM Connections Mobile service.
    news-config.xml Stores properties that control how information is cleaned up and synchronized in the news repository.
    notification-config.xml Stores properties that control email notifications across all of the applications.
    oa-config.xml Stores properties that affect Activities, such as managing uploaded files, defining which statistics to collect, and purging the trash.
    opensocial-config.xml Defines properties that affect the behavior of the OpenSocial service, and is used for the integration of OpenSocial gadgets.
    profiles-config.xml Stores properties that control the behavior of the Profiles application.
    profiles-policy.xml Stores properties that can enable or disable profiles on the basis of profile type and properties that control the behavior of status updates in Profiles.
    proxy-config.tpl Defines proxy server redirects for specific URL patterns. Using redirects, you can allow access to web sites that you deem to be safe or block access to web sites that you deem to be dangerous. This configuration file also defines rewrite rules that specify aliases for web addresses.
    search-config.xml Stores properties that control the behavior of the Search application.
    uiextensions-config.xml Stores properties that manage customization in the business card, Communities, the home page, and Profiles.
    widgets-config.xml Stores properties that control the behavior of the widgets that can be added to the Communities and Profiles applications.
    wikis-config.xml Stores properties that control the behavior of the Wikis application.
    XRDS.xml Standard definition document in XML format for the discovery of metadata about a resource.


    Related tasks

  • IBM Connections configuration property values


    Edit events-config.xml

    You can edit the events-config.xml file by checking it out with a command, and then editing it directly.

    The events configuration file stores properties that control how events are collected and managed. You can edit configuration properties for deploying event handlers and setting some media gallery configuration values. See the topics Deploying an event handler and Media gallery events-config.xml properties for more information.

    1. Start the wsadmin client.

    2. Access the IBM Connections configuration files:

      execfile("connectionsConfig.py")

    3. Check out the events-config.xml configuration file using the following command:

      LCConfigService.checkOutEventsConfig("<temp_directory>", "<cell_name>")

      ...where:

      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied by the checkOutEventsConfig command. The XML file contains the configuration settings and the corresponding XSD files is used to validate the XML file. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

        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, type the following command while in the wsadmin command processor:

        print AdminControl.getCell()

        This input parameter is case-dependent.

      For example:

      LCConfigService.checkOutEventsConfig("C:/temp","foo01Cell01")

    4. Navigate to the working directory you specified in Step 3, open the events-config.xml file, and edit the values of the configuration properties to change.

    5. After making edits, check the configuration files back in :

      LCConfigService.checkInEventsConfig("<temp_directory>", "<cell_name>")

      You must run the checkin during the same wsadmin session in which you ran the checkout command.

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

      synchAllNodes()

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

    8. Stop and restart the servers hosting the edited IBM Connections applications.


    Related tasks

  • Deploying an event handler

  • Change the media galleries J2C alias


    Change common configuration property values

    Configuration settings control how and when various common operations take place. You can edit the settings to change how IBM Connections behaves. Use the connectionsConfig script in the WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named LotusConnections-config.xml. Changes to common configuration settings require node synchronization and a restart of all the application servers.

    Some properties in LotusConnections-config.xml cannot be edited using this procedure. They cannot be edited using updateConfig command nor displayed using the showConfig command. Instead, check out the configuration file using the checkOutConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, be sure to save the file, and then open it 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. After fixing any errors, check the file back in using the checkInConfig command.

    How do you determine which properties you can edit using the wsadmin commands and which you cannot? Use the showConfig command. Return a listing of all the properties that can be edited using the updateConfig command and their current values.

    To change common configuration settings using wsadmin commands:

    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. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values : LCConfigService.showConfig()

    4. Enter the following command to change a common configuration setting: LCConfigService.updateConfig("property","value") where property is one of the editable IBM Connections configuration properties and value is the new value with which you want to set that property. See Common configuration properties for a complete list of editable properties. For example:

      LCConfigService.updateConfig("versionStamp","")

    5. Optional: Repeat the previous step once for each property setting to change.


    What to do next

    Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.


    Related tasks

  • Start the wsadmin client
  • Apply common configuration property changes
  • Expose email addresses
  • Turning off active content filtering
  • Disable an application
  • Hide email addresses
  • Enable virus scanning
  • Disable the social analytics service
  • Specify a list of fonts and colors users can use for bookmark lists


    Common configuration properties

    The common configuration properties for IBM Connections are stored in LotusConnections-config.xml. The properties are represented as XML elements.

    You can change the values of the properties in the following ways:

    • Use the updateConfig command from the wsadmin client. This is the preferred method for editing values of properties in the configuration file. When you use the wsadmin client to edit a property value, validation is performed on your change before the change is applied, which helps to prevent errors.

      Not all properties can be edited this way.

    • Edit the XML elements in the file directly using a text editor. This method is potentially more error prone. If you choose to edit the XML elements directly, you still must use the checkOutConfig wsadmin command to check out the configuration files and the checkInConfig wsadmin command to check LotusConnections-config.xml back in after you have made your updates. When you check the file in, validation runs on the edited file and you are informed if you introduced any errors. Fix any errors, save the file, and try to check it in again.
    While it is better to use the updateConfig command from the wsadmin client to edit the properties in the configuration file, some of the properties cannot be edited this way. The values of those properties must be changed by editing the XML file directly.

    How do you determine which properties you can edit using the wsadmin commands and which you cannot? You can use the showConfig wsadmin command. Return a listing of all the properties that can be edited using the wsadmin client.

    This topic outlines those properties that you can edit using the updateConfig command from the wsadmin client and those that you cannot.


    Properties that you can edit using the wsadmin client

    The following list defines the configuration properties that can be edited using the updateConfig command from the wsadmin client.

    activities.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    activities.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    activities.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    activities.enabled

    Specifies whether the ability to access the Activities application over HTTP is enabled. The property accepts the following values: true or false.

    activities.href

    Web address from which to access the Activities application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.
    Provide a fully-qualified domain name. This parameter is case-sensitive.

    activities.href.prefix

    Context root from which to access the application. For example: /activities.

    activities.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    activities.pcs.name.js.eval

    Label of the link that you click to access the Activities application from the business card.

    activities.pcs.url.pattern

    Web pattern of the link to the Activities application from the business card.

    activities.ssl.enabled

    Specifies whether the ability to access the Activities application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    activities.ssl.href

    Web address from which to access the Activities application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    allowedContent.contentType.enabled

    Specifies whether the active content filter removes flash animation files from entries in the Blogs and Wikis applications. Accepts the values: true or false. However, editing this value has no effect. See Configuring the active content filter for Blogs and Wikis for information about how to prevent flash from being added to entries in those applications.

    blogs.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    blogs.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    blogs.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    blogs.enabled

    Specifies whether the ability to access the Blogs application over HTTP is enabled. The property accepts the following values: true or false.

    blogs.href

    Web address from which to access the Blogs application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    blogs.href.prefix

    Context root from which to access the application. For example: /blogs.

    blogs.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    blogs.pcs.name.js.eval

    Label of the link that you click to access the Blogs application from the business card.

    blogs.pcs.url.pattern

    Web pattern of the link to the Blogs application from the business card.

    blogs.ssl.enabled

    Specifies whether the ability to access the Blogs application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    blogs.ssl.href

    Web address from which to access the Blogs application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    cognos.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    cognos.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    cognos.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    cognos.enabled

    Specifies whether the ability to access the Cognos application over HTTP is enabled. The property accepts the following values: true or false.

    cognos.href

    Web address from which to access the Cognos application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    cognos.href.prefix

    Context root from which to access the application. For example: /cognos.

    cognos.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    cognos.ssl.enabled

    Specifies whether the ability to access the Cognos application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling SSL in your environment. Disabling SSL is a complex, multi-step process and you should consult with IBM Support before attempting to do so.

    cognos.ssl.href

    Web address from which to access the Cognos application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    communities.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    communities.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    communities.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    communities.enabled

    Specifies whether the ability to access the Communities application over HTTP is enabled. The property accepts the following values: true or false.

    communities.href

    Web address from which to access the Communities application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    communities.href.prefix

    Context root from which to access the application. For example: /communities.

    communities.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    communities.pcs.name.js.eval

    Label of the link that you click to access the Communities application from the business card.

    communities.pcs.url.pattern

    Web pattern of the link to the Communities application from the business card.

    communities.ssl.enabled

    Specifies whether the ability to access the Communities application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    communities.ssl.href

    Web address from which to access the Communities application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    connections.blogs.feed.return401_fornopermission_toviewblog

    If the setting is present and set to True, then return a 401 error if a user does not have permission to view a blog entry, otherwise return a 403 error.

    connections.blogs.lastModifierDisabled

    Controls whether or not to display the last modifier information in blogs entries.

    connections.blogs.onlymembercanvote

    Specify "True" if you want to limit voting in an Ideation blog to the community members. Other users will still be able to recommend ideas.

    customAuthenticator.name

    Specifies the short name for the code to use to secure server to server communication. The options are:

    • DefaultAuthenticator: Uses the IBM LTPA token to secure the connection. This option is the default option.

    • SiteMinderAuthenticator: Uses a SiteMinder token to secure the connection.

    • TAMAuthenticator: Uses a Tivoli® Access Manager token to secure the connection.

    The customAuthenticator.ConnectionTimeout, customAuthenticator.CookieTimeout, customAuthenticator.DefaultMaxConnectionsPerHost, customAuthenticator.MaxTotalConnections, and customAuthenticator.SoTimeout properties were deprecated in version 3.

    deployment.id

    Unique identifier of the current deployment. This deployment ID is used by plug-ins and other API clients after the address of a deployment changes to determine whether the new address is the same deployment or not. The deployment ID is a unique value that is generated by the installer. Alternatively, you can assign an ID to a deployment. If you decide to assign the ID instead of using the ID generated by the installer, do the following things:

    1. Use the naming convention: the reversed domain name of the IBM Connections installation. For example: com.example.social-intranet.

    2. If the deployment moves from one installation or hostname to another, set the value of the new deployment ID to the same value as the original deployment.
    The deployment.id value is exposed within the atom:id of the /serviceconfigs API feed available from all IBM Connections services.

    dogear.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    dogear.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    dogear.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    dogear.enabled

    Specifies whether the ability to access the Bookmarks application over HTTP is enabled. The property accepts the following values: true or false.

    dogear.href

    Web address from which to access the Bookmarks application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    dogear.href.prefix

    Context root from which to access the application. For example: /dogear.

    dogear.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    dogear.pcs.name.js.eval

    Label of the link that you click to access the Bookmarks application from the business card.

    dogear.pcs.url.pattern

    Web pattern of the link to the Bookmarks application from the business card.

    dogear.ssl.href

    Web address from which to access the Bookmarks application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    dogear.ssl.enabled

    Specifies whether the ability to access the Bookmarks application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    dynamicHosts.enabled

    Specifies whether a reverse proxy is configured for IBM Connections. The property accepts the following values: true or false.

    dynamicHosts.href

    Web address from which to access IBM Connections through a reverse proxy over HTTP.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    dynamicHosts.ssl_href

    Web address from which to access IBM Connections through a reverse proxy over secure HTTP (HTTPS).

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    email.expose.enabled

    Specifies whether or not to display user email addresses in the product user interface, and product-generated notifications or URLs. The property accepts the following values: true or false.

    files.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    files.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    files.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    files.enabled

    Specifies whether the ability to access the Files application over HTTP is enabled. The property accepts the following values: true or false.

    files.href

    Web address from which to access the Files application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    files.href.prefix

    Context root from which to access the application. For example: /files.

    files.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    files.pcs.name.js.eval

    Label of the link that you click to access the Files application from the business card.

    files.pcs.url.pattern

    Web pattern of the link to the Files application from the business card.

    files.ssl.enabled

    Specifies whether the ability to access the Files application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    files.ssl.href

    Web address from which to access the Files application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    force.conf.comm.enabled

    Specifies whether access to the IBM Connections applications can only be reached over a secure HTTP channel (HTTPS).The property accepts the following values: true or false. If you set the value of this property to true, the value of the profiles.directory.service.extension.href or communities.directory.service.extension.href properties, if Profiles or Communities directory service integration is enabled, must be specified as a secure HTTP (HTTPS) web address.

    forums.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    forums.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    forums.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    forums.enabled

    Specifies whether the ability to access the Forums application over HTTP is enabled. The property accepts the following values: true or false.

    forums.href

    Web address from which to access the Forums application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    forums.href.prefix

    Context root from which to access the application. For example: /forums.

    forums.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    forums.pcs.name.js.eval

    Label of the link that you click to access the Forums application from the business card.

    forums.pcs.url.pattern

    Web pattern of the link to the Forums application from the business card.

    forums.ssl.enabled

    Specifies whether the ability to access the Forums application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    forums.ssl.href

    Web address from which to access the Forums application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    help.enabled

    Specifies whether the ability to access the help system over HTTP is enabled. The property accepts the following values: true or false.

    help.href

    Web address from which to access the help system over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    help.href.prefix

    Context root from which to access the help system. For example: /activities.

    help.interService.href

    Web address from which other IBM Connections applications access the help system. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    help.ssl.enabled

    Specifies whether the ability to access the help system over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    help.ssl.href

    Web address from which to access the help system over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    homepage.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    homepage.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    homepage.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    homepage.enabled

    Specifies whether the ability to access the Home page application over HTTP is enabled. The property accepts the following values: true or false.

    homepage.href

    Web address from which to access the Home page application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    homepage.href.prefix

    Context root from which to access the application. For example: /homepage.

    homepage.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    homepage.ssl.enabled

    Specifies whether the ability to access the Home page application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    homepage.ssl.href

    Web address from which to access the Home page application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    metrics.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    metrics.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    metrics.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    metrics.enabled

    Specifies whether the ability to access the Metrics application over HTTP is enabled. The property accepts the following values: true or false.

    metrics.href

    Web address from which to access the Metrics application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    metrics.href.prefix

    Context root from which to access the application. For example: /metrics.

    metrics.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    metrics.ssl.enabled

    Specifies whether the ability to access the Metrics application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling SSL in your environment. Disabling SSL is a complex, multi-step process and you should consult with IBM Support before attempting to perform this step.

    metrics.ssl.href

    Web address from which to access the Metrics application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    mobile.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    mobile.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    mobile.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    mobile.enabled

    Specifies whether the ability to access IBM Connections from a mobile device over HTTP is enabled. The property accepts the following values: true or false.

    mobile.href

    Web address from which to access IBM Connections from a mobile device over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    mobile.href.prefix

    Context root from which to access IBM Connections from a mobile device. For example: /mobile.

    mobile.interService.href

    Web address from which IBM Connections applications access one another from a mobile device. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    mobile.ssl.enabled

    Specifies whether the ability to access IBM Connections from a mobile device over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    mobile.ssl.href

    Web address from which to access IBM Connections from a mobile device over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    news.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    news.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    news.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    news.enabled

    Specifies whether the ability to access Home page Updates over HTTP is enabled. The property accepts the following values: true or false.

    news.href

    Web address from which to access Home page Updates over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    news.href.prefix

    Context root from which to access the application. For example: /news.

    news.interService.href

    Web address from which other IBM Connections applications access Home page Updates. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    news.ssl.enabled

    Specifies whether the ability to access Home page Updates over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    news.ssl.href

    Web address from which to access Home page Updates over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    personTag.href

    Web address from which to access the business card service over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    personTag.href.prefix

    Context root from which to access the business card.

    personTag.interService.href

    Web address from which other IBM Connections applications access the business card. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    personTag.enabled

    Specifies whether the ability to access the business card over HTTP is enabled. The property accepts the following values: true or false.

    personTag.ssl.enabled

    Specifies whether the ability to access the business card over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    personTag.ssl.href

    Web address from which to access the business card service over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    profiles.directory.service.extension.enabled

    Identifies whether Profiles directory service integration is enabled. When Profiles directory service integration is enabled, IBM Connections retrieves user information from the Profiles database instead of the LDAP server. The property accepts a value of true or false. It is set to false by default. If you install the Profiles application and specify to use the Profiles database as the user directory during the installation, this value is automatically set to true.

    Group information can be retrieved from the LDAP directory only.

    The profiles.directory.service.extension.auth, profiles.directory.service.extension.auth.alias, communities.directory.service.extension.auth, communities.directory.service.extension.auth.alias, and communities.directory.service.extension.enabled properties can not be edited using wsadmin commands starting in version 3.

    profiles.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    profiles.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    profiles.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    profiles.enabled

    Specifies whether the ability to access the Profiles application over HTTP is enabled. The property accepts the following values: true or false.

    profiles.href

    Web address from which to access the Profiles application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    profiles.href.prefix

    Context root from which to access the application. For example: /profiles.

    profiles.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    profiles.pcs.name.js.eval

    Label of the link that you click to access the Profiles application from the business card.

    profiles.pcs.url.pattern

    Web pattern of the link to the Profiles application from the business card.

    profiles.ssl.enabled

    Specifies whether the ability to access the Profiles application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    profiles.ssl.href

    Web address from which to access the Profiles application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    quickr.enabled

    Specifies whether the ability to access a link to a Lotus Quickr. place from the business card over HTTP is enabled. The property accepts a Boolean value; the options are true and false. See Using business cards in the Administering Profiles section of the product documentation for more information about these Lotus Quickr properties.

    quickr.href

    Web address from which to access a Lotus Quickr place over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    quickr.href.prefix

    Context root from which to access Sametime awareness services. For example: /quickr.

    quickr.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    quickr.pcs.name.js.eval

    Label of the link that you click to access the Lotus Quickr place from the business card.

    quickr.pcs.url.pattern

    Web pattern of the link to the Lotus Quickr place from the business card.

    quickr.ssl.enabled

    Specifies whether the ability to access a link to a Lotus Quickr place from the business card over secure HTTP (HTTPS) is enabled. The property accepts the following values: true and false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    quickr.ssl.href

    Web address from which to access a Lotus Quickr place over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    sametimeLinks.anonymousLogin.enabled

    Boolean. Specifies whether the ability to access the Sametime Links resources anonymously is enabled. Options are true and false.

    Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Add Sametime awareness to IBM Connections.

    sametimeLinks.enabled

    Boolean. Specifies whether the ability to connect to the Sametime Links resources over HTTP is enabled. Options are true and false.

    Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Add Sametime awareness to IBM Connections.

    sametimeLinks.href

    Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed over the HTTP protocol. Set the protocol (HTTP), server name, and optionally the port number.

    Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Add Sametime awareness to IBM Connections.

    sametimeLinks.href.prefix

    Context root from which to access the application. For example: /sametime.

    sametimeLinks.interService.href

    Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed from other IBM Connections applications.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    sametimeLinks.ssl.enabled

    Boolean. Specifies whether the ability to connect to the Sametime Links resources over HTTPS is enabled. The property accepts the following values: true or false.

    Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Add Sametime awareness to IBM Connections.

    sametimeLinks.ssl.href

    Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed over the HTTPS protocol. Set the protocol (HTTPS), server name, and optionally the port number.

    Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Add Sametime awareness to IBM Connections.

    sametimeProxy.enabled

    Boolean. Specifies whether the ability to connect to the Sametime proxy resources over HTTP is enabled. Options are true and false.

    sametimeProxy.href

    Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed over the HTTP protocol. Set the protocol (HTTP), server name, and optionally the port number.

    sametimeProxy.interService.href

    Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed from other IBM Connections applications.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    sametimeProxy.ssl.enabled

    Boolean. Specifies whether the ability to connect to the Sametime proxy resources over HTTPS is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    sametimeProxy.ssl.href

    Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed over the HTTPS protocol. Set the protocol (HTTPS), server name, and optionally the port number.

    sand.enabled

    Boolean. Specifies whether the ability to connect to the Social Networking and Discovery resources over HTTP is enabled. Options are true and false.

    sand.href

    Web address from which the Social Networking and Discovery resources can be accessed over the HTTP protocol. Set the protocol (HTTP), server name, and optionally the port number.

    sand.href.prefix

    Context root from which to access the application. For example: /sand.

    sand.ssl.enabled

    Boolean. Specifies whether the ability to connect to the Social Networking and Discovery resources over HTTPS is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    sand.ssl.href

    Web address from which the Social Networking and Discovery resources can be accessed over the HTTPS protocol. Set the protocol (HTTPS), server name, and optionally the port number.

    search.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    This property has no default value and typically should not be modified from installed defaults in a cluster configuration.

    search.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This property has no default value.

    search.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    This property has no default value.

    search.enabled

    Specifies whether the ability to access Advanced Search over HTTP is enabled. The property accepts the following values: true or false.

    search.href

    Web address from which to access Advanced Search over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    search.href.prefix

    Context root from which to access the application. For example: /search.

    search.ignore.punctuation.enabled

    Specifies whether or not to ignore punctuation in search terms. This property accepts the following values: true or false. When set to true, punctuation in search terms is ignored. For example, for an occurrence of the term I.B.M, the terms I.B.M. and IBM are stored in the index. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.

    search.interService.href

    Web address from which other IBM Connections applications access Advanced Search. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    search.language.sensitivity.enabled

    Specifies whether or not to turn on language sensitivity in search. The property accepts the following values: true or false. When set to true, the product supports accent insensitive searches. For example, for an occurrence of á, the product stores á and alt. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.

    search.one.to.two.mapping.enabled

    Specifies whether or not to perform one-to-two mapping on search terms. The property accepts the following values: true or false. When set to true, the product performs a one-to-two mapping on search terms. For example, for an occurrence of the term Mü the terms Müand Mueller are stored in the index. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.

    search.Queue_Max

    Number of connections refused before a subsequent transaction is allowed. This property is used only when Search is installed on a different server from the server hosting the application in which a search is being performed. If the Search server is not responding, a queue of requests is created. The length of the queue is defined by the value of this property. Only the last search request in the queue is sent to the Search server. When the search server starts responding, the queue is no longer used. The default value is 10.

    search.ssl.enabled

    Specifies whether the ability to access Advanced Search over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.

    search.ssl.href

    Web address from which to access Advanced Search over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    search.Transaction_Max

    Maximum number of transactions allowed. This property is used only when Search is installed on a different server from the server hosting the application in which a search is being performed. This setting prevents the server that is preforming the search from running out of memory due to the Search server not responding. The default value is 20.

    seedlistSets.maximumPageSize

    Maximum number of items on the search return page. The value must be greater than or equal to 100.

    seedlistSets.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. Connections 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 Connections 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 this value is higher than the span of days between incremental crawls. For example, if incremental crawls happen every four days, make sure this value is higher than 4. This ensures that incremental crawls capture all deletion records.

    use.richTextEditor.inBookmarklet.enabled

    Specifies whether the description field on the Edit Bookmark form that is displayed when you create a bookmark using the Add Bookmark button is a rich text or plain text field. The form loads more quickly with a plain text description field. The field is plain text by default. The property accepts the following values: true or false.

    versionStamp

    Defines a version number that is stored as an internal URL reference for static content on the product's web pages. After customizing the product or installing an interim fix, the administrator increments the value of this property to prevent end users from having to clear their web browser cache to see the latest changes. When updating the value of this property, pass a null value to make the server assign a time stamp value to it. If you choose to specify your own time stamp, use the following syntax: yyyyMMdd.HHmmss For example: 20090720.034448.

    wikis.ejb.cluster

    Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

    wikis.ejb.port

    WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

    wikis.ejb.server

    Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

    wikis.enabled

    Specifies whether the ability to access the Wikis application over HTTP is enabled. The property accepts the following values: true or false.

    wikis.href

    Web address from which to access the Wikis application over HTTP. Set the protocol (HTTP), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    wikis.href.prefix

    Context root from which to access the application. For example: /wikis.

    wikis.interService.href

    Web address from which other IBM Connections applications access this application. Set the protocol and server name.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    wikis.pcs.name.js.eval

    Label of the link that you click to access the Wikis application from the business card.

    wikis.pcs.url.pattern

    Web pattern of the link to the Wikis application from the business card.

    wikis.ssl.href

    Web address from which to access the Wikis application over secure HTTP (HTTPS). Set the protocol (HTTPS), server name, and optionally the port number.

    Provide a fully-qualified domain name. This parameter is case-sensitive.

    wikis.ssl.enabled

    Specifies whether the ability to access the Wikis application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.


    Properties that can only change by editing the XML file directly

    The following properties are also stored in LotusConnections-config.xml, but cannot be edited using the updateConfig command from the wsadmin client. Instead, check out the configuration file using the wsadmin client LCConfigService.checkOutConfig command. Then, navigate to the temp directory and open the checked-out file, and then edit the property in a text editor. When you have finished editing the file, check in the updated file using the LCConfigService.checkInConfig command. Validation runs on the file. If an error is found, you are notified and can make any necessary changes, save the file, and try to check it in again.

    • Virus scanning properties:

      <!-- 
        To enable virus scanning, first delete the empty avFilter element.
        Then, uncomment the avFilter in the comment and replace hostname as 
        appropriate
        Replace myScannerService with the appropriate name for your scanner 
        (eg AVSCAN for Symantec, RESPMOD for McAfee)
      -->
          <avFilter>
          </avFilter>
          <!-- <avFilter class="AVScannerICAP">
              <property>av.scanner.servers=myscanner.host.com</property>
              <property>exception.on.virus=yes</property>
              <property>av.scanner.service=myScannerService</property>
              <property>av.chunk.size=50000</property>
              <property>first.read.timeout=120000</property>
          </avFilter>
      	   -->
      The XML elements and attributes function as follows:

      av.chunk.size

      Transfer rate. Specify an integer in bytes. This property is not displayed in the configuration file by default. If you want to specify a value for it, add it.

      av.scanner.servers

      Defines the virus scanning server to use to scan uploaded files for viruses. Replace my.virus.scanning.server.com with a list of one or more of the virus scanning servers used by your organization. Separated multiple servers with a comma. For example:

      <property>av.scanner.servers=ssoc.acme.com</property> or <property>av.scanner.servers=ssoc1.acme.com,ssoc2.acme.com</property>

      av.scanner.service

      Defines the service name used by the anti virus scanner. Set this to AVSCAN for Symantec, and RESPMOD for McAfee.

      exception.on.virus

      Defines what to do when a virus is found. This property should always be set to yes.

      first.read.timeout

      Length of time for the timeout. Specify an integer in milliseconds. This property is not displayed in the configuration file by default. If you want to specify a value for it, add it.

    • Display language customization support:

      <languageSelector 
       enabled="true" 
       defaultLanguage="" 
       cookieName="conxnsCookie"
       cookieDomain=".acme.com" 
       usePermanentCookie="true">
        <language lang="en">English</language>
        <language lang="zh">\u4e2d\u6587\uff08\u7b80\u4f53\uff09</language>
        <language lang="zh_tw">\u4e2d\u6587 (\u7e41\u9ad4)</language>
        <language lang="ja">\u65e5\u672c\u8a9e</language>
        <language lang="ko">\ud55c\uad6d\uc5b4</language>
        <language lang="fr">Fran\u00e7ais</language>
        <language lang="de">Deutsch</language>
        <language lang="it">Italiano</language>
        <language lang="es">Espa\u00f1ol</language>
        <language lang="pt_br">Portugu\u00eas (Brasil)</language>
        <language lang="cs">\u010ce\u0161tina</language>
        <language lang="da">Dansk</language>
        <language lang="nl">Nederlands</language>
        <language lang="fi">suomi</language>
        <language lang="el">\u0395\u03bb\u03bb\u03b7\u03bd\u03b9\u03ba\u03ac</language>
        <language lang="hu">Magyar</language>
        <language lang="no">Norsk (Bokm\u00e5l)</language>
        <language lang="pl">polski</language>
        <language lang="pt">Portugu\u00eas (Portugal)</language>
        <language lang="ru">\u0420\u0443\u0441\u0441\u043a\u0438\u0439</language>
        <language lang="sl">sloven..ina</language>
        <language lang="sv">Svenska</language>
        <language lang="tr">T\u00fcrk\u00e7e</language>
        <language lang="iw">\u05e2\u05d1\u05e8\u05d9\u05ea</language>
        <language lang="ar">\u200f\u0627\u0644\u0639\u0631\u0628\u064a\u0629\u200f</language>
        <language lang="ca">Catal\u00e0</language>
        <language lang="kk">\u049a\u0430\u0437\u0430\u049b\u0448\u0430</language>
        <language lang="th">\u0e44\u0e17\u0e22</language>
      </languageSelector>
      The following table identifies the languages based on the lang property value:

      Table 2. Language code values

      Lang property value Language
      ar Arabic
      ca Catalan
      cs Czech
      da Danish
      de German
      en English
      el Greek
      es Spanish
      fi Finnish
      fr French
      hu Hungarian
      it Italian
      iw Hebrew
      ja Japanese
      kk Kazakh
      ko Korean
      nl Dutch
      no Norwegian
      pl Polish
      pt Portuguese
      pt_br Brazilian Portuguese
      ru Russian
      sl Slovenian
      sv Swedish
      th Thai
      tr Turkish
      zh Simplified Chinese
      zh_tw Traditional Chinese
      The XML entries and attributes function as follows:

      cookieDomain

      Optional. Defines a cookie domain which enables the language setting to work across multiple servers. Specify a valid, fully qualified domain name of the server where the cookie resides. For example: .acme.com. Note that the domain name begins with a period (.). If you specify this cookie domain, the language setting would work for Profiles on profiles.acme.com and for Activities on activities.acme.com. By default, no cookie domain is used.

      cookieName

      Optional. The default cookie name is lcLang. If you want to use a different name for the cookie, specify a new name in this attribute.

      defaultLanguage

      By default, the product user interface is displayed in the language specified as the preferred language by the web browser. You can use the defaultLanguage attribute to define a fallback language in which to display the user interface if the preferred language specified by the browser is not included in the language elements list. It there are no language elements specified, the language specified in this attribute is the only language in which IBM Connections is displayed. Set the language using the exact strings listed in the example.

      enabled

      Specifies whether to allow users to change the display language of the product. This attribute accepts a Boolean value; the options are true and false.

      language

      Each <language> element represents a language that you want users to be able to select from the language selector drop-down list in the product navigation bar. Add and remove language elements to create a full list of the languages you want to make available. Include a lang attribute that specifies the ISO country code associated with the language. Provide the language name as it should be displayed in the list as the value of the language element. Specify non-Latin characters in Javascript-escaped unicode format. You can only specify languages that the product supports. For a list of languages, see Supported languages.

      Also, remove any of the language elements that are included in the languageSelector element by default if you do not want them to be displayed from the drop-down list of language options in the product menu bar. They are English, French, Chinese, and Arabic.

      usePermanentCookie

      Optional. Specifies whether you want the cookie to persist for longer than the duration of the web browser session. This attribute accepts a Boolean value; the options are true and false. If you set the attribute to true, it creates a persistent cookie that has an expiry date of ten years from the date it was created.

    • Active content filter:

      For some applications, you can customize the configuration file that is used by the active content filter. To do so, manually edit the acf_config_file attribute of the <sloc:serviceReference> element representing the application. See Configuring the active content filter for Blogs, Wikis, and Forums or Configuring the active content filter for Activities, Communities, and Bookmarks for more details.


    Related

  • Use Profiles and Communities business cards
  • Supported languages

  • Add Sametime awareness though the Sametime client
  • Start the wsadmin client
  • Apply common configuration property changes
  • IBM Connections configuration property values
  • Disable the social analytics service
  • Delete the index

  • IBM Connections configuration error messages


    Apply common configuration property changes

    After you have edited the configuration properties that are common to all IBM Connections applications, check the changed configuration files in, and restart the servers to apply the changes.

    You must perform the check in during the same wsadmin session in which you checked out the files for the changes that you made to take effect.

    1. Open a command window and start the wsadmin command line tool as described in the topic, Starting the wsadmin client.

    2. Optional: If you want to confirm the changes that you made before checking the configuration files in, you can list the configuration settings and values :

      LCConfigService.showConfig()

    3. 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.

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

      LCConfigService.checkInConfig()

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

      synchAllNodes()

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

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


    Related tasks

  • Expose email addresses
  • Use the Profiles database as the user directory
  • Apply property changes in Activities
  • Apply property changes
  • Apply property changes in Communities
  • Apply Files property changes
  • Apply property changes in Forums
  • Apply property changes in the News repository
  • Apply property changes in Profiles
  • Apply Wikis property changes
  • Hide email addresses
  • Enable virus scanning
  • Disable the social analytics service
  • Required post-customization step

  • Profiles configuration properties
  • Common configuration properties
  • Activities configuration properties


    Run administrative commands

    Use administrative commands to run tasks on the server.

    Administrative commands interact with the IBM Connections applications and their resources through scripts. These scripts use the AdminControl object available in WebSphere Application Server wsadmin tool to interact with the application servers. Each script uses managed Java. beans (MBeans) to get and set server administration properties.

    Unlike with configuration properties, when you use these commands to change server administration properties, you do not have to check out any files nor restart the server for the changes to take effect. You do, however, need to understand a bit about how to manipulate Java objects. When you perform server operations using the commands, the item, member information, and access level information are represented as hash tables. Many of the commands, in fact, return a vector of hash tables that represent application resources. Commands you can use to perform tasks, such as deleting, archiving, and restoring, all take parameters formatted as vectors of hash tables. You can then pass information in the hash tables to commands that perform server tasks.

    When an administrative command is invoked, a SOAP request is made to the IBM Connections application, for example Activities. The number of seconds that the wsadmin client waits for a response to a SOAP request is specified in the com.ibm.SOAP.requestTimeout property specified in the soap.client.props file in the following directory: {WAS_HOME}\profiles\{PROFILE_NAME}\properties. If a command takes longer to complete than the value of the com.ibm.SOAP.requestTimeout property, an error is displayed on the wsadmin console, and any value returned from the invoked method is lost. The command continues to be processed by the application, but the connection that the application had to the client that invoked it is gone. This detail is important to note because some commands take a long time to run. For example, in a system with a large number of Activities, the ActivityService.fetchActivities() command can take a long time to complete. You can monitor the status of these operations by scanning the SystemOut.log file for success and failure messages.

    To increase the time interval that passes before a request fails, edit the com.ibm.SOAP.requestTimeout property in the soap.client.props file. This property is a configuration property, so after editing the property, you must restart the server for the change to take effect.

    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 following command to access the application configuration files:

      execfile("application_py_file")

      ...where application_py_file is one of the following:

      • IBM Connections-wide: connectionsConfig.py

      • OAuth: oauthAdmin.py

      • Activities: activitiesAdmin.py

      • Blogs: blogsAdmin.py

      • Bookmarks: dogearAdmin.py

      • Communities: communitiesAdmin.py

      • Files: filesAdmin.py

      • Forums: forumsAdmin.py

      • Home Page: homepageAdmin.py

      • Metrics: metricsAdmin.py

      • News: newsAdmin.py

      • Profiles: profilesAdmin.py

      • Search: searchAdmin.py

      • Wikis: wikisAdmin.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.

    3. Edit administrative properties and perform administrative tasks using the administrative commands documented in the individual application sections of the product documentation.
  • Activities administrative commands
  • Communities administrative commands
  • Files administrative commands
  • Forums administrative commands
  • News administrative commands
  • Profiles administrative commands
  • Wikis administrative commands
  • Manage the client application list


    Start or stop Connections applications

    IBM Connections applications, such as Files, are WebSphere Enterprise Applications. Start or stop them in the WebSphere Administrative Console as you would any other WebSphere application.

    For complete documentation on starting and stopping WebSphere applications, see the topic Start or stop enterprise applications in the IBM WebSphere Application Server information center.

    1. Log in to the WebSphere® Administrative Console on the IBM® Connections server.

    2. Click Applications > Application Types > WebSphere enterprise applications in the console navigation tree.

    3. Select the check box for the application you want started or stopped.

    4. Click a button:

      Option Description
      Start Runs the application and changes the state of the application to Started. The status is changed to partially started if not all servers on which the application is deployed are running.

      Stop Stops the processing of the application and changes the state of the application to Stopped.
      To restart a running application, select the application you want to restart, click Stop and then click Start.

    System maintenance

    Make sure IBM Connections works properly in your particular environment.


    Change WebSphere Application Server environment variables

    The directory paths to IBM Connections application data and other resources are given associated WebSphere Application Server environment variables. If you change default paths in your environment, you must update the variables.

    The environment variables are given default values unless you change them during the product installation. See WebSphere Application Server environment variables for a list of the default values.

    If, for example, you decide to move the directory associated with an application, such as the index directory for Bookmarks, to a different system driver, you can do so, but you must also update the environment variable defined for the Bookmarks index directory in WebSphere Application Server. It is important to update the environment variables because the application configuration files that define the behavior of the applications reference the directory paths using these environment variables.

    1. Use an administrator ID, log into the WebSphere Application Server Integrated Console associated with the profile to which you installed IBM Connections. If you installed the applications to multiple WebSphere Application Server profiles, log into the console associated with the appropriate profile.

    2. Expand Environment, and then click WebSphere Variables.

    3. Find the environment variable to change and edit it from the list.

    4. Save and apply your changes, and then restart the server.


    Related tasks

  • Set the timeout for seedlist requests


    WebSphere Application Server environment variables

    Unless you change the directory paths during the installation, a set of default IBM WebSphere Application Server environment variables are defined for the IBM Connections application directories. These variables are referenced from the configuration files associated with the applications.

    The following tables list the default environment variables defined for application directories on WebSphere Application Server, and for the customization base directory.

    It is common practice for production deployments to use more than one shared content store to avoid issues when all the applications attempt to read or write to the same attached device. In this scenario, you might need to change the environment variables to match your deployment. When doing so, you need to update the properties in the IBM Connections configuration engine at the same time; otherwise, the utility for export/import will not function properly. For more information about IBM Connections configuration engine properties, see ConfigEngine properties.

    Table 3. Activities default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    ACTIVITIES_CONTENT_DIR File upload directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/activities/content

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\activities\content

    ACTIVITIES_HOME Directory in which Activities was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/activities/activities/activities

    Microsoft

    Windows: C\Program Files\IBM\Connections\activities\activities\activities

    ACTIVITIES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product. For example: opt/ibm/db2/java
    ACTIVITIES_STATS_DIR Statistics directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/activities/statistics

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\activities\statistics

    Table 4. Blogs default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    BLOGS_CONTENT_DIR File upload directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/blogs/upload

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\blogs\upload

    BLOGS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    BLOGS_HOME Directory in which Blogs was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/blogs/blogs/blogs

    Microsoft

    Windows: C:\Program Files\IBM\Connections\blogs\blogs\blogs

    Table 5. Bookmarks default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    DOGEAR_FAVICON_DIR Icons upload directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/dogear/favorite

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\dogear\favorite

    DOGEAR_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    DOGEAR_HOME Directory in which the Bookmarks application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/dogear/dogear/dogear

    Microsoft

    Windows: C:\Program Files\IBM\Connections\dogear\dogear\dogear

    Table 6. Communities default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    CATALOG_INDEX_DIR Directory in which the index is stored / local

    AIX and Linux: /opt/IBM/Connections/data/local/catalog/index

    Microsoft

    Windows: C\Program Files\IBM\Connections\data\local\catalog\index

    CATALOG_REPLICATION_DIR Directory in which the delta index files are stored / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/catalog/indexReplication

    Microsoft

    Windows: C\Program Files\IBM\Connections\data\shared\catalog\indexReplication

    COMMUNITIES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    COMMUNITIES_HOME Directory in which Communities was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/communities/communities/communities

    Microsoft

    Windows: C:\Program Files\IBM\Connections\communities\communities\communities

    Table 7. Customization default WebSphere Application Server environment variable

    Variable name Description / Local or shared* Default value
    CONNECTIONS_CUSTOMIZATION_PATH Customization directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/customization

    Microsoft

    Windows: C:\Program files\IBM\Connections\data\shared\customization

    Table 8. Files default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    FILES_CONTENT_DIR File upload directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/files/upload

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\files\upload

    Files_HOME Directory in which the Files application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/files/files/files

    Microsoft

    Windows: C:\Program Files\IBM\Connections\files\files\files

    Files_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.

    Table 9. Forums default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    FORUM_CONTENT_DIR Forum content directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/forums/content

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\forums\content

    FORUM_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    FORUM_HOME Directory in which the Forum application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/forum/forum/forum

    Microsoft

    Windows: C:\Program Files\IBM\Connections\forum\forum\forum

    Table 10. Home page default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    Homepage_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    Homepage_HOME Directory in which the Home page application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/homepage/homepage/homepage

    Microsoft

    Windows: C:\Program Files\IBM\Connections\homepage\homepage\homepage

    Table 11. Metrics default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    METRICS_HOME Directory in which the Metrics application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/metrics/metrics/metrics

    Microsoft

    Windows: C:\Program Files\IBM\Connections\metrics\metrics\metrics

    METRICS_JDBC_DRIVER_HOME JDBC driver JAR files directory / local. JDBC driver library path specified when you installed the product.

    Table 12. News default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    ACTIVITY_STREAM_SEARCH_INDEX_DIR Directory in which the index for Activity Stream search is stored / local

    AIX and Linux: /opt/IBM/Connections/DataLocal/news/search/index

    Microsoft

    Windows: C:\Program Files\IBM\Connections\DataLocal\news\search\index

    ACTIVITY_STREAM_SEARCH_REPLICATION_DIR Replication directory for Activity Stream Search / shared

    AIX and Linux: /opt/IBM/Connections/data/news/search/indexReplication/ActivityStream

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\news\search\indexReplication\ActivityStream

    AUDIT_FILE_ROOT_DIR Stores temporary attachments for audit purposes. / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/audit

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\audit

    NEWS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    NEWS_HOME Directory in which the News application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/news/news/news

    Microsoft

    Windows: C:\Program Files\IBM\Connections\news\news\news

    Table 13. Profiles default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    PROFILES_CACHE_DIR Cache directory / local

    AIX and Linux: /opt/IBM/Connections/data/local/profiles/cache

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\local\profiles\cache

    PROFILES_HOME Directory in which the Profiles application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/profiles/profiles/profiles

    Microsoft

    Windows: C:\Program Files\IBM\Connections\profiles\profiles\profiles

    PROFILES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.
    PROFILES_STATS_DIR Statistics directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/profiles/statistics

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\profiles\statistics

    Table 14. Search default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    CRAWLER_PAGE_PERSISTENCE_DIR Directory used to store the seedlist pages persisted during crawing. / local

    AIX and Linux: /opt/IBM/Connections/data/local/search/persistence

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\local\search\persistence

    EXTRACTED_FILE_STORE Directory used to store the extracted file content. / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/search/extracted

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\search\extracted

    FILE_CONTENT_CONVERSION Platform-specific path to the executable that will be called for text extraction from files at indexing time. / local

    AIX and Linux: /opt/IBM/WebSphere/Connections/data/local/search/stellent/dcs/oiexport/exporter

    Microsoft

    Windows: Program Files\IBM\Connections\data\local\search\stellent\dcs\oiexport\exporter

    SEARCH_DICTIONARY_DIR Dictionary directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/search/dictionary

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\search\dictionary

    SEARCH_HOME Directory in which Search was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/search/search/search

    Microsoft

    Windows: C:\Program Files\IBM\Connections\search\search\search

    SEARCH_INDEX_DIR Index directory / local

    AIX and Linux: /opt/IBM/Connections/data/local/search/index

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\local\search\index

    SEARCH_INDEX_BACKUP_DIR Backup index directory / local

    AIX and Linux: /opt/IBM/Connections/data/local/search/backup

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\local\search\backup

    SEARCH_INDEX_SHARED_COPY_LOCATION Directory used for the automatic distribution of the baseline index to other nodes. / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/search/staging/

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\search\staging\

    SEARCH_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.

    Table 15. WebSphere Application Server Service Integration Bus file store environment variables

    Variable name Description / Local or shared* Default value
    MESSAGE_STORE_PATH Directory used to store the files used and managed by the messaging engines of the WebSphere Application Server Service Integration Bus (SIB) for the IBM Connections bus (permanent, temporary and log file) / shared

    The same requirements as for other shared content apply to this directory. In addition, if NFS is used, it is highly recommended by WebSphere Application Server SIB to use the version 4 of the protocol.

    AIX and Linux: /opt/IBM/Connections/data/shared/messageStores

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\messageStores

    Table 16. Wikis default WebSphere Application Server environment variables

    Variable name Description / Local or shared* Default value
    WIKIS_CONTENT_DIR File upload directory / shared

    AIX and Linux: /opt/IBM/Connections/data/shared/wikis/upload

    Microsoft

    Windows: C:\Program Files\IBM\Connections\data\shared\wikis\upload

    WIKIS_HOME Directory in which the Wikis application was installed. This variable is only necessary on the first node. / local

    AIX and Linux: /opt/IBM/Connections/wikis/wikis/wikis

    Microsoft

    Windows: C:\Program Files\IBM\Connections\wikis\wikis\wikis

    WIKIS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path specified when you installed the product.

    *Shared content must be accessible (read/write) by all nodes in a cluster. The shared content store must reside in a shared repository that grants read-write access to the Deployment Manager and all the nodes. Use one of the following methods to create a shared data directory:

    • Network-based file shares (for example: NFS, SMB/Samba, and so on)

    • Storage area network drives (SAN)

    • If you are using a shared-file system on Microsoft Windows, specify the file location using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name

    With version 3, all variables changed from being server-level variables to being cell-level variables. Variables having a server level scope are more granular than those with a node or cell level scope.

    Both shared and local content stores must be accessible using the same path from all nodes and the deployment manager.


    Related

  • Search index folder structure


    ConfigEngine properties

    The ConfigEngine properties in the wkplc_comp.properties file are used during the export/import operation.

    Production deployments often use more than one shared content store to avoid issues when all the applications are trying to read or write to the same attached device. In the event required to change the values of IBM WebSphere Application Server environment variables to match your deployment, you must update the properties in the IBM Connections configuration engine at the same time to ensure that the utility for exporting and importing functions correctly.

    IBM Connections uses WebSphere Application Server environment variables at runtime, but during the export/import operation, the utility uses the wkplc_comp.properties file. The file is located in the following directory:
    LC_install_dir/ConfigEngine/properties/wkplc_comp.properties

    Table 17. ConfigEngine properties

    WebSphere environment variables ConfigEngine Properties
    ACTIVITIES_CONTENT_DIR activities.objectstore.file.directory
    ACTIVITIES_STATS_DIR activities.statistic.directory
    AUDIT_FILE_ROOT_DIR news.auditFileDir
    BLOGS_CONTENT_DIR blogs.UploadDirectory
    COMMUNITIES_STATS_DIR communities.StatisticDirectory
    CONNECTIONS_CUSTOMIZATION_PATH connections.CustomizationDirectory
    DOGEAR_FAVICON_DIR dogear.UploadDirectory
    FILES_CONTENT_DIR files.UploadDirectory
    FILE_CONTENT_CONVERSION search.StellentDirectory
    FORUM_CONTENT_DIR forum.UploadDirectory
    PROFILES_STATS_DIR profiles.statistic.directory
    SEARCH_DICTIONARY_DIR search.DictionaryDirectory
    WIKIS_CONTENT_DIR wikis.UploadDirectory


    Change the name of the session cookie ID

    The session cookie ID for IBM Connections is named JSESSIONID by default. Other products hosted by the WebSphere Application Server often use the same name for their session cookie. If IBM HTTP Server is hosting multiple web servers, you might want to change the cookie name of one of them to prevent the cookie from being lost when the user is redirected from one product to another.

    1. If multiple products are hosted on the IBM WebSphere Application Server cell, by default the other application and WebSphere Application Server servers will have conflicting use of the JSESSIONID session ID cookie. For each WebSphere Application Server that uses the same virtual host (hostname) as the one that hosts Lotus Connections applications, do the following:

      1. In the WebSphere Application Server Integrated Solutions Console, expand Servers in the navigation pane, and then select Server Types > WebSphere application servers.

      2. Click the first clustered server.

      3. Expand Web Container Sets under Container Sets, and then select Web container.

      4. Under Additional Properties, click Session management.

      5. Select Enable cookies.

      6. Enter a different cookie name in the Cookie name field, for example, LCSESSIONID.

      7. Click OK, click Save, and then click Save again.

      8. Repeat with each clustered server.

    2. Restart the WebSphere Application Server or servers.

    3. Regenerate the plugin-cfg.xml file for the IBM HTTP Server in the WebSphere Application Server Integrated Solutions Console. To do so:

      1. Open the WebSphere Application Server Integrated Solutions Console.

      2. Expand Servers, and then select Server Types > Web servers.

      3. Select the check box next to the IBM HTTP Server name. For example: webserver1.

      4. Click Generate Plug-in to regenerate the plugin-cfg.xml file.

      5. If necessary, click Propagate Plug-in to copy the plugin-cfg.xml file from the local directory

        ...where the Application Server is installed to the remote machine.

    4. Restart the IBM HTTP Server.


    Schedule tasks

    The Activities, Communities, Files, Forums, News, Search, and Wikis applications use the IBM WebSphere Application Server scheduling service for performing regular tasks. You can use wsadmin commands to change the schedule by which a task runs or to disable a scheduled task altogether.

    The scheduling service allows you to reliably process workloads using parallel processing, and to schedule resource-intensive tasks during off-peak hours when there is low traffic. For more information about the WebSphere Application Server scheduling service, see the WebSphere Application Server Information Center at: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/welc6tech_sch.html

    The WebSphere Application Server scheduling service is based on the Cron calendar, which uses predefined date algorithms to determine when a task should run. IBM Connections tasks are configured by default to run on a certain schedule. You can change the time at which the scheduled tasks run using wsadmin commands to edit the configuration files for the associated application. Cron schedule values use the following syntax:

    second minute hourOfDay dayOfMonth month dayOfWeek
    Some tips when specifying the cron schedule values:

    • Specify an asterisk (*) to indicate to select all options. For example, if you specify * as the value of the dayOfWeek parameter, the task runs every day of the week.

    • Always set seconds to 0, except for in the Profiles task, which runs every 20 seconds and is specified using the syntax */20.

      The */n syntax means take the first value in the range, and then every nth value. So, if you specified */3 in the month position, the task would run quarterly in January, April, July, and October.

    • dayOfMonth and dayOfWeek are mutually exclusive; always set one to ?.

      The ? indicates that no value is being provided.

    • You can indicate in a single cron expression that you want a task to run multiple times by using multiple values separated by commas or you can specify a range by separating the values with a dash.

      • You can specify the value in dayOfWeek using SUN, MON or using numbers 1,2 where 1 represents Sunday.

      • You can specify JAN, FEB for the value of month or by using numbers 1,2 where 1 represents January.

      • To specify one or more seconds, use the values 0, 1, ... 59.

      • To specify one or more hours, use the values 0, 1, ... 23.
      For example, specifying 1,4,7,10 in the month position specifies that you want the task to run quarterly. Specifying 2-6 in the dayOfWeek position indicates that you want the task to run Monday through Friday.

    • If it is easier for you to read and define the schedule by separating out the values into multiple cron expressions, you can do so and use a | to concatenate the values into a composite schedule. For example, you could indicate to schedule to run quarterly at 3:45 PM on the second day of the month using the following string: 0 45 15 2 1 ? | 0 45 15 2 4 ? | 0 45 15 2 7 ? | 0 45 15 2 10 ?

    To see examples of cron expressions and what they mean, see Examples of scheduler values. For more information on the Cron calendar, see the WebSphere Application Server Information Center at: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/websphere/scheduler/UserCalendar.html

    To disable a scheduled task, use wsadmin commands.


    Related

  • Manage the Search index

  • Configure the widget life-cycle retry schedule
  • Manage Communities scheduled tasks
  • Configure news event log clean-up
  • Add scheduled tasks for Search
  • Complete activities that are not being used
  • Empty the Activities trash on a schedule
  • Schedule Activities statistics collection
  • Manage Forums scheduled tasks
  • Retrieve file content

  • Files configuration properties


    Examples of scheduler values

    Use the examples provided here to construct your own Cron calendar scheduler values or copy and paste these values into your wsadmin commands to reuse them.

    */30 * * * * ?

    Every 30 seconds

    0 */5 * * * ?

    Every 5 minutes starting at midnight. Be very sure to specify .0' for seconds

    0 0 * * * ?

    Every hour

    0 0 * ? * *

    Every hour on the hour

    0 50 * * * ?

    Every hour at 50 minutes past the hour

    0 15 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 1,2,3,4,5,6,7,8,9,10,11,12 ?

    Every hour at 15 minutes past the hour

    0 0 0-22/2 * *

    Every other hour starting at midnight.

    0 0 4/5 * * ?

    Every 5 hours starting at 4 AM. This would run at 4:00, 9:00, 14:00, and 20:00.

    0 0 0,8,16 * * ?

    Midnight, 8 AM, and 4 PM every day

    0 0 11 * * ?

    Every day at 11 AM

    0 0 0 * * ?

    Every day at midnight

    0 0 2 ? * *

    Every day at 2 AM

    0 0 12 ? * MON,TUE,WED,THU,FRI

    Weekdays at noon. MON and so on represent the days of the week.

    0 0 23 ? * 2-6

    Monday through Friday at 11 PM

    0 0 21 ? * 2-6/2

    Monday, Wednesday, and Friday at 9 PM

    0 30 18 ? * SAT,SUN

    Weekend days at 6:30 PM

    0 0 2 ? * SUN

    Weekly on Sundays at 2:00 AM

    0 0 23 ? * SAT

    Weekly on Sat at 11 PM

    0 0 * 1 * ?

    Every hour on the first day of every month

    0 1 0 L * ?

    Last day of every month at 00:01 AM

    0 59 23 L * ?

    Every month on last day at 11:59 PM

    0 0 22 1 * ?

    First day of every month at 10 PM

    0 45 15 2 1,4,7,10 ?

    Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM

    0 45 15 2 */3 ?

    Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM

    0 45 15 2 1 ? | 0 45 15 2 4 ? | 0 45 15 2 7 ? | 0 45 15 2 10 ?

    Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM

    0 30 3 1 1,7 ?

    January 1 and July 1 at 3:30 AM

    0 30 3 2 1 ? | 0 30 3 1 7 ?

    January 2 and July 1 at 3:30 AM

    0 0 0 4 7 ?

    Once a year at midnight on the 4th of July

    0 30 9 4 7 ?

    Once a year at 9:30 AM on the 4th of July

    0 45 15 2 1 ?

    Once a year on January 2 at 3:45 PM


    Clear all scheduled tasks

    Use administrative commands to clear the scheduler of all tasks.

    Only perform this procedure if you need to recreate all scheduler tasks. If you see an exception relating to LTPA tokens in the system log before each task runs, then you should perform this procedure to clear the scheduled tasks. This might be required, for example, after a new LTPA token is imported into IBM Connections or imported from a server in another cell as the result of enabling single sign-on, when reverting the DBs from a production environment to a staging environment, or after generating new LTPA keys due to a corporate security policy or LTPA timeout.

    Do not run the command documented here unless the clusters hosting the applications and the applications themselves are running. The administrative command used in this procedure interacts with the scheduler MBeans for each application to enumerate the scheduled tasks, and clear the tasks. The WebSphere Application Server scheduler is not application-aware, so as long as the clusters hosting an application are running, the scheduler will attempt to run the scheduled tasks for that application, even if the application itself is stopped. Each attempt to run a scheduled task for a stopped application results in an error message to the log.

    If you disable or stop an application, be sure to also cancel any scheduled tasks associated with it.

    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 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.

    3. Make sure that all clusters and applications are started and that no scheduled tasks are currently running by retrieving a list of tasks. Use the following command:

      Scheduler.listAllTasks()

      From the returned list, determine what to do next using these guidelines:

      Wsadmin client message

      Recommended action

      Status = running

      Wait until the task is completed.

      Skipping app_name application

      This means that the cluster hosting the application is not started. Restart the cluster.
      Here is a sample of the type of response you may receive when listing scheduled tasks:

      wsadmin>Scheduler.listAllTasks()
      
      Task Name  |  Status  |  Next Fire Time |  Interval
      Communities tasks
      LifecycleRetryQueuedEvents  SCHEDULED  Mon Feb 07 09:01:00 EST 2011  0 1 0-23/3 ? * *
      EventLogCleanup               SCHEDULED  Mon Feb 07 09:30:00 EST 2011   0 30 0-23/3 ? * *
      
      Activities tasks
      TrashAutoPurgeJob             SCHEDULED  Sun Feb 13 02:00:00 EST 2011   0 0 2 ? * SUN
      ActivityAutoCompleteJob       SCHEDULED  Sat Feb 12 23:00:00 EST 2011   0 0 23 ? * SAT
      DatabaseRuntimeStats          SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
      30MinStats                    SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0/30 * * * ?
      DailyStats                    SCHEDULED  Mon Feb 07 11:00:00 EST 2011   0 0 11 * * ?
      
      Forums tasks
      TrashAutoPurgeJob             SCHEDULED  Sun Feb 13 02:00:00 EST 2011   0 0 2 ? * SUN
      
      Profiles tasks
      Profiles Worker Process       SCHEDULED  Mon Feb 07 08:36:46 EST 2011   20seconds
      
      Files tasks
      SearchClearDeletionHistory    SCHEDULED  Mon Feb 07 16:00:00 EST 2011   0 0 0,8,16 * * ?
      MetricsDailyCollection        SCHEDULED  Tue Feb 08 00:00:00 EST 2011   0 0 0 * * ?
      TagUpdateFrequency            SCHEDULED  Mon Feb 07 10:00:00 EST 2011   0 0 0-22/2 * * ?
      DirectoryGroupSynch           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
      FileActuallyDelete            SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 0-23/3 * * ?|0 30 1-23/3 * * ?
      
      Wikis tasks
      SearchClearDeletionHistory    SCHEDULED  Mon Feb 07 16:00:00 EST 2011   0 0 0,8,16 * * ?
      MetricsDailyCollection        SCHEDULED  Tue Feb 08 00:00:00 EST 2011   0 0 0 * * ?
      TagUpdateFrequency            SCHEDULED  Mon Feb 07 10:00:00 EST 2011   0 0 0-22/2 * * ?
      DirectoryGroupSynch           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
      FileActuallyDelete            SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 0-23/3 * * ?|0 30 1-23/3 * * ?
      
      News tasks
      NewsDataCleanup               SCHEDULED  Mon Feb 07 23:00:00 EST 2011   0 0 23 ? * *
      NewsCheckUpdatedPersons       SCHEDULED  Mon Feb 07 08:50:00 EST 2011   0 50 * * * ?
      EmailDigestDelivery           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * ? * *
      MetricsCollector              SCHEDULED  Tue Feb 08 02:00:00 EST 2011   0 0 2 ? * *
      PersonSpreadTranche           SCHEDULED  Tue Mar 01 22:00:00 EST 2011   0 0 22 1 * ?
      
      Search tasks
      20min-file-retrieval-task     SCHEDULED  Mon Feb 07 08:41:00 EST 2011   0 1/20 0,2-23 * * ?
      15min-search-indexing-task    SCHEDULED  Mon Feb 07 08:46:00 EST 2011   0 1/15 0,2-23 * * ?
      nightly-optimize-task         SCHEDULED  Tue Feb 08 01:30:00 EST 2011   0 30 1 * * ?
      nightly-sand-task             SCHEDULED  Tue Feb 08 01:00:00 EST 2011   0 0 1 * * ?
      
      wsadmin>

    4. After performing any suggested actions, run the following command to clear the scheduled tasks:

      Scheduler.clearAllTasks()

    5. Restart the cluster servers to force the scheduled tasks to be recreated.

      1. From the WebSphere Application Server Integrated Solutions Console, expand Servers, click Server Types, and then click WebSphere application servers.

      2. Select the check box for one server per cluster, and then click Restart.


    Maintain application DBs

    Each IBM Connections application stores data in a database, and some also store data on a file system. You must back up these DBs and file systems on a regular schedule using the methods documented by the vendor from whom you purchased the database and file system that you are using.

    If you use IBM DB2 DBs, IBM Connections provides a few SQL scripts to help you perform maintenance tasks on them, such as collecting statistics and compacting. You can collect statistics while IBM Connections is running; there is no need to stop the applications nor bring the DBs offline. However, you must stop all applications that access the DBs before compacting and defragment them.

    When you restore data for an application that is also available from the Communities application, you must also restore the data in the Communities application to keep the two in sync. See Recovering from a database failure for more details.


    Related

  • Recover from a database failure
  • Restore a Community Blog after a Communities database failure

  • Back up Files data
  • Back up Wikis data
  • Back up IBM Connections
  • Restore Activities data


    Gather DB2 database statistics daily

    Use the provided script to gather statistics about DB2 database table usage. Run the scripts nightly using the DB2 Task Center, for example, to update internal statistics used by DB2. Up-to-date statistics are necessary for proper performance. This procedure is relevant for DB2 DBs only. Oracle and SQL Server gather statistics automatically. You can collect statistics while IBM Connections is running and in use. However, it is best to schedule statistic collection to run on a regular basis during off-peak hours using a tool such as DB2 Task Scheduler.

    To gather DB2 database statistics, complete the following steps:

    1. Copy the statistics script named runstats.sql to the root directory of the application database for which you want to gather statistics. The script is stored in the following subdirectory of the IBM Connections installation files:

      • AIX or Linux:

        /Lotus_Connections_Install/connections.sql/
         application_subdirectory/db2

      • Microsoft

        Windows:

        \Lotus_Connections_Install\connections.sql\
         application_subdirectory\db2

      where application_subdirectory is the script file storage directory of the application for which you are compacting the database. Choose one of the following subdirectories:

      • activities

      • blogs

      • communities

      • dogear

      • files

      • forum

      • homepage

      • metrics

      • profiles

      • wikis

    2. Log into the database server using an ID that has administrative privileges.

    3. Open a command prompt, and then change to the directory to which you copied the script.

    4. Use the following command to run the application scripts:

      • For Activities, Blogs, Communities, and Forums:

        db2 -td@ -vf runstats.sql

      • For Bookmarks and Profiles:

        db2 -tvf runstats.sql

      • For Home page:

        db2 -tvf updateStats.sql

      • For Files, Metrics, and Wikis:

        db2 -td@ -vf updateStats.sql


    Improve access performance and defragmenting DB2 database data

    Use the scripts provided with IBM Connections to improve access performance and reclaim fragmented space in the DB2 database data of an application database. This procedure is relevant for DB2 DBs only. Oracle and SQL Server compact data automatically.

    The script that you run to improve access performance and reclaim the fragmented space of the database takes the database offline. To prepare the database to be taken offline, you must stop the WebSphere Application Server instances for each application that you plan to run the script on. You do not need to run this script on the database frequently. IBM recommends that you schedule this tasks during another maintenance task that requires you to take the application offline.

    1. Copy the database compacting script named reorg.sql to the root directory of the application database for which you want to improve access performance. The scripts are stored in the following subdirectory of the IBM Connections installation files:

      • AIX or Linux:

        /Lotus_Connections_Install/connections.sql/
         application_subdirectory/db2

      • Microsoft

        Windows:

        \Lotus_Connections_Install\connections.sql\
         application_subdirectory\db2

      where application_subdirectory is the script file storage directory of the application for which you are improving database access performance. Choose one of the following subdirectories:

      • activities

      • blogs

      • communities

      • dogear

      • files

      • forum

      • homepage

      • metrics

      • profiles

      • wikis

      To improve access performance of the Communities discussion forum database, copy the reorg_forum.sql file from the communities subdirectory.

    2. From the WebSphere Application Server Integrated Solutions Console, stop the servers hosting the applications hosting the DBs. To do so, complete the following steps:

      1. Log in to the WebSphere Application Server Integrated Solutions Console as an administrator.

      2. Expand Servers > Server Types, and then select WebSphere application servers.

      3. Select the check boxes next to the servers hosting the applications with the DBs in which you want to improve access performance, and then click Stop.

    3. Log into the database server using an ID that has administrative privileges.

    4. Open a command prompt, and change to the directory to which you copied the script.

    5. Use the following command to run the application scripts:

      • For Activities, Blogs, Communities, Forums, Files, Metrics, and Wikis:

        db2 -td@ -vf reorg.sql

      • For Bookmarks, Home page, and Profiles:

        db2 -tvf reorg.sql

    6. Restart the application servers by repeating Step 2, but selecting Start instead of Stop.


    Configure notifications

    If you did not create a mail session on the WebSphere Application Server during the initial installation, you can configure it afterwards to enable support for email notifications in the IBM Connections applications.

    When you enable notifications, users are kept informed about new information and events that take place in the IBM Connections applications. For example, the following types of notifications are available for the applications:

    Activities

    Notification events are enabled by default. Email event types are only enabled if you enabled email notifications during the product installation process.

    Table 18. Activities notification types

    Notification name Description Notification type
    add-member When an activity owner adds members to an activity, a notification is automatically sent to them to inform them about the activity. Directed
    autocomplete Activity owners receive an email to warn them that one of their inactive activities will be marked complete if it is not updated. Directed
    create When a standard activity is created, each member is sent a notification informing them about the activity. When a community activity is created, notifications are sent out only if individual members are added; no notifications are sent when an entire community membership list is added. Directed
    notify Activity members can send other members notifications about entries. Directed

    Blogs

    Table 19. Blogs notification types

    Notification name Description Notification type
    approved When an entry, idea, or comment is approved, an automatic notification is sent to the author as well as last editor to inform them about it. Moderation
    confirmflagged When a flag on a post, idea or comment is confirmed, an automatic notification is sent to the flag creator to inform him about it. Moderation
    notify Notifications that one user sends to others to inform them about useful blog posts. Directed
    notifyassigned-author When a blog owner assigns author permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
    notifyassigned-draft When a blog owner assigns draft permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
    notifyassigned-owner When a blog owner assigns owner permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
    notify-idea Notifications that one user sends to others to inform them about useful ideas. Directed
    notifyflagged When a post, idea, or comment is flagged as inappropriate, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to inform them about it. Moderation
    notifyreposted When an entry or idea is modified and re-posted, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to inform them about it. Moderation
    notifyreview When a new entry, idea, comment or trackback comment is posted and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation
    ownermsg When a new comment is posted, an automatic notification is sent to the entry or idea creator about the new comment. Response
    quarantined When an entry, idea, or comment is quarantined, an automatic notification is sent to the authors, which includes the post creator and its last editor, and blog owners to inform them about it. Moderation
    rejected When an entry, idea, or comment is rejected, an automatic notification is sent to the author and last editor to inform them about it. Moderation
    restored When an entry, idea, or comment is restored, an automatic notification is sent to the author and last editor and blog owners to inform them about it. Moderation
    returned When an entry or idea is returned, an automatic notification is sent to the post authors, which includes the post creator and its last editor, and blog owners to inform them about it. Moderation

    Bookmarks

    Table 20. Bookmarks notification types

    Notification name Description Notification type
    brokenurl Broken URL notifications display in the activity stream on the Home page. Directed
    notify Users can send notifications to other users to inform them about useful bookmarks. Directed
    notifyReplaceURL Administrator can send a notification to the bookmark owner to report the update of a link. This notification is triggered by an MBean

    Communities

    Table 21. Communities notification types

    Notification name Description Notification type
    broadcastMail Members can send notifications to other members to inform them about important events. Broadcast
    invite Members can send a notification to a non-member to invite them to join the community. Directed
    memberAdded Notifications are automatically generated and sent to members when they are added to a community. Directed
    memberRemoved Notifications are automatically generated and sent to members when they are removed from a community. Directed
    notifyEvent Community members can send other members notifications about specific events by opening the event and selecting More Actions > Notify Other People. The event owner can also send this notification when creating the event. Directed
    requestToJoin Users can request to join a community by sending a notification to the community's owner. Directed

    Files

    Table 22. Files notification types

    Notification name Description Notification type
    collectionMediaAdd Notification sent to users when a file is added to a folder or community they are following. Directed
    collectionMemberUpdate Notification sent to users when a folder is shared with them, or when their folder access level changes. This applies to individual users, not groups. Directed
    commentAdd Notification sent to users when a comment is created on a file they are following. Users can follow files by opening the file page and clicking Follow. Follow
    communityVisibilityUpdate Notification sent to owners of a community when the community was changed from non-public to public and private files shared with the community were removed from it. Directed
    mediaEdit Notification sent to users when a file they are following is edited. Users can follow files by opening the file page and clicking Follow. Follow
    mediaShare Notification sent to users when files are shared with them. Directed

    Moderation

    Table 23. Moderation notification types

    Notification name Description Notification type
    notifyApproved When an entry is approved, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
    notifyAutoQuarantined When an entry is flagged as inappropriate a specified number of times, automatic notification is sent to the Global Moderator and Reviewers. The number of inappropriate flaggings is specified in the contentreview-config.xml file, in the autoQuarantine property. For example, if you specify autoQuarantine at "5", notification is sent after the entry is flagged a fifth time. Moderation
    notifyFlagged When an entry is flagged as having inappropriate content, and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation
    notifyPending When an entry is added and needs approval, an automatic notification is sent to the entry author to let them know that the entry is in the review process. Reviewers and moderators are notified separately by a notifyReview email. Moderation
    notifyQuarantined When an entry is quarantined, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
    notifyRejected When an entry is rejected, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
    notifyRestored When an entry is restored, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
    notifyReview When an entry is added, and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation

    News

    Table 24. News notification types

    Notification name Description Notification type
    dailyDigest If email notifications are enabled on your system, you will have options that are set to Daily Newsletter option by default in the Sets page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Areas that have this option set will have content included in the Daily Newsletter received, once there has been an update by a person other than yourself within that subview since the last Daily Newsletter. Follow
    followIndividual If email notifications are enabled on your system, you will have options that are set to Individual E-mails option by default in the Sets page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Any updates within the corresponding News Feed subview by a person other than yourself are sent to you in individual emails. Follow
    replyToError When a user replies to a ReplyTo enabled notification and an error occurs at the server, an automatic notification is generated and sent to the user to inform them of the error. Directed
    weeklyDigest If email notifications are enabled on your system, you will have options that are set to Weekly Newsletter option by default in the Sets page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Areas that have this option set will have content included in the Weekly Newsletter received, once there has been an update by a person other than yourself within that subview since the last Weekly Newsletter. Follow

    Profiles

    Table 25. Profiles notification types

    Notification name Description Notification type
    notify If a person designates someone else as a colleague, the colleague is sent a notification inviting them to join that person's network. Directed
    notifyBoardOwnerForComment Board owners are notified when someone comments on their message board. Response
    notifyBoardOwnerForEntry Board owners are notified when someone posts a message in their message board. Response
    notifyEntryOwnerForComment Board owners are notified when someone comments on a message board entry. Response

    Wikis

    Table 26. Wikis notification types

    Notification name Description Notification type
    commentAdd

    Notification sent to users when a comment is created on a wiki page they are following, or on any page in a wiki they are following.

    Users can follow wiki pages or wikis by opening a page and clicking Follow, and then Follow this Page or Follow this Wiki.

    Follow
    mediaEdit

    Notification sent to users when an event occurs in a wiki page or wiki they are following. Events include title or description edits, new tags, and new or deleted pages, edits or comments.

    Users can follow wiki pages or wikis by opening a page and clicking Follow, and then Follow this Page or Follow this Wiki.

    Follow
    roleAdd

    Notification sent to users when they are made a member of a wiki, or when their wiki access level is changed. This applies to individual users, not groups.

    Directed

    The following notification types are supported:

    Broadcast

    Sent solely to the recipients by email. Broadcast notifications are not shown on the Home Page.

    Directed

    Sent from one user, or the system, to another user or set of users. Users can opt to not receive these notifications via email through their email preferences settings. Directed notifications are always visible to the recipients and the sender from the Home Page.

    Follow

    Generated for users who follow a particular resource and who choose to have individual notifications sent for that type of resource on their email preferences settings.

    Moderation

    Used solely in the content moderation process.

    Response

    Used to inform a user when a comment or reply has been left on their content. Response notifications only go to the owner of the content, not followers. These notifications are sent if the user has elected to receive responses through individual emails in their email preferences settings.

    Only complete this task if you did not configure notifications during the installation. You can configure notifications to be sent in one the following ways:

    Send mail from a server found by doing a lookup

    This configuration performs a lookup of domain namespace (DNS) MX records to retrieve a list of available SMTP servers. If the DNS lookup does not find any available SMTP servers, then notification fails. If one or more SMTP servers are returned by the lookup, then IBM Connections attempts to send the notification email through one, and then the next until the email is sent successfully. This option avoids the risk of a single point of failure. If you choose this option, make sure your DNS is configured with valid MX records to ensure that available SMTP servers can be found.

    Send mail from a specific SMTP server

    This configuration uses a single SMTP server. You must define the SMTP server and its associated settings as a mail session that is managed by WebSphere Application Server. This single SMTP server is used to send email notifications. If the server is unavailable, then notification fails.


    Send mail from any available mail server

    Configure IBM Connections to perform a lookup of domain namespace (DNS) MX records to retrieve a list of available SMTP servers. If the DNS lookup does not find any available SMTP servers, then email notifications fail to be delivered. If one or more SMTP servers are returned by the lookup, then IBM Connections attempts to send the email through one, and then the next until the email is sent successfully.

    Mail is configured as part of the installation process. Only perform this procedure if you did not enable mail during the installation or you want to change the mail configuration.

    You can choose to have IBM Connections perform a DNS lookup of multiple SMTP server to find one that is available to send the message or you can configure notifications to be sent from a single, dedicated SMTP server. If you are interested in the latter configuration, see Sending mail from a dedicated mail server. If you choose to enable mail from any available server, make sure your DNS is configured with valid MX records to ensure that available SMTP servers can be found.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    2. Access the IBM Connections configuration files:

      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.

    3. Check out the notification-config.xml file :

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. When you specify a path to the temporary directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

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

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Search for the <emailChannelConfig> element, and then change the value of the <useJavaMailProvider> element from true to false:

      <useJavaMailProvider>false</useJavaMailProvider>

    6. Remove the punctuation commenting out the <smtpJNDILookup> element by removing the !-- from the opening element and -- from the closing element. For example, change the following XML markup:

      <!--smtpJNDILookup>
      ...
      </smtpJNDILookup-->
      to the following markup:

      <smtpJNDILookup>
      ...
      </smtpJNDILookup>

    7. Set the value of the <smtpJNDILookupURL> element within the <smtpJNDILookup> XML block to a valid DNS lookup web address for your environment.

      For example, the following web address performs a lookup of MX records for the acme.com domain using the default DNS server on the system on which IBM Connections is running:

      dns:///acme.com
      This value performs the same lookup on a specific DNS server that has an IP address of 192.168.0.2.

      dns://192.168.0.2/acme.com

    8. Configure or comment out any of the remaining properties in the <smtpJNDILookup> element block as needed for your environment. Some of the elements for which you can specify values are defined as follows:

      <authEntry>

      Specifies a WebSphere managed Java 2 Connector alias that specifies the username and password to use when connecting to an SMTP server requiring authentication.

      <javamail>

      Specifies valid JavaMail properties. For example:

      <javamail>
        <property name="mail.debug">false</property>
        <property name="mail.smtp.connectiontimeout">120000</property>
        <property name="mail.smtp.timeout">120000</property>
        <property name="mail.smtp.port">465</property>
        <property name="mail.smtp.socketFactory.port">465</property>
        <property 
         name="mail.smtp.socketFactory.class">javax.net.ssl.SSLSocketFactory
        </property>
        <property name="mail.smtp.socketFactory.fallback">false</property>
      </javamail>

      The smtp properties configure a secure connection to the SMTP server using SSL. The time out properties define the amount of time for the notification to wait for the server to complete the request. If the time limit is reached, an exception is written to the server log, and an error is displayed to the Activities user that requested the notification. These properties prevent resources from being consumed in the event that the SMTP server is unavailable. The time interval is specified in milliseconds. A value of 120,000 is two minutes. See the JavaMail documentation for more information about these properties.

    9. The <maxRecipients> element defines the maximum number of people to whom you can send a notification at one time. The default value for this element is 50, but you can change it.

      <maxRecipients>50</maxRecipients>

    10. Save and close the notification-config.xml file.

      You must check out and edit the same file in the procedure described in Enabling email notifications. If you plan to complete that procedure next, keep the notification-config.xml file open and checked out.

    11. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")

    12. Stop and restart IBM Connections.


    What to do next

    You must complete the steps described in Enabling email notifications before users can send and receive email notifications.


    Related tasks

  • Start the wsadmin client
  • Enable email notifications


    Send mail from a dedicated mail server

    Configure IBM Connections notifications to be sent from a specific SMTP server that is managed by WebSphere Application Server. If the designated mail server is unavailable, then notification emails fail to be delivered.

    Mail is configured as part of the installation process. Only perform this procedure if you did not enable mail during the installation or you want to change the mail configuration.

    You can choose to configure notifications to be sent from a single SMTP or have IBM Connections perform a lookup of multiple SMTP server to find one that is available to send the message. If you are interested in the latter configuration, see Sending mail from any available mail server.

    1. Log into the IBM WebSphere Application Server Integrated Solutions Console.

    2. Expand Resources and select Mail > Mail sessions.

    3. Select Cell scope, and then create a new session.

    4. Specify values for the following fields:

      Name

      Specify IBM Connections Notification or another descriptive string.

      JNDI name

      Specify mail/notification as the value of the JNDI name.

    5. Set the following custom properties to define time outs that will prevent resources from being consumed in the event that the SMTP server is unavailable:

      mail.smtp.timeout=120000
      mail.smtp.connectiontimeout=120000
      The time interval is specified in milliseconds. A value of 120,000 is two minutes.

    6. In the Outgoing Mail Properties section, specify the fully qualified host name or IP address of the SMTP server that you want to use in the Server field.

    7. Optional: If the SMTP server requires authentication, then provide values for the following fields:

      User

      User ID used to connect to the SMTP server.

      Password

      Password associated with the user ID used to connect to the SMTP server.

      Verify Password

      Repeat the password specified in the previous field.

    8. If the SMTP server requires traffic to be sent over SSL, then add the following customer properties, and then specify values for them by clicking the Custom properties link, and then clicking New:

      mail.smtp.port

      Specifies the SMTP port number, which is often 465.

      mail.smtp.socketfactory.port

      Specifies the SMTP port number, which is often 465.

      mail.smtp.socketfactory.class

      Specifies the SSL socket factory class.

      mail.smtp.socketFactory.fallback

      Specifies whether an unsecure connection can be made if SSL is not available. This property accepts the following values: true or false.
      For example:

      mail.smtp.port=465
      mail.smtp.socketfactory.port=465
      mail.smtp.socketfactory.class=javax.net.ssl.SSLSocketFactory
      mail.smtp.socketFactory.fallback=false

    9. Click OK, and then save your changes.

    10. 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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    11. Update the notification configuration file to indicate to use a mail session managed by WebSphere Application Server.

      1. Access the IBM Connections configuration files:

        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. Check out the notification-config.xml file :

        LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

        ...where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. When you specify a path to the temporary directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

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

      3. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

      4. Search for the <emailChannelConfig> element, and then uncomment the following line of XML markup if it is commented out:

        <useJavaMailProvider>true</useJavaMailProvider>

      5. Comment out the <smtpJNDILookup> element if it is not already.

        <!--smtpJNDILookup>
        ...
        </smtpJNDILookup-->

      6. Save and close the notification-config.xml file.

        You must check out and edit the same file in the procedure described in Enabling email notifications. If you plan to complete that procedure next, keep the notification-config.xml file open and checked out.

      7. Check in the configuration files :

        LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")

      8. Stop and restart IBM Connections.


    What to do next

    You must complete the steps described in Enabling email notifications before users can send and receive email notifications.


    Related tasks

  • Start the wsadmin client
  • Enable email notifications


    Enable email notifications

    Edit configuration settings to enable email notifications in the IBM Connections applications if you did not do so during the installation.

    Only complete this procedure if you did not enable email notifications during the product installation. You must complete the steps described in the Configuring notifications topic before you can start this procedure. You might choose not to enable email notifications if you have configured IBM Connections to hide email addresses, for example. Even when you do not enable email notifications, if you installed the Home page application, the product still supports a subset of notifications that can be displayed in the Home page application. The subset includes the notifications of type "Directed," which are listed in the topic named Configuring notifications.

    When you set the enabled property to false globally or for a specific source, this disables all notification events for the Home page. Notification emails will not be sent and notifications will not display in the My Notifications view in the Home page. For this reason, when you are disabling email only, it is important to ensure that you only set the email channel to false for a specific notification type.

    To configure email notifications, 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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    2. Access the IBM Connections configuration files:

      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.

    3. Check out the notification-config.xml file :

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where

      • temp_dir is the temporary 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 temporary directory must grant write permissions or the command will not run successfully.

      • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.

      If you want to enable mail for all of the applications and if you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each component. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile. For example:

      • AIX/Linux:

        LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")

      • Microsoft

        Windows:

        LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Find the <config> element with the ID attribute equal to notification-config.

    6. Search for the <source name="<applicationName>" string to find the section of XML markup that defines the notification settings for the application for which you want to enable email notifications.

    7. Change the value of the enabled attribute associated with the email channel element to true. For example:

      <source 
       name="Activities" 
       enabled="true" 
       defaultFollowFrequency="DAILY">
         <type name="notify" notificationType="DIRECTED">
      <type name="notify" notificationType="DIRECTED">
       <channel name="email" enabled="true">
        <property name="sender">blogs-admin@example.com</property>
        <property name="ftl">notify.ftl</property>
       </channel>
       <channel name="event" enabled="true">
        <property name="eventName">blogs.notification.notify</property>
        <property name="transformerClass">com.ibm.lotus.connections.core.notify.channels.event.BlogsNotificationEventTransformer</property>
       </channel>
      </type>
      ...
      </source>

      When you disable notifications during the installation process, all the email channels are set to false. Source events are left at true because notification events are still valid to be sent and displayed in the Home page activity stream. Set the entire source to false disables all events, which means that notification emails will not be sent and will not display in the My Notifications view in the Home page.

    8. Save and close the notification-config.xml file.

    9. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")

      If you plan to specify administrator email addresses now, keep the notification-config.xml file checked out; you must edit values in it to complete the next procedure.


    What to do next

    See Defining valid administrator email addresses for some additional steps that you must take to configure automatic notifications in Activities.


    Related tasks

  • Change common configuration property values
  • Start the wsadmin client
  • Define valid administrator email addresses
  • Send mail from any available mail server
  • Send mail from a dedicated mail server


    Configure Forums for email notification replies

    Configure Forums so that users can reply to forum topics by email.

    When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. After you enable and configure notification replies, users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

    When users reply to notifications, a mail server uses a rule or trigger to direct the reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums.

    For this to work, an administrator must configure the mail server and mail session, and then enable the feature. Users must specify their email settings in IBM Connections. For a user to receive notifications that they can reply to, the Notifications feature must be enabled on the server. The email notification reply feature must also be enabled on the server in the news-config.xml file. Each user who wants to receive email reply notifications must then have the feature enabled on their Sets screen.

    Configure the mail session requires performing some simple steps in the WebSphere Application Server administrative console. Configuring the mail server requires creating the dedicated mailbox, and creating a rule or trigger to direct replies to it. Steps for creating the rule or trigger will vary depending on the mail server. For example, in Microsoft Exchange you create a transport rule; in Domino® you create a trigger.

    IBM Connections supports the Simple Mail Transfer Protocol (SMTP) for sending notifications, and the Internet message access protocol (IMAP) and secure Internet message access protocol (IMAPS) for notification replies. Any mail server using these protocols can direct notifications and notification replies. This documentation only provides information on configuring the following mail servers to handle notification replies: IBM Lotus Domino 8.5.2, Microsoft Exchange 2007, and Microsoft Exchange 2010. See Configuring notifications for information on configuring notifications in an installed deployment.

    In deployments with multiple IBM Connections servers, the different servers cannot use the same mailbox. However, they can use different mailboxes on the same mail server, in which case each would require its own direction rules.


    Configure WebSphere Application Server for email notification replies

    Configure an IBM WebSphere Application Server mail session to connect to a mailbox dedicated to storing email notification replies.

    After you have set up your IBM Lotus Domino or Microsoft Exchange server to receive replies, you need to configure the IBM® WebSphere® Application Server mail session parameter to connect to the mailbox dedicated to storing email notification replies. If your environment requires authentication to connect to the mailbox containing the replies, you must use IBM WebSphere Application Server with FixPack 17 or later.

    The steps in this topic are required to configure Forums so that users can reply to forum topics by email. When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. Users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

    A mail server uses a rule or trigger to direct reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums. This topic documents how to create the mail session.

    The ReplyTo mailbox should be different from a Connections user's regular mailbox. It is better to have a mailbox set aside just to handle ReplyTo replies to avoid the risk of having notifications sent to that user being read back in as ReplyTo replies.

    1. Open the IBM WebSphere Administrative Console.

    2. Navigate to Resources > Mail > Mail Sessions.

    3. Select a scope, and then create a new mail session with the following properties:

      1. In the Name field type: lcreplyto

      2. In the JNDI name field type: mail/replyto

    4. In the Incoming Mail Properties section set the following properties:

      1. In the Server field, type the name of the mail server where the MailIn mailbox is located.

      2. In the Protocol field, type the name of the protocol the server will use. You must use either IMAP or IMAPS.

      3. In the User field, type the name of a user with access to the mailbox.

      4. In the Password field, type the password the user from Step c.


    Configure Domino for email notification replies

    Configure IBM Lotus Domino 8.5.2 to direct email notification replies to a dedicated mailbox.

    Install and configure a IBM Lotus Domino 8.5.2 Messaging Server. See the IBM Lotus Domino Messaging Server documentation.

    The steps in this topic are required to configure Forums so that users can reply to forum topics by email. When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. Users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

    A mail server uses a rule or trigger to direct reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums. This topic documents how to configure a Domino server to direct reply emails to a dedicated mailbox.

    1. Open the Domino server and click the Domain tab.

    2. Expand Messaging in the navigator, and then click Configuration.

    3. Select the messaging server and click Edit Configuration.

    4. Click the Router/SMTP tab, then the Restrictions and Controls tab, and then the Rules tab.

    5. Click New Rule and create a rule that moves emails containing lcreplyto_ in the To field to the mailbox, for example:

      When To contains lcreplyto_ move to Database mail\mailin.nsf
      Where mail\mailin.nsf is the location and name of your dedicated email reply mailbox.

    6. Domino moves the emails to the Sent view instead of the Inbox of the mail database. Create a Notes® agent to move the emails from the Sent view to the Inbox.

      1. Open the mail server in Notes.

      2. In the People & Groups tab, expand PeoplebyOrganization.

      3. Edit the account of the user used to direct reply mail.

      4. Click Open Mail File.

      5. Select the View > Agents menu item.

      6. Click New Agent.

      7. Add the following Lotusscript to the agent:

        The following script is only an example to be used for reference, and you will need to change or adjust the script based on your actual environment.

        Sub Initialize
            
            Dim session As New NotesSession
            Dim db As NotesDatabase
            Dim view As NotesView
            Dim doc As NotesDocument
            
            Set db = session.CurrentDatabase
            Set view = db.getView("$Sent")
            
            Set doc = view.GetFirstDocument()
            While Not(doc Is Nothing)
                Call doc.PutInFolder("$inbox")
                Set doc = view.GetNextDocument(doc)
            Wend
            
            
        End Sub

      8. Open the agent properties:

        • In the Options section select Shared.

        • In the Runtime section select On schedule, and then select More than once a day.

        • In the Target field select All new & modified documents.

        • Set a schedule, for example have it run every 5 minutes, all day.

      9. Before running the script ensure you have adequate permissions to run it.


    Configure Exchange for notification replies

    Configure Microsoft Exchange 2007 or 2010 to direct email notification replies to a dedicated mailbox.

    In environments with Microsoft Exchange, create a Transport Rule, on either the Edge Transport server or Hub Transport server, that identifies notification reply emails based on a pattern, and then directs that mail to the dedicated mailbox. For example, you can create a rule that identifies emails in which the To header contains the unique domain name you've appended as a suffix to notification reply email addresses.

    Example:

    • Rule type: Transport Rule, on Hub Transport

    • Condition: "when the message header contains text patterns"

    • Sub-condition: message header = "To"

    • Sub-condition: pattern = "lconn.acme.com$" (address ends with lconn.acme.com). Substitute lconn.acme.com with the domain you are using for notification reply emails. See Enabling notification replies for more information.

    • Action: "redirect the message to addresses"

    • Target address: "lconn@acme.com". Substitue lconn@acme.com with the address of the mailbox dedicated to storing notification reply emails.

    The domain configured in the news-config.xml file for ReplyTo needs to be an Accepted Domain, which can be configured in the Hub Transport tab of the Exchange console.

    For details on creating rules for identifying and directing email, see the Microsoft Exchange documentation.


    Related tasks

  • Enable notification replies


    Enable notification replies

    An administrator must edit settings in the news-config.xml file to allow users to reply to email notifications. Users must specify two preferences.

    To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details.

    In the news-config.xml file you must enable support for the reply feature, and also provide a special ReplyTo address. If your deployment has a dedicated IBM Connections mail domain, you must provide that as well. If your deployment uses an existing domain, provide either a prefix or suffix to add to the IBM Connections domain.

    For users to be able to reply to emails, certain of their IBM Connections settings must be selected. They must click Sets, and then the Email Preferences tab. They must make sure Receive notifications from other people by email and Allow me to reply to notifications by email (this option is only available if mail-in is enabled in the news-config.xml file) are selected. In the Content that I am following section, they must make sure Forums is set to Individual Emails.

    Users will not see Allow me to reply to notifications by email until you perform the steps in this topic to enable notification replies.

    To configure the data synchronization 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 News Jython script interpreter.

      1. Use the following command to access the News configuration file:

        execfile("newsAdmin.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 News cell-level configuration file :

        NewsCellConfig.checkOutConfig("working_dir", "cellName")

        ...where:

        • working_dir is the temporary directory to which you want to check out the cell-level configuration file. This directory must exist on the server where you are running wsadmin.

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

        • cellName is the name of the cell that the home page node belongs to. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, type the following command in the wsadmin command processor to determine it:

          print AdminControl.getCell()

        For example:

        NewsCellConfig.checkOutConfig("d:/temp", "NewsServerNode01Cell")
        The command displays this message:

        News Cell Level configuration file successfully checked out.

    3. Open news-config.xml in a text editor.

    4. Locate the section containing the mailin element:

      	<!-- These settings control the Mail-In feature, which provides support
      for replying to certain notifications to add responses / comments. -->
      
      	<mailin enabled="true">
      	    <replyto enabled="true">
      	    
      	    	<!-- A special ReplyTo address is added to notifications where
      				 the user can reply to the notification to respond/comment.
      				 The domain may be a dedicated domain for connections bound
      				 mails. Or it could be existing domain, in which case a prefix
      				 of suffix should be provided also. -->
      
      	        <replytoAddressFormat>
      	            <domain>enterprise.com</domain>
      
      	            <!-- A prefix OR suffix (not both) may also be provided. 
      						This is necessary if an existing domain (with other 
      						email addresses) is being used.
      						There is a 28 character limit for the affix. -->
      
      	            <!--  
      	            	<affix type="suffix">_lcreplyto</affix>
      					-->
      
      	        <affix type="prefix">lcreplyto_</affix>
      	            
      	        </replytoAddressFormat>
      	    </replyto>
      	</mailin>

      • Set the mailin.enabled and replyto.enabled attributes as "true."

      • Specify your email server domain in the replytoAddressFormat.domain element. The example shown is enterprise.com.

      • If you use an existing, non-dedicated domain that contains other email addresses, specify either a suffix or prefix to be added to the domain in the address. The examples shown are _lcreplyto and lcreplyto_.

    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 the News repository for information about how to save and apply your changes.


    Results

    ReplyTo can be turned on or off by Connections users if the default setting <replyToEnabled>true</replyToEnabled> is specified in notification-config.xml. Refer to Enable email notifications for instructions on modifying notification-config.xml.


    Related

  • Configure Exchange for notification replies


    Define valid administrator email addresses

    Edit configuration property settings to change the default email addresses from which system notifications, such as a request to join a community, are sent. Notifications are sent from generic administrator email addresses if you do not take action. Default email addresses are initially set during installation, so use this procedure only if you want to change them.

    By default, automatic notifications are sent from a generic email address, such as blogs-admin@example.com. Edit the property to change this to a legitimate administrator email address that has access rights to send mail. Some of the notification messages sent automatically, such as the notifications used to handle blog postings that are flagged for containing inappropriate content, inform recipients that they can respond to the default administrative user email address from which the notification was sent. If you do not edit the default email address, recipients get a delivery failure notification when they try to respond to the automatic email.

    • If you plan to prevent user email addresses from being displayed in the product, define a valid email address for the global administrator. When you hide emails, this global administrator address is specified as the sender even in emails generated by user actions that would normally specify that user as the sender. The global sender email address is only used if you configure IBM Connections to prevent emails from being displayed.

    • If you provide additional administrator email addresses for the different types of notifications, those settings take precedence over the global address. If you want the global administrator address to be used for a specific notification, comment out the sender property currently specified for that notification type. For example:

      <!--<property name="sender">files_admin@example.com</property>-->

    You can edit the following administrator email addresses:

    • Global sender. Change the default email address of the global sender into one with the correct domain for your enterprise and a name that your users will recognize and trust.

    • Specific notification types. Edit the administrator addresses used when different types of notifications are sent.
    If you want to change default email addresses from what you assigned in install:

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    2. Access the IBM Connections configuration files:

      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.

    3. Check out the notification-config.xml file :

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed Activities. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

      AIX and Linux only: The directory you specify as the temporary directory must grant write permissions.

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Specify a valid internet-style email address containing no spaces for the global sender by editing the globalSenderEmailAddress property in the following section of the notification-config.xml file:

      <properties>
        <property name="globalSenderName">IBM Connections Administrator</property>
        <property name="globalSenderEmailAddress">global-admin@example.com</property> 
      </properties>

    6. Optional: If you want to force the email address that you specify in the globalSenderEmailAddress to be used as the sender of all notifications, add the following property to the <properties> element previously listed, and set it equal to true.

      <property name="alwaysUseGlobalSender">true</property>

    7. Optional: By default, the email address of the original sender is set as the reply-to address. If you do not want the original sender to appear as the reply-to address, then add the following property to the <properties> element previously listed, and set it equal to false.

      <property name="includeOriginalSenderAsReplyTo">false</property>

      If the alwaysUseGlobalSender property is set to false, then the includeOriginalSenderAsReplyTo property is ignored. If the alwaysUseGlobalSender property is set to true, then the includeOriginalSenderAsReplyTo is optional. The default value for this property is true if the property is added, but no value is defined for it.

    8. Optional: To specify different administrator email addresses for different notifications types per application, search for the notification types you want to change, and then change the value of the sender properties. If there is no sender property, add one.

      If a type element is present, the email address specified for it is used instead of the global administrator address. If you want the global sender address to be used instead of the address specified here, comment out the associated type element. For example, if you want to change the address from which notifications that inform people that they have been added to an activity are sent, edit the value of the sender property in the following notification type:

      add-member

      For example:

      <type name="add-member">
        <channel name="email" enabled="true">
          <property name="sender">
            activities-admin@example.com
          </property>
          <property name="ftl">
      			addMemberMail.ftl
          </property>
        </channel>
       </type>

      No notifications are sent from the Home page application.

    9. Save and close the notification-config.xml file.

    10. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")


    Related

  • Optional post-installation tasks

  • Enable email notifications
  • Start the wsadmin client
  • Hide email addresses
  • Specify an administrator email address for Blogs notifications


    Enable users to specify email notification preferences

    Edit configuration settings to enable users to specify the email address to which they would like notifications sent, the frequency with which they receive notifications, and what language the notification is written in.

    Email notifications must be enabled in IBM Connections for this procedure to have any effect. If you have configured IBM Connections to hide email addresses, you might not want to enable email notifications.

    When you enable users to specify email preferences, a Sets link is available from the product header that users can click to define their email preferences. Otherwise, no user interface settings are made visible to users.

    The following preferences are set by default:

    Table 27. Default email preference settings

    Preference Default setting
    Responses and notifications Individual emails
    Activities Daily newsletter
    Blogs Weekly newsletter
    Bookmarks Weekly newsletter
    Communities Daily newsletter
    Files Individual emails
    Forums Daily newsletter
    People Weekly newsletter
    Tags Weekly newsletter
    Wikis Daily newsletter

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

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

      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.

    3. Enter the following command to check out the notification-config.xml file:

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where

      • temp_dir is the temporary 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.

      • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.

      If you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each application. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile. For example:

      • AIX or Linux:

        LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")

      • Microsoft

        Windows:

        LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Make any of the following changes to the <defaultEmailPreferences> element:

      • To allow users to specify a preferred email address for notifications, change the value of the <allowEmailAddressOverride> element to true. For example:

        <defaultEmailPreferences>
         <allowEmailAddressOverride>true</allowEmailAddressOverride>
          ... 
        </defaultEmailPreferences>

      • Specify whether automatic email notifications that result from one user notifying another or that are sent from the system should be sent to the person in email. If users do not receive the notification in email, they can still view the notifications from the Home page application. To prevent notifications from being sent by email, set <sendEmailsForDirectNotifications> to false.

      • Define the language in which notifications should be written:

        • If you want emails to be displayed in the language that corresponds to the locale that was set in the browser the last time the user accessed the application from the web, then set <useLanguageFromCallingComponent> to true.

        • If you want to define a default language to use for all notification messages all of the time, set <useLanguageFromCallingComponent> to false and specify the language code of the language in the <defaultLanguage> element.
        Users can change these settings from the product user interface; you are just defining the default values here.

        The list of languages present in the Sets page represents the languages that are enabled for the product, which is defined in the <languageSelector> element in LotusConnections-config.xml. For more details, see Enabling users to set a language preference.

      • Edit the following elements:

        <defaultResponsesFrequency>

        Specifies the frequency with which users receive notifications about responses to their postings.
        Valid values include:

        • DAILY: Send a notification email with a list of notifications once a day.

        • INDIVIDUAL: Send an email each time a notification is produced.

        • NONE: Do not send any notifications by email.

        • WEEKLY: Send a notification email with a list of notifications once a week.
        Users can change this setting from the product user interface; you are just defining the default values here.

        <defaultTagFollowFrequency>

        Specifies the frequency with which users receive notifications about tags that they are following.

        Valid values include:

        • DAILY: Send a notification email with a list of notifications once a day.

        • INDIVIDUAL: Send an email each time a notification is produced.

        • NONE: Do not send any notifications by email.

        • WEEKLY: Send a notification email with a list of notifications once a week.
        Users can change this setting from the product user interface; you are just defining the default values here.

        <digestItemsPerCategory>10</digestItemsPerCategory>

        Defines the number of items that display within a category of the daily or weekly digest. The allowable range is 5-25. The default value is 10. This setting is applied globally and cannot be configured per user.

        <replyToEnabled>true</replyToEnabled>

        When set to true, users receive emails with replyTo support. This option is displayed on the Email Sets page for each user. The default value is true.

      For example:

      <defaultEmailPreferences>
        <allowEmailAddressOverride>true</allowEmailAddressOverride>
        <useLanguageFromCallingComponent>false</useLanguageFromCallingComponent>
        <defaultLanguage>es</defaultLanguage>
        <sendEmailsForDirectNotifications>true</sendEmailsForDirectNotifications>
        <defaultResponsesFrequency>INDIVIDUAL</defaultResponsesFrequency>
        <defaultTagFollowFrequency>WEEKLY</defaultTagFollowFrequency>
        <digestItemsPerCategory>10</digestItemsPerCategory>
        <replyToEnabled>true</replyToEnabled>
      </defaultEmailPreferences>

    6. For each application, you can also specify the frequency with which users should receive notifications about content that they are following by editing the defaultFollowFrequency attribute for that application. For example, to define the frequency with which users should receive notifications about content they are following in the Activities application, edit the source element for Activities as follows:

      <source 
       defaultFollowFrequency="DAILY" 
       enabled="true" 
       name="Activities">

    7. Save and close the notification-config.xml file.

    8. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")

    9. Update the version stamp property to force a refresh of users' web browsers, so that they see the email preference changes the next time they access the product. See Required post-customization step.


    Related tasks

  • Start the wsadmin client
  • Set email notification preferences
  • Enable users to set a language preference
  • Required post-customization step


    Disable embedded applications in notifications

    Standard notifications sent from IBM Connections can include an OpenSocial embedded application that is displayed in supported email clients. You can remove embedded applications from all supporting notifications by disabling a configuration property in the notification-config.xml file.

    To run administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details. The notification types listed in the following table include the application/embed+json MIME part that is required for embedded application support. All other notifications support HTML and plain text versions only.

    Table 28. Notification types that support embedded applications

    Application/Embedded application Operation
    Files (specific to a file)

    • Create a file

    • Update a file

    • Comment on a file

    • Like a file

    • Share a file
    Blog entries

    • Create a blog entry

    • Update a blog entry

    • Comment on a blog entry

    • Like a blog entry
    Ideation Blog entries

    • Create an ideation blog idea

    • Update an ideation blog idea

    • Comment on an ideation blog idea
    Forum topics

    • Create a forum topic

    • Update a forum topic

    • Reply to a forum topic
    Status updates

    • Post a status update

    • Comment on a status update

    • Like a status update

    • Repost a status update
    Network invites

    • Send a network invitation

    Embedded applications are only included in standard notifications; users must select the individual email option available from the Email Preferences page to receive them.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

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

      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.

    3. Enter the following command to check out the notification-config.xml file:

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where

      • temp_dir is the temporary 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.

      • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.

      If you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each application. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile. For example:

      • AIX or Linux:

        LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")

      • Microsoft

        Windows:

        LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Locate the following section of the file:

      <properties>
        <property name="globalSenderName">IBM Connections Administrator</property>
        <property name="globalSenderEmailAddress">global-admin@example.com</property>
        <includeMobileLinksInNotifications>false</includeMobileLinksInNotifications>
        <disableEmbeddedAppsInNotifications>false</disableEmbeddedAppsInNotifications>
      </properties>

    6. Change the value of the <disableEmbeddedAppsInNotifications> element to true as follows:

      <disableEmbeddedAppsInNotifications>true</disableEmbeddedAppsInNotifications>
      The default value is false.

    7. Save and close the notification-config.xml file.

    8. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")


    Include mobile links in notifications

    You can enable links to the IBM Connections Mobile service from notifications by updating the value of a property in the notifications configuration file.

    To run administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details. A configuration option in the notification-config.xml file allows you to enable links within notifications to the IBM Connections Mobile service. When this option is enabled, if the notification being sent has a supported view in the Mobile service, an Open in Mobile link will be included in the notification. In standard notifications, the link is appended to the action link bar. In daily and weekly digests, the link is placed on the line after each entry.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

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

      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.

    3. Enter the following command to check out the notification-config.xml file:

      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")

      ...where

      • temp_dir is the temporary 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.

      • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.

      If you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each application. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile. For example:

      • AIX or Linux:

        LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")

      • Microsoft

        Windows:

        LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")

    4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    5. Locate the following section of the file:

      <properties>
        <property name="globalSenderName">IBM Connections Administrator</property>
        <property name="globalSenderEmailAddress">global-admin@example.com</property>
        <includeMobileLinksInNotifications>false</includeMobileLinksInNotifications>
        <disableEmbeddedAppsInNotifications>false</disableEmbeddedAppsInNotifications>
      </properties>

    6. Change the value of the <includeMobileLinksInNotifications> element to true as follows:

      <includeMobileLinksInNotifications>true</includeMobileLinksInNotifications>
      The default value is false.

    7. Save and close the notification-config.xml file.

    8. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")


    Remove nodes from a cluster

    You can remove IBM WebSphere Administration Server nodes from a cluster using the Integrated Solutions Console or using a command.


    Related tasks

  • Remove a node from the index management table


    Remove nodes from a cluster using the Integrated Solutions Console

    You can remove nodes from a cluster using the IBM WebSphere Application Server Integrated Solutions Console.

    To remove a node from a cluster, complete the following steps:

    1. From the Integrated Solutions Console, select System Administration > Nodes.

    2. Select the check box next to the node to delete and click Remove Node.

      If you cannot remove the node by clicking Remove Node, remove the node from the configuration by clicking Force Delete.

    3. Restart WebSphere Application Server.


    Related tasks

  • Remove nodes from a cluster from the command line


    Remove nodes from a cluster from the command line

    Use the removeNode command to remove an IBM WebSphere Application Server node from a Network Deployment distributed administration cell.

    For additional information about the removeNode command, refer to the following web page:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Frxml_removenode.html

    To remove a node from a cluster, complete the following steps:

    1. Log in to the node to remove from the cluster.

    2. Open a command prompt and change to the profile_root/bin directory.

    3. Run one of the following scripts to remove the node:

      • AIX or Linux:

        ./removenode.sh

        [-username uid] [-password pwd]

      • Windows:

        removenode.bat

        [-username uid] [-password pwd]

      where:

      • uid is the Deployment Manager administrator user name

      • pwd is the Deployment Manager administrator password


    Related tasks

  • Remove nodes from a cluster using the Integrated Solutions Console


    Back up and restore data

    You must back up both the application DBs and content stores on a regular schedule using the methods documented by the vendor from whom you purchased the database and file system you are using.

    When you restore data for an application that is also available from the Communities application, you must also restore the data in the Communities application to keep the two in sync. See Recovering from a database failure for more details.

    Manage content

    Use superusers, moderation, and other methods to manage IBM Connections content.


    Administer application content

    To view and control content in your deployment, you can create a dedicated global administrator or administrators with administrative capabilities over content in the applications.

    A global administrator can edit and remove objectionable content. The Moderation feature can assist in this process, but not all components have the Moderation implemented. Also, although some wsadmin commands can be helpful with removing objectionable content, they do not cover all situations. For example, in the event that someone who is the only Owner of some content (such as the only owner of an activity or community) and that person leaves the organization or is out of office for an extended time period, the Global Administrator could add additional owners and even remove the original owner if needed.

    Table 29. Summary of administrative capabilities for Connections applications.

    IBM strongly recommends creating a new user account solely for these administrative purposes. This is especially true for administrators in Activities. Add administrative abilities to your own account in other applications can result in confusion and can lead to accidental modification of data. Also recommended is that the same person (or multiple people) be given an admin role across all components, rather than assigning the admin role to someone different for each component, particularly for Communities, which might have widgets added from multiple components.

    Application Administrative capabilities Steps

    Activities

    • Access any activity returned by search

    • Open any activity using a URL address

    • Modify any activity

    • Delete any activity in Trash

    • See private entries. They cannot change privacy settings.

    To view and control Activities content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Activities J2EE admin role. See Roles.

    Blogs and Ideation Blogs

    • Configure administration settings

    • Edit any blog or blog entry

    • Delete any blog, entry, or comment

    To view and control Blogs and Ideation Blogs content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Blogs J2EE admin role. See Roles.

    When the user logs into Blogs or Ideation Blogs they will see an Administration tab where they can configure administration settings.

    Bookmarks

    • Remove unwanted links

    There is no way to create a comparable administrator for Bookmarks. However, adding a user to the J2EE search-admin role allows that user to see any bookmark in Bookmark search results. Any administrator can use the Bookmarks wsadmin commands to remove unwanted links from the Bookmarks application.

    Communities

    • Access to any community, public or restricted

    • Rights to view and update community settings, members, invitations, bookmarks and feeds

    • With some extra configuration, rights to access and edit content in remote application widgets

    • Users with this role will see an additional Administration link that will allow them to administer the Community Catalog.

    To view and control Communities content, follow steps in Administering Communities content.

    Files

    • Editor access on all files

    To view and control Files content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Files J2EE admin role. See Roles.

    Forums

    • Edit, update, or delete any forum, forum topic, or reply

    To view and control Forums content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Forums J2EE admin role. See Roles.

    Home page

    • Administer site-wide settings for the Home page from the Home page administration user interface or using the wsadmin client

    • Add custom widgets for use on the Home page

    • Enable and disable widgets

    • Enable and disable the My Page view

    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.

    News

    Events are generated by the various IBM Connections applications whenever an activity occurs in the system. Information about these events is stored in the News repository, and the Home page application pulls data from the repository to display only the events that are relevant to a particular user on that user's Home page. You can configure News configuration settings to control how the information that the Home page receives from the News repository is stored and administered.

    The administrators are the users mapped in the admin J2EE role in the News application.

    • Register a new application or source type so that it displays in the IBM Connections user interface.

    • Update, enable, or disable an application registration.

    • Check out/check in News repository configuration files.

    • Remove single or multiple reply-to IDs.

    • Remove all microblog and associated data for a community from the News repository.

    • Synchronize news data with other applications.

    • Return an XML synchronization report of the community resources held in the News repository.

    • Return information about a scheduled task.

    • Delete any status update and comment on status updates in the system, including community status updates.

    • Create a status update in any community.

    • Change the status update settings in any community.

    • View the Activity Stream feed from any community

    View and control News content using scripts accessed using the wsadmin client as detailed in the Administering the News repository section.

    Profiles

    • Delete photos

    • Edit user About Me and Background information

    • Activate or deactivate any profile

    • Edit core user attributes

    To view and control Profiles content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Profiles J2EE admin role. See Roles.

    You must use wsadmin commands to delete photos, edit About Me and Background information, and activate or inactivate any profile. See Profiles administrative commands.

    Use the Profiles REST ATOM API to edit core user attributes. See Profiles Administration API. Attributes you cannot edit are link roles, friends, tags, and the following and follower lists. To edit those attributes you must use direct SQL.

    Search

    Search in any application returns all content. For example, a search in Communities will return private communities even if you are not a member.

    To have search return all content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Search J2EE search-admin role. See Roles.

    Wikis

    • Search returns all content

    • Create, edit, read, and delete any content

    • Remove a wiki creator from wiki membership

    To view and control Wikis content:

    1. Find or create a user who will be dedicated to this purpose.

    2. Add the user to the Wikis J2EE admin role. See Roles.

    Once a user creates a wiki, they are the owner of that wiki. An administrator can add new owners to the wiki, but the creator of the wiki cannot be removed from the membership. Direct SQL manipulation on the database is required to reassign the creator and remove them from the membership.


    Related

  • Profiles Administration API

  • Administer community content
  • Assign people to J2EE roles

  • Profiles administrative commands


    Administer community content

    You can create a dedicated administrator with access to all communities, public or restricted. This administrator has granular control over communities content, including the ability to edit or remove inappropriate content. This administrator is also required for IBM Lotus Sametime integration with IBM Connections.

    Global communities administrators can access all communities with rights to view and update community settings, members, invitations, bookmarks and feeds; however, within restricted communities the global administrator cannot view and manage remote widget applications, such as Activities, Blogs, Ideation Blogs, Files, Forums, and Wikis. To manage content in remote widget applications, you add the communities global administrator to the J2EE admin role for all of these applications. See Assigning people to J2EE roles for detailed information. After communities global administrator is in the admin role for those applications, she can manage content in any of them, whether the applications are standalone or remote widgets in a community.

    You can use search to find private communities, but add the global administrator to the search-admin role of the Search application. Use the Public Communities view to find public and moderated communities.

    Global administrators cannot add or remove widgets from communities by default. They must log into the community as the global administrator, and then add themselves as a community member with Owner access.

    The global administrator role is not supported on mobile devices. Global administrators must use a supported browser.

    1. Find or create a user who will be dedicated to administering content, and add them to the J2EE admin role of Communities, Activities, Blogs, Files, Forums, and Wikis. Also add them to the search-admin role of Search. See Roles. In the following steps, we will ensure that the communities-config.xml file contains the "admin" block of grant statements and is not commented out.

    2. 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

    3. Access and check out the Communities configuration files:

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

        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 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:

        CommunitiesConfigService.checkOutPolicyConfig("/opt/my_temp_dir", "CommServerNode01Cell")

    4. From the temporary directory to which you just checked out the IBM Connections configuration files, open the communities-policy.xml file in a text editor.

    5. Make sure the file contains the following grant statement, and that it is not "commented out" (disabled).

      <comm:grant>
      	<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>

    6. Save your changes to the communities-policy.xml file.

    7. Check in the updated file using the following wsadmin client command:

      CommunitiesConfigService.checkInPolicyConfig("<working_directory>", "<cell_name>")

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

    9. Stop and restart the server hosting the Communities application.


    Results

    When the global administrator specified in the various J2EE roles logs in to Communities, she should be able to view and edit all communities and community resources.


    Related

  • Manage inappropriate content
  • Manage community content
  • Profiles Administration API

  • Add owners and members to a community
  • Assign people to J2EE roles

  • Administer application content


    Moderation overview

    Find out what level of content moderation is available for the applications in version 3 and version 3.0.1.

    If the moderation application is installed and enabled, you can define a person or set of people who will review and approve the content that users add to certain applications before it is published or review and act on content that has been flagged as problematic.

    Moderation can be configured to make moderation available for global moderators, community owners or blog owners, as follows:

    Global moderators

    User assigned the global-moderator J2EE role for the Moderation component can review and manage content for blogs, forums, and community files from the global moderation interface, which is accessed using the Moderation link in the application menu bar. The link is only visible to users who have been assigned the J2EE global-moderator role. For more information about assigning roles, see Roles.

    Community moderators

    When owner moderation is enabled for communities, community owners can access moderation options for their community by opening the community and selecting Community Actions > Moderate Community. Community moderators can only manage the content of communities that they own, and they can only do so from the community moderation interface; they cannot access the global moderation interface.

    You can specify whether owner moderation is enabled by changing the value of the ownerModerate setting in the contentreview-config.xml file. For more information, see Managing content moderation and flagged content.

    Blogs moderators

    If the Moderation service is enabled, you can moderate Blogs from the central moderation interface. If the Moderation service is not enabled, you can moderate Blogs from a moderation interface available from the Blogs application. When owner moderation is enabled for Blogs, blog owners can access moderation options for a blog they own by opening the blog and choosing the Moderation tab. If moderation is enabled for a blog, the blog owner can review content before it is posted to a blog. In addition, users of the Blogs application have the options to flag content as inappropriate. When content is flagged, the moderator is informed and can take action from the moderation interface.

    In addition to the user interfaces available for moderation, there is a public moderation API that can be leveraged by third-party developers to extend the capabilities of content moderation.


    Related

  • Moderate blogs programmatically
  • Moderate community files and comments programmatically
  • Moderate forum content programmatically
  • Moderate forums
  • Moderate the content in a community
  • Manage inappropriate content


    Moderation roles

    Monitor and control the content of blogs, community files, and forums using the moderation tools.

    As the IBM Connections administrator, you can do the following to enable and configure moderation:

    • Enable or disable moderation for content before it is published and after it is published.

    • Assign the Global-Moderator role to users so they can moderate all content from a central UI.

    • Set up categories and route which moderators see what flagged content.

    • Enable owner moderation for blogs, forums, or community files so that owners can publish their content directly to a blog, forum, or community file and moderate content for the blogs, forums, or community files they own.

    When moderation is enabled, users can:

    • Flag published blog or forum posts or community files that are inappropriate

    • Submit content for review.

    • Blog and forum users can edit their own published content.

    • In addition, Blog owners can view their own submitted, rejected, or published content.

    Users you have assigned the Global-Moderator role can:

    • Approve, reject or delete submitted content.

    • Dismiss, quarantine or delete flagged content and restore quarantined content.

    • Provide an explanation to the author when rejecting submitted content, dismissing or quarantining flagged content, or when restoring quarantined content.

    • View and directly edit submitted content or comments

    When owner moderation is enabled, blog, forum, or community owners can manage the content in the blog, forum, or community files they own.


    Moderated content states

    When content is moderated, it can be in a variety of states before and after being published.

    The state that content is in dictates

    ...where it is in the pre-moderation or post-moderation workflow and controls whether the content is available to users or unavailable because it has not been approved or is in quarantine.


    Content states before publication

    Content that requires review and approval before it is published can be in one of the following states:

    • Pending: The moderator can approve or reject the content.

    • Active: Content is published

    • Rejected: Content will not be published.


    Content states after publication

    Content that has already been published but requires review, for example, if it was flagged as inappropriate, can be in one of the following states:

    • Active with flags: The content is published but it may be flagged for review. The moderator can dismiss flags or quarantine the content.

    • Active: The content is published.

    • Quarantined : the content is quarantined and notification is sent to the author


    Manage content moderation and flagged content

    Edit configuration property settings in the contentreview-config.xml file to enable moderation and to specify what moderators should receive email notification when content requires moderation. Restart your applications to see the changes.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    Configure IBM Connections using scripts accessed with the wsadmin client. These scripts use the connectionsConfig object available in WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named contentreview-config.xml.

    The properties in the contentreview-config.xml file cannot be edited using the updateConfig command nor displayed using the showConfig command. Instead, check out the configuration file using the checkOutContentConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, save the file in Unicode format and check the file back in using the checkInContentConfig command and restart the application servers to see the changes.

    If moderation is enabled, moderators can review and approve blog comments and entries, forum posts, and community files from a central location. You can configure who can review and approve content with a setting in the contentreview-config.xml file as follows:

    • If ownerModerate=true in contentreview-config.xml, a blog, forum, or community owner can moderate content for a blog, forum, or community they own. In addition, content an owner creates is published directly, without requiring moderation.

    • If ownerModerate=false in contentreview-config.xml, only users assigned the J2EE moderator role in the WAS console can manage content on the site. For information on assigning users to the moderator role, see the topic Roles.

    You can also configure the flag inappropriate content application for Blogs and Forums to specify categories for what type of content to flag, and to specify designated reviewers who will receive email notifications when content is flagged. There are two default categories for inappropriate content: Legal issue and Human resources issue. You can edit those categories, add new ones, or remove all categories. The file is also configured with placeholders for the email addresses of designated reviewers. Change those to actual email addresses for users assigned the moderator role who can review flagged content.

    When you enable moderation, users cannot upload thumbnail images in Media Gallery widgets.

    To change moderation configuration settings:

    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. 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. See the topic Starting the wsadmin client.

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

      1. 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. Check out the IBM Connections content configuration file using the following command:

        LCConfigService.checkOutContentReviewConfig("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.

        • 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/Linux:

          LCConfigService.checkOutContentReviewConfig("/opt/temp","foo01Cell01")

        • Microsoft

          Windows:

          LCConfigService.checkOutContentReviewConfig("c:/temp","foo01Cell01")

    3. From the temporary directory to which you just checked out the IBM Connections configuration files, open the contentreview-config.xml file in a Unicode text editor.

      Editing the file using a standard text editor that does not support Unicode could corrupt the file.

    4. To configure settings for managing content in the pre-moderated state, that is, before it is published or when it is updated, set the following options for each application:

      contentApproval

      Set to "true" to require moderation for the specified application. By default this is set to "false". When the setting is set to false, moderation is not automatically enforced for an application, but moderation API command and filters still work. Moderators can still perform moderation tasks.

      ownerModerate

      Set to "true" to specify that blog owners and community owners can moderate content in blogs or communities they own. By default this is set to "false" so that only users assigned the J2EE moderator role in the WAS console can moderate content. For information on assigning users to the moderator role, see the topic Roles.
      In the following example, moderation is enforced for blogs so that all content must be approved by a moderator before it is published or updated in a blog. Each blog owner can moderate content for the blogs they own.

      <serviceConfiguration>
      <service id="blogs">
      <contentApproval enabled="true">
        <ownerModerate enabled="true" /> 
        </contentApproval>

    5. To configure settings for managing content in the post-moderated state, that is, content that is flagged by a user after it is published. set the following options for each application:

      contentFlagging

      Set to "true" to require moderation for flagged content. By default this is set to "false". When the setting is set to false, this means the end user can't flag content from the user interface or using an API command. Blogs Moderation API and filters will still work. Moderators can still perform moderation tasks. Files and Forums API commands will return errors.

      ownerModerate

      Set to "true" to specify that forum users can moderate their own flagged content. By default this is set to "false" so that only users assigned the J2EE moderator role in the WAS console can moderate. For information on assigning users to the moderator role, see the topic Roles.

      IssueCategorization

      Set to "true" to display a list of categories so that users can choose one when flagging content. By default this is set to "false."

      This feature is not available for Files.

      automaticQuarantine

      Forums only. Set to "true" and specify an integer as a value for threshold. When a forum post is flagged the number of times specified for the threshold value, the post is automatically quarantined and removed from the forum. By default this is set to "false."

      flagCategory

      To make a <flagCategory> element available for an application, first define it with a unique id and descriptions in the desired languages to the <flaggedCategories> section of the configuration file, then add it to the <IssueCategorization> section for the application.

      reviewer email

      To add designated reviewers who will receive notification email when content is flagged, replace the placeholder email names for each category with the email addresses of designated reviewers who are assigned the moderator role.

      You can also configure a group email here, but each member of the group must be assigned the moderator role.

      In the following example, flagging is enabled for forums and each forum owner can moderate flagged content for the forums they own. Issue categorization is enabled so that users can select a category when flagging content. If ten users flag a forum post, it is automatically quarantined and removed from the forum.

      <service id="forums">
      <contentApproval enabled="true">
        <ownerModerate enabled="true" /> 
        </contentApproval>
       <contentFlagging enabled="true">
        <ownerModerate enabled="true" /> 
        <automaticQuarantine enabled="true" threshold="10" /> 
       <issueCategorization enabled="true">
       <flagCategory id="001">
        <reviewer email="reviewer1@acme.com" /> 
        <reviewer email="reviewer2@acme.com" /> 
        </flagCategory>
      <flagCategory id="002">
        <reviewer email="reviewer2@acme.com" /> 
        <reviewer email="reviewer3@acme.com" /> 
        </flagCategory>
        </issueCategorization>
        </contentFlagging>

    6. To add a category for flagged content, add a new <flagCategory> element with a unique id and descriptions in the desired languages to the <flaggedCategories> section of the configuration file.
      Tip: The fastest way to add a content category is to copy an existing <flagCategory> element, paste it into the file and edit the ID and descriptions in the required languages. For example, to add a content category for "Offensive Language" add the following:

      <flagCategory>
          <id>003</id>
          <description xml:lang="en">Offensive Language</description>
          <description xml:lang="fr">French equivalent</description>
          <description xml:lang="it">Italian equivalent</description>
         </flagCategory>
      Note that the new ID is .003.. This must be unique. As this example shows, you can also add language statements and provide translated strings for category names.

    7. To specify who should receive email notification of content awaiting moderation or flagged content that needs review, replace the placeholder email names in the following section with the email addresses of users assigned the moderator role for that service.

      <moderator email="moderator3@acme.com" /> 
        <moderator email="moderator4@acme.com" /> 

    8. Save your changes to the contentreview-config.xml file.

    9. Check the file back in, using the command:

      LCConfigService.checkInContentReviewConfig(<temp-dir>,"<cell-name>")
      During the check-in process validation is done to ensure no xml syntax errors are in the file.

    10. Restart the affected applications to see the changes.


    Related

  • Optional post-installation tasks
  • Moderate blog content
  • Moderated content states for blogs
  • Moderate forums
  • Moderate the content in a community

  • Start the wsadmin client
  • Specify an administrator email address for Blogs notifications
  • Manage flagged content for a blog
  • Moderate Blog comments


    Moderate content before it is published

    Review before it is published to make sure it meets your standards.

    When content is submitted by a user, it is marked for review and it displays on the Content Approval section of the Moderation tab. An authorized moderator can view the state of submitted content and take action on it. Content can be:

    • Blog entries or comments

    • Community files content or comments

    • Forum posts or comments

    The workflow described in this topic requires that valid email addresses are configured for the reviewers and that email notifications are enabled for your Connections deployment.

    When a user submits content, it sets in motion a workflow for reviewing the content. The workflow goes as follows:

    1. Notification is sent to the moderator that content has been submitted. The notification includes information about the person submitting the content and a link to the content. The content is posted to the Content Approval section in the Moderation interface for viewing and managing content before it is published.

    2. The moderator reviews the content and acts on it.

    3. If the content is acceptable, the reviewer approves it and it is published. The author receives notification email that the content is approved.

    4. If the content is considered inappropriate, the reviewer rejects the content. In this case, the author is notified by email. The posting appears on the Rejected panel.

    5. If the content is considered inappropriate, the reviewer can delete it from either the Require Approval or the Rejected tabs.
    Follow these steps to review content and take action.

    1. Click the Moderation tab.

    2. Click Content Approval in the navigation pane and then select the type of content to work with - Blogs, Files, or Forums. Content awaiting decisions are displayed along with information on who submitted the content.

    3. Review an item and choose one of these actions:

      Option Description
      Approve Publish the content.

      Reject The content is moved to the Rejected tab where you can later approve it or delete it. Blog content that is rejected can be revised by the author and resubmitted for approval.

      Delete Permanently remove the content.


    Related

  • Moderate forums
  • Moderate the content in a community


    Moderate published content that is flagged

    Review published content that has been flagged as inappropriate and take action on flagged entries and comments.

    When content is flagged by a user, it is marked for review and it displays on the Flagged Content section of the Moderation tab. An authorized moderator can view the history and state of flagged content and take action on it. Flagged content can be:

    • Blog entries or comments

    • Community files content or comments

    • Forum posts

    The workflow described in this topic requires that valid email addresses are configured for the reviewers and that email notifications are enabled for your Connections deployment.

    When a user flags content as inappropriate, it sets in motion a workflow for reviewing and resolving the issue. The workflow goes as follows:

    1. Notification is sent to the moderator that content has been flagged. The notification includes information about the person flagging the content, and a link to the content in the Moderation interface. The entry or comment is posted to the Flagged Content section in the Moderation interface for viewing and managing flagged content.

      There is a setting in the contentreview-config.xml file which determines whether notification is sent to a moderator or content reviewer as follows:

      • If issueCategorization is disabled, then notification is sent to all the moderators.

      • If issueCategorization is enabled, then the notification will only be sent to the reviewers defined under each issue category, but if reviewer information is not provided, the notification will still be sent to all the moderators.

    2. The moderator reviews the content and acts on it.

    3. If the reviewer does not think the content is inappropriate, the flag is dismissed and the content remains in the blog or community.

    4. If the content is considered inappropriate, the reviewer quarantines the posting, which means it is removed and placed in a quarantined state. In this case, the author is notified. The posting appears on the Quarantined panel.

    5. If the content is considered inappropriate, the reviewer can delete it from either the Flagged for Review or the Quarantined tabs.
    Follow these steps to review flagged content and take action.

    1. Click the Moderation tab.

    2. Click Flagged Content in the navigation pane and then select the type of content to work with - Blogs, Files, or Forums. Content awaiting decisions are displayed along with information on who flagged the content and why.

    3. Review a flagged entry and choose one of these actions:

      Option Description
      Dismiss Dismiss the flag. The content remains available.

      Quarantine This option turns the post in question to a draft and removes it to a quarantine area so it is not available to readers. This option prompts you to send notification to the posting author explaining your reason for removing the post and providing a link so the author can revise the content. Quarantined content can be restored or deleted.

      Delete Permanently remove the content.

    4. View content that you have quarantined, select one or more items, and take one of the following actions:

      • Click Restore to dismiss the flag and restore the content to a published state.

      • Click Delete to permanently remove the content.


    Related

  • Moderate forums
  • Moderate the content in a community


    Manage moderation when email is disabled

    If email is disabled or if users do not have email addresses, some parts of the moderation workflow must be completed manually.

    If IBM Connections is configured so that email notification is disabled, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:

    • When an entry is flagged as inappropriate, the reviewers will not receive email indicating there is a potentially offensive posting. Reviewers will have to periodically visit the Flagged Content section of the Moderation interface to see what content needs action and then manually send confirmation notification messages to the user who flagged the content.

    • If the reviewer quarantines an item, the owner will not receive email notifications. The reviewer will have to manually send a notification message to the content owner.

    If your organization includes people with no email, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:

    • If a reviewer has no email, when an entry or comment is flagged as inappropriate, the reviewer will not receive email indicating there is a potentially offensive posting. Reviewers will have to periodically visit the Flagged Entries or Flagged Comments pages of the Moderation interface to see what entries need action.

    • If the content owner has no email, and the reviewer quarantines an item, the content owner will not receive email notifications.

    • If the person who flagged the message as inappropriate has no email, the person will not receive a confirmation email that the post they found offensive is being reviewed.


    Configure moderation for communities

    Configure moderation for communities so that owners can review and manage the blog, file, and forum content directly in the community. Owners can control what content is added by members (pre-moderation) and remove anything that might be considered inappropriate in your organization (post-moderation).

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    Configure IBM Connections using scripts accessed with the wsadmin client. These scripts use the connectionsConfig object available in WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named contentreview-config.xml.

    The properties in the contentreview-config.xml file cannot be edited using the updateConfig command nor displayed using the showConfig command. Instead, check out the configuration file using the checkOutContentReviewConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, save the file in Unicode format and check the file back in using the checkInContentReviewConfig command and restart the application servers to see the changes. When owner moderation is enabled for communities, community owners can access moderation options for their community by opening the community and selecting Community Actions > Moderate Community. Community moderators only can manage the content of communities that they own.

    Administrators configure the following section of the contentreview-config.xml file to set community moderation:

    <commModerationConfiguration>
    	<preModeration>
    		<forceForAllCommunities enabled=boolean value of true or false />
    		<enabledByCreation enabled="true" />
    	</preModeration>
    	<postModeration>
    		<forceForAllCommunities enabled=boolean value of true or false />
    		<enabledByCreation enabled="true" />
    	</postModeration>
    </commModerationConfiguration>
    
    <service id="blogs">
    		<contentApproval enabled=boolean value of true or false>
    		    <ownerModerate enabled=boolean value of true or false/>
    	</contentApproval>
    		<contentFlagging enabled=boolean value of true or false>
    		    <ownerModerate enabled=boolean value of true or false/>
    
    <service id="files">
    		<contentApproval enabled=boolean value of true or false>
    		    <ownerModerate enabled=boolean value of true or false/>
            </contentApproval>
    		<contentFlagging enabled=boolean value of true or false>
    		    <ownerModerate enabled=boolean value of true or false/>
    
    
    <service id="forums">
    		<contentApproval enabled=boolean value of true or false>
               		 <ownerModerate enabled=boolean value of true or false/>
           </contentApproval>
    		<contentFlagging enabled=boolean value of true or false>
    			<ownerModerate enabled=boolean value of true or false/>

    Where:

    preModeration

    Community owners must approve all content before it can be posted.

    postModeration

    Viewers can flag content.

    forceForAllCommunities

    Set to "true" to require moderation for communities. By default this attribute is set to "false". When the setting is set to false, moderation is not automatically required for a community, but moderation API command and filters still work. Moderators can still perform moderation tasks.

    enabledByCreation

    Set determines if the moderation check boxes in the Start Community form should be checked when a user clicks Start a Community.

    contentApproval

    Set to "true" to require moderation for the specified application. By default this attribute is set to "false". When the setting is set to false, moderation is not automatically enforced for an application, but moderation API command and filters still work. Moderators can still perform moderation tasks.

    contentFlagging

    Set to "true" to require moderation for flagged content. By default this attribute is set to "false". When the setting is set to false, the user cannot flag content from the user interface or using an API command. Blogs Moderation API and filters still work. Moderators can still perform moderation tasks. Files and Forums API commands returns errors.

    If you upgraded IBM Connections from release 2.5 to release 3.0 or higher, the default for Blogs is "true" for compatibility reasons.

    ownerModerate

    Must be set to "true" to specify that community owners can moderate the content in communities that they own, otherwise it is set to "false". If contentFlagging or contentApproval for a service is set to true, then ownerModerate must be set to true. If contentFlagging or contentApproval for a service is set to false, then ownerModerate must be set to false.

    To change community moderation 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. 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. See the topic Starting the wsadmin client.

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

      1. 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. Check out the IBM Connections content configuration file using the following command:

        LCConfigService.checkOutContentReviewConfig("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.

        • 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/Linux:

          LCConfigService.checkOutContentReviewConfig("/opt/temp","foo01Cell01")

        • Microsoft

          Windows:

          LCConfigService.checkOutContentReviewConfig("c:/temp","foo01Cell01")

    3. From the temporary directory to which you just checked out the IBM Connections configuration files, open the contentreview-config.xml file in a Unicode text editor.

      Editing the file using a standard text editor that does not support Unicode could corrupt the file.

    4. Determine if you want to give owners the ability to turn pre-approval on and off, or if you want to force owners to approve content.

      Table 30. Owners must approve all content

      Force pre-approval Sample code What the owner sees in the user interface
      Let owners turn off pre-approval

      <preModeration>
      <forceForAllCommunities enabled="false">
      .....
      </premoderation>

      Owners can clear the check box.

      Owners must approve all content (...)

      Force owners to pre-approve content

      <preModeration>
      <forceForAllCommunities enabled="true">
      .....
      </premoderation>

      Owners cannot clear the check box.

      Owners must approve all content (...)

    5. After you decide whether or not you want to force owners to pre-approve content, you should select the specific content that requires pre-approval.

      Table 31. Determine the content that requires approval

      Content that requires owner.s approval Sample code What owner sees in the user interface
      Blog content requires the owner.s approval

      <service id="blogs">
      <contentApproval enabled="true">
      <ownerModerate enabled= "true">
      </contentApproval>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Blogs)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Blogs)

      Files content requires the owner.s approval

      <service id="files">
      <contentApproval enabled="true">
      <ownerModerate enabled= "true">
      </contentApproval>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Files)

      Forums content requires the owner.s approval

      <service id="Forums">
      <contentApproval enabled="true">
      <ownerModerate enabled= "true">
      </contentApproval>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Forums)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Forums)

      Blogs and Files require the owner.s approval. Forums does not.

      <service id="blogs">
      <contentApproval enabled="true">
      <ownerModerate enabled= "true">
      </contentApproval>
      <service id="files">
      <contentApproval enabled="true">
      <ownerModerate enabled= "true">
      </contentApproval>
      <service id="Forums">
      <contentApproval enabled="false">
      <ownerModerate enabled= "true">
      </contentApproval>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Blogs, Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Blogs, Files)

      Files requires the owner.s approval.

      Blogs content is moderated in the community, but only the global moderator can approve it. The community owner cannot manage content or change the moderation options of Blogs in his community.

      <service id="blogs">
      <contentApproval enabled= "true">
      <ownerModerate enabled= "false">
      <service id="files">
      <contentApproval enabled= "true">
      <ownerModerate enabled= "true">

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Files)

      Files requires the owner.s approval.

      Blogs content does not require any approval. All content is published directly without approval.

      <service id="blogs">
      <contentApproval enabled= "false">
      <ownerModerate enabled= "false">
      <service id="files">
      <contentApproval enabled= "true">
      <ownerModerate enabled= "true">

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Owners must approve all content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

      Owners must approve all content (Files)

    6. Determine if you want to give owners the ability to let people flag inappropriate content. You can let owners decide if they want to include this ability in their community, or you can force them to offer this ability in their community.

      Table 32. Viewers can flag inappropriate content

      Force pre-approval Sample code What the owner sees in the user interface
      Let owners turn off flagging

      <postModeration>
      <forceForAllCommunities enabled="false">
      .....
      </postmoderation>

      Owners can clear the check box.

      Viewers can flag inappropriate content (...)

      Force owners to viewers to flag content.

      <postModeration>
      <forceForAllCommunities enabled="true">
      .....
      </postmoderation>

      Owners cannot clear the check box.

      Viewers can flag inappropriate content (...)

    7. After you decide if you want to force owners to let viewers flag content, select the specific widget where they can flag content.

      Table 33. Determine the content that can be flagged

      Content that can be flagged Sample code What owner sees in the user interface
      Blog content can be flagged as inappropriate by viewers

      <service id="blogs">
      <contentFlagging enabled="true">
      <ownerModerate enabled="true"/>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Blogs)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Blogs)

      Files content can be flagged as inappropriate by viewers

      <service id="files">
      <contentFlagging enabled="true">
      <ownerModerate enabled="true"/>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Files)

      Forums content can be flagged as inappropriate by viewers

      <service id="Forums">
      <contentFlagging enabled="true">
      <ownerModerate enabled="true"/>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Forums)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Forums)

      Files and Forums content can be flagged as inappropriate by viewers. Blogs cannot.

      <service id="blogs">
      <contentFlagging enabled="false">
      <ownerModerate enabled="false"/>
      <service id="files">
      <contentFlagging enabled="true">
      <ownerModerate enabled="true"/>
      <service id="Forums">
      <contentFlagging enabled="true">
      <ownerModerate enabled="true"/>

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Files, Forums)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Files, Forums)

      Files content can be flagged as inappropriate by viewers.

      Blogs content can be flagged as inappropriate by viewers, but only the global moderator can take action. The community owner cannot manage content or change the moderation options of Blogs in his community.

      <service id="blogs">
      <contentFlagging enabled="true">
      <ownerModerate enabled= "false">
      <service id="files">
      <contentFlagging enabled="true">
      <ownerModerate enabled= "true">

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Files)

      Files content can be flagged as inappropriate by viewers.

      Blogs content cannot be flagged as inappropriate. The community owner cannot manage flagged content or change the flag moderation options of Blogs in his community.

      <service id="blogs">
      <contentFlagging enabled="false">
      <ownerModerate enabled= "false">
      <service id="files">
      <contentFlagging enabled="true">
      <ownerModerate enabled= "true">

      If forceForAllCommunities is set to false, the check box can be cleared by owners.

      Viewers can flag inappropriate content (Files)

      If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

      Viewers can flag inappropriate content (Files)

    Administer the Widget container

    The Widget Container is the IBM Connections-specific integration of the Common Rendering Engine, also known as the CRE.

    The CRE is the successor to Mashup Enabler and adds the ability to render OpenSocial gadgets as well as iWidgets. Throughout the IBM Connections documentation, the Connections instance of CRE will be referred to as the Widget Container. This section of the documentation is specific to the administration of the Widget Container. More details on the CRE in general can be found in the IBM Social Business Development wiki.

    If you wish to add gadgets deployed externally, such as iGoogle gadgets, 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.


    Administer gadgets for IBM Connections and widgets for Home page

    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

    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.


    Related tasks

  • Configure the AJAX proxy for a specific application
  • Configure the Home page administrator


    Enable 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 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 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 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.


    Related tasks

  • Disable widgets


    Gadget registration commands

    Administrators can use NewsWidgetCatalogService commands to register gadgets, particularly if the IBM Connections Home page application, with its administrative interface, has not been installed.


    Flag constants used for widget policy settings

    GadgetFlags

    TRUSTED use to indicate that a gadget is 'trusted' and should be granted access to the non-base gadget features.

    SSO indicates that a particular gadget is granted access to the SSO feature.

    WidgetContexts

    UPDATE indicates that this widget is applicable to the updates page of the Homepage.

    WIDGET indicates that this widget is applicable to the widgets page of the Homepage.

    SHAREDIALOG indicates that this gadget is applicable to the share dialog.

    EMBEDXP indicates that this gadget is provides an embedded experience.


    Sets available for widgets

    Before using any NewsWidgetCatalogService commands, be sure to run newsAdmin.py as described in the first two steps of the topic Access the News configuration file. The following table describes the settings available for widgets:

    Table 34. Description of the settings available for widgets

    Sets Description
    widgetId READONLY The id of the widget.
    title REQUIRED The title for the widget in the catalog.
    text REQUIRED Descriptive text for the widget in the catalog.
    url REQUIRED URL for the widget.
    secureUrl Alternate 'secure' (HTTPS) URL for the widget XML.
    iconUrl The URL for the widget icon. This icon is placed next to the widget in the widget catalog.
    secureIconUrl Alternate 'secure' (HTTPS) URL for the widget icon. This icon is placed next to the widget in the widget catalog.
    previewImage Set for a URL to an optional preview image.
    categoryName Sets the category for the widget to be displayed in if it is available in the 'customize' panel. Valid values for this are the name of a Connections application (for example: 'profile', 'wikis', 'files') in lowercase.
    isSystem READONLY: Indicates if this is a 'system' defined widget. These should not be altered as a rule.
    isHomepageSpecific Indicates if the widget is homepage specific. This setting is used by Homepage iWidgets.
    isDefaultOpened This indicates if the particular widget should be placed on the widgets page (if applicable) for new users.
    multipleInstanceAllowed This indicates if the user may place multiple instances of a widget onto the widgets or updates page. This setting is only valid for iWidgets.
    isGadget Indicates whether this is a OpenSocial gadget (true) or iWidget (false).
    policyFlags Also see GadgetFlags. List of policy flags set for this widget. For the 4.0 release, this setting is only relevant for gadgets.
    enabled Indicates if this widget is enabled or disabled.
    prereqs This is a comma-separated list of applications that are required for this widget to be enabled. The widget is implicitly disabled if the list of prerequisites is not met.
    appContexts Also see WidgetContexts. Indicates the contexts

    ...where this widget is intended to be used.

    proxyPolicy Specifies the proxy policy access for custom gadgets. Also see proxyPolicy constant.


    Constants for enablement

    Enablement

    ALL returns both enabled and disabled widgets

    ENABLED returns only enabled widgets

    DISABLED returns only disabled widgets


    Constants for True and False

    Constant for True

    TRUE=1

    Constant for False

    FALSE=0


    Unbounded page size constant

    PAGE_SIZE_UNBOUNDED = -1


    Constants for proxyPolicy

    proxyPolicy

    INTRANET_ACCESS All server access.

    EXTERNAL_ONLY Only servers outside of the SSO domain.

    CUSTOM No access. Access will be defined by the proxy-policy.dynamic file.

    For more information about the proxy-policy.dynamic file, refer to Configure per-host proxy access rules for OpenSocial gadgets.


    NewsWidgetCatalogService

    NewsWidgetCatalogService.browseWidgets(enablement = Enablement.ALL, pageSize = PAGE_SIZE_UNBOUNDED, pageNumber = 1)

    Browse the widgets in the widget catalog.

    Uses the parameter for enablement (Refer to Enablement).

    Uses the parameter for pageSize.

    Uses the parameter for pageNumber.

    Returns a list of Widget objects.

    wsadmin>NewsWidgetCatalogService.browseWidgets(Enablement.ALL, 1, 1)

    NewsWidgetCatalogService.clearWidgetCaches()

    Clears cached widget.xml files from your server without needing to restart your system. If a gadget or iWidget.xml has been updated and you want to force it to be reread by the system, simply call this command.

    NewsWidgetCatalogService.countWidgets(enablement = Enablement.ALL)

    Count the widgets in the widget catalog.

    * Uses the parameter for enablement (Refer to Enablement).

    * Returns a count of the number of widgets in the catalog.

    NewsWidgetCatalogService.findWidgetById(WidgetId)

    Find a widget by id.

    Uses the parameter for widgetId.

    Returns the matching widget or null if no matching widget is found.

    For example:

    wsadmin>NewsWidgetCatalogService.findWidgetById("405a4f26-fa08-4cef-a995-7d90fbe2634f")

    NewsWidgetCatalogService.findWidgetByUrl(widgetUrl)

    Find a widget by Url.

    Uses the parameter for url.

    Returns the matching widget or null if no matching widget is found.

    NewsWidgetCatalogService.listShareGadgets(enablement = Enablement.ALL)

    List out the share gadgets. By design, paging is not supported.

    Uses the parameter for enablement (Refer to Enablement).

    Returns the share gadgets.

    For example:

    wsadmin>NewsWidgetCatalogService.listShareGadgets(Enablement.ALL)

    NewsWidgetCatalogService.updateWidgetShareOrder(widgetId, orderAfterWidgetId)

    Place the widget marked in a widgetId after a second widget in widget ordering.

    widgetId The id of the widget you wish to move.

    orderAfterWidgetId The id of the widget you want to place the gadget after. If this is null, the widget will be placed first in the ordering.

    NewsWidgetCatalogService.addWidget(**widget)

    Add a widget to the widget catalog.

    ** widget indicates that this is a free form set of key=value properties. The keys/values map to the Sets available for widgets table previously described.

    Returns the ID of the newly created widget.

    The following example creates a sample EE gadget that has 'trusted' access policies. This gadget depends on the Profiles component.

    NewsWidgetCatalogService.addWidget(, text="Sample gadget description.", url="http://www.to.my.gadget.com/gadget.xml",
    categoryName=[WidgetCategories.NONE], isGadget=TRUE,appContexts=[WidgetContexts.EMBEDXP], "policyFlags=[GadgetPolicyFlags.TRUSTED]}, prereqs=["profiles"])

    NewsWidgetCatalogService.updateWidget(widgetId, **widget)

    Update an existing widget in the widget catalog.

    Uses the parameter for widgetId.

    ** widget indicates that this is a free form set of key=value properties. The keys/values map to the Sets available for widgets table previously described.

    wsadmin>NewsWidgetCatalogService.updateWidget("1bf9ad75-a634-4301-88c6-ce493eb03cc9", , text="test")

    NewsWidgetCatalogService.removeWidget(widgetId)

    Remove a widget matching the widgetId entered.

    For example:

    wsadmin>NewsWidgetCatalogService.removeWidget("405a4f26-fa08-4cef-a995-7d90fbe2634f") 

    NewsWidgetCatalogService.enableWidget(widgetId)

    Returns the following output:

    CLFRQXXXXI: Widget {0} is now enabled.

    NewsWidgetCatalogService.disableWidget(widgetId)

    Returns the following output:

    CLFRQXXXXI: Widget {0} is now disabled.

    NewsWidgetCatalogService.ProxyPolicy

    Set the server proxy policy.

    INTRANET_ACCESS May access intranet sites.

    EXTERNAL_ONLY May access external (non-intranet) sites only.

    CUSTOM Uses rules in the rule manager configuration.


    Configure OAuth for custom gadgets

    The IBM Connections 4.0 release supports an OAuth 2.0 consumer proxy that allows the Homepage component to surface gadgets in an OpenSocial container that can interact with an OAuth 2.0 protected service. In order for this proxy to function, there are a series of new administration commands that are exposed in the News service to define OAuth 2.0 providers, clients, and the associated gadget that will interact with the protected service.

    See the topic Running administrative commands for steps on executing newsAdmin.py before running OAuth proxy configuration commands in IBM Connections.

    Perform any of the following tasks using the appropriate command:


    Counting providers

    NewsOAuth2ConsumerService.countProvider()

    Returns the total number of OAuth 2.0 providers registered with the consumer proxy. There are no parameters.

    Example:

    wsadmin>NewsOAuth2ConsumerService.countProvider()
    
    20


    Returning a list of providers

    NewsOAuth2ConsumerService.browseProvider(int pageSize, int pageNumber)

    Returns a list of Map objects that represent each OAuth 2.0 provider registered with the consumer proxy, in ascending ordered by provider name. The following information is returned for each map object in the returned list:

    • authHeader: "true" or "false"

    • authUrl: the authentication url endpoint for the provider

    • clientAuth: the client authentication method in use

    • name: the name of the provider

    • tokenUrl: the token url endpoint for the provider

    • urlParam: "true" or "false"

    pageSize

    The maximum number of providers to list per page. The default value is 20. This parameter is optional.

    pageNumber

    The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.

    Example:

    wsadmin>NewsOAuth2ConsumerService.browseProvider(50, 1)


    Returning a single provider

    NewsOAuth2ConsumerService.findProvider(string providerName)

    Returns a Map with information about the registered OAuth 2.0 provider with the specified name.

    providerName

    The unique provider name.

    Example:

    wsadmin>NewsOAuth2ConsumerService.findProvider("provider123")


    Register or updating a provider

    NewsOAuth2ConsumerService.registerProvider(string providerName, string clientAuth, string authHeader, string urlParam, string authUrl, string tokenUrl)

    Registers or updates an existing OAuth 2.0 provider by name with the associated parameters.

    providerName

    The unique provider name.

    clientAuth

    The client authentication method for accessing this provider. Supported values out of the box are "standard" and "basic" per the specification.

    authHeader

    Value of "true" if credentials must be encoded in the authorization header, otherwise "false".

    urlParam

    Value of "true" if credentials must be specified as query parameters on the URI, otherwise "false".

    authUrl

    The authentication endpoint for the provider.

    tokenUrl

    The token endpoint for the provider.

    Example:

    wsadmin>NewsOAuth2ConsumerService.registerProvider("provider123", "standard", "true", "false", "???", "???")


    Delete a provider

    NewsOAuth2ConsumerService.deleteProvider(string providerName)

    Deletes a provider by name if it exists, and has no existing associated clients or gadget bindings.

    providerName

    The unique provider name.

    Example:

    wsadmin>NewsOAuth2ConsumerService.deleteProvider("provider123")


    Counting clients

    NewsOAuth2ConsumerService.countClient(string providerName)

    Returns the total number of OAuth 2.0 clients registered with the consumer proxy.

    providerName

    An optional filter to only count clients associated with the specified provider.

    Example:

    wsadmin>NewsOAuth2ConsumerService.countClient("provider123")


    Returning a single client

    NewsOAuth2ConsumerService.findClient(string clientName)

    Returns a Map with information about the registered OAuth 2.0 client with the specified name.

    providerName

    The client name.

    Example:

    wsadmin>NewsOAuth2ConsumerService.findClient("client123")


    Returning a list of clients

    NewsOAuth2ConsumerService.browseClient(string providerName, int pageSize, int pageNumber)

    Returns a list of Map objects that represent each OAuth 2.0 clients registered with the consumer proxy, in ascending ordered by provider name. The following information is returned for each map object in the returned list:

    • clientId: the identifier issued by the authorization server when registering your client

    • clientSecret: the secret issued by the authorization server when registering your client

    • ctype: the client type, "confidential" or "public" are the supported values per the specification

    • grantType: "code" per specification, or "client_credentials" per specification

    • name: the name of the client

    • providerName: the name of the associated provider that was previously registered

    • redirectUri: the client redirection uri

    providerName

    An optional filter to only browse clients associated with the specified provider.

    pageSize

    The maximum number of clients to list per page. The default value is 20. This parameter is optional.

    pageNumber

    The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.

    Example:

    wsadmin>NewsOAuth2ConsumerService.browseClient("provider123", 50, 1)


    Register or updating a client

    NewsOAuth2ConsumerService.registerClient(string clientName, string providerName, string ctype, string grantType, string clientId, string clientSecret, string redirectUri)

    Registers or updates an existing OAuth 2.0 client by name with the associated parameters.

    clientName

    The name to associate with the client that must be unique in a deployment.

    providerName

    The name of the registered provider to associate with this client.

    ctype

    The client type. Supported values are "confidential" or "public" per LINKspecification/LINK.

    grantType

    The authorization grant type. Supported values are "code" or "client_credentials" per specification??

    clientID

    The identifier issued by the authorization server when registering your client.

    clientSecret

    The secret issued by the authorization server when registering your client.

    redirectUri

    The client redirection URI.

    Example:

    wsadmin>NewsOAuth2ConsumerService.registerClient("client123", "provider123", "confidential", "code", "my-client", "my-secret", "https://{opensocial}/gadgets/oauth2callback")


    Delete a client

    NewsOAuth2ConsumerService.deleteClient(string clientName)

    Deletes a client by name if it exists, and has no existing associated gadget bindings that leverage this client.

    clientName

    The name of the client to remove.

    Example:

    wsadmin>NewsOAuth2ConsumerService.deleteClient("client123")


    Binding a gadget

    NewsOAuth2ConsumerService.bindGadget(string widgetId, string serviceName, string clientName, string allowModuleOverride)

    Binds a gadget to a client with the specified service name and client name.

    widgetId

    The id of the widget.

    serviceName

    The name to associate with the gadget. The widgetId and service name must create a unique composite key for the deployment.

    clientName

    The name of the client to associate with this gadget.

    allowModuleOverride

    Value is "true" if the gadget overrides the provider default endpoint urls, else "false".

    Example:

    wsadmin>NewsOAuth2ConsumerService.bindGadget("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service", "client123", "false")


    Delete a binding

    NewsOAuth2ConsumerService.unbindGadget(string widgetId, string serviceName)

    Deletes a gadget binding by widgetId and serviceName.

    widgetId

    The id of the widget.

    serviceName

    The name to associate with the gadget. The widgetId and service name must create a unique composite key for the deployment.

    Example:

    wsadmin>NewsOAuth2ConsumerService.unbindGadget("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service")


    Returning bindings

    NewsOAuth2ConsumerService.browseGadgetBinding(string widgetId, string clientName, int pageSize, int pageNumber)

    Returns a list of Map objects that represent each OAuth 2.0 gadget bindings registered with the consumer proxy ordered by service name ascending. The following information is returned for each map entry in the returned list:

    • clientName: the name of the associated client

    • allowModuleOverride: "true" or "false"

    • serviceName: the name of the associated service

    • uri: the gadget uri

    widgetId

    An optional filter to browse bindings only associated with a specific widget.

    clientName

    An optional filter to browse gadgets only associated with the specified client.

    pageSize

    The maximum number of bindings to list per page. The default value is 20. This parameter is optional.

    pageNumber

    The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.

    Example:

    wsadmin>NewsOAuth2ConsumerService.browseGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "client123", 50, 2)


    Counting bindings

    NewsOAuth2ConsumerService.countGadgetBinding(string widgetId, string clientName)

    Returns the total number of OAuth 2.0 bindings registered with the consumer proxy.

    string widgetId, string clientName

    widgetId is an optional filter to count only bindings associated with a specific widget.

    Example:

    wsadmin>NewsOAuth2ConsumerService.countGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_servicex")


    Returning a single binding by gadgetUri

    NewsOAuth2ConsumerService.findGadgetBindingByUri(string gadgetUri, string serviceName)

    Returns a Map with information about the registered OAuth 2.0 gadget bindings with the specified gadgetUri and service name.

    gadgetUri

    The uri for the gadget.

    serviceName

    The name associated with the gadget. A gadgetUri and service name create a unique composite key for a gadget in the deployment.

    Example:

    wsadmin>NewsOAuth2ConsumerService.findGadgetBinding("http://www.acme.com/mygadget", "connections_service")


    Returning a single binding by widgetId

    NewsOAuth2ConsumerService.findGadgetBindingByWidgetId(string widgetId, string serviceName)

    Returns a Map with information about the registered OAuth 2.0 gadget bindings with the specified widget id and service name.

    widgetId

    The id of the widget.

    serviceName

    The name associated with the gadget. A widgetId and service name create a unique composite key for a gadget in the deployment.

    Example:

    wsadmin>NewsOAuth2ConsumerService.findGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service")


    Purging all tokens

    NewsOAuth2ConsumerService.purgeAllTokens()

    Purges all tokens persisted in the repository. This operation should be executed if the underlying encryption method has been modified.

    Example:

    wsadmin>NewsOAuth2ConsumerService.purgeAllTokens()


    Configure per-host proxy access rules for OpenSocial gadgets

    Proxy access is configured on a per-gadget level. This configuration is distinct from the proxy configuration file in that it specifies which end points may be contacted rather than what tokens or headers may be sent. In general the proxy access is configured during gadget registration by setting the Server access setting to external (outside the SSO domain) or all server access. Beyond these two settings, an administrator may expand or restrict access further by specifying custom proxy or (in cases where they wish for extra security) may enumerate per-gadget-per-server (and even per user) custom proxy rules. Custom proxy rules are defined in a separate configuration file.

    The rule manager operates as a stack. If one rule allows the request and a second deny's the request, then the last rule to execute wins. In Connections the execution ordering is as follows:

    1. denyAll(): block all requests

    2. MasterRule(): consult the widget DB and allow or deny the request based on the gadget administrative data. Registering a gadget with "custom" causes a deny() to be pushed onto the stack

    3. Any custom rules defined in proxy-policy.dynamic: Finally the proxy-policy.dynamic file is executed. This file contains additional allow/deny rules.
    Thus, custom rules you define in the policy file might override any other access decision. In the case of gadgets with "custom" server access, the gadget has no implicit server access.

    The "proxy-policy.dynamic" file is located in the under LotusConnections-config/opensocial-proxy-rules. Add rules as needed as described in this topic. Unlike other configuration files, an application or server restart is NOT needed to reload the file. File changes will be detected and acted upon with-in 10-15 seconds. A rule consists of an Action, User, Target URL, and Component.

    • The Action represents the action to be taken by the proxy when processing this rule such as "Allow" and "Deny".

    • The User represents a current user, and can be an anonymous user or system user, for example, the viewer or owner of a gadget.

    • Target URL represents the target URL to access through the proxy.

    • The Component represents the gadget that sends out the request.
    The rules are specified as JavaScript program source code. Each rule is specified as a JavaScript function invocation. Four functions are provided out-of-box:

    • allow - Used to specify an ALLOW rule. This function takes three parameters:

      • Current® user's UID

      • Widget's URL - URL of the widget/gadget component that sends the request

      • Target URL - the URL that the widget/gadget wants to access.
      For example, allow('user1', 'http://www\.example.com/widget1\.xml', 'http://www\.google\.com') specifies that if the current user is 'user1', then the widget 'http://www.example.com/widget1.xml' is allowed to access URL 'http://www.google.com'.

    • deny - Used to specify a DENY rule. This function shares the same parameters as allow function.

    • allowAll - A shortcut function to allow all requests.

    • denyAll - A shortcut function to deny all requests.
    When using allow and deny functions, the username, widget URL and target URL are actually regular expressions so wild cards can be used. For example, if all user names that start with 'user' is allowed, then 'user.*' can be entered as the first parameter. A guide of JavaScript regular expression pattern can be found at here. Since the rules are specified as JavaScript program source code, JavaScript code logic also can be used. You can use an if/else clause in a rule. For example, The following predefined variables also are provided:

    • user: login-id of current user

    • component : URL of the widget that sends the request

    • targetUrl : the URL to access
    These predefined variables can be used in the JavaScript code. For example:

    allow('user1', '.*', '.*ibm\.com'); // user1 is allowed to access all URLs that end with ibm.com
    In another example of a gadget that draws from Connections data, you want to set a rule that only certain gadgets can communicate with the internet. To accomplish this you could set a global rule to prevent gadgets from connecting to secure.ibm.com and then make gadget- or user-specific rules to permit particular gadgets to do so. Or you can expose certain mail servers, but you might want extra protection so that only certain gadgets can make a request to those servers.
    Here is an example of rule configuration that uses a mix of allow and deny functions:

    /*
    
    * Pre-defined variables that can be used in the script.
    
    * _user -> Current user's UID
    
    * _component -> Gadget URL
    
    * _targetUrl -> Target URL to access
    
    */
    
    
    allowAll(); // this means allow('*', '*', '*')
    
    allow('alex', 'http://myserver/gadget1.xml', 'www.ibm.com');
    
    deny('alex', 'http://myserver/gadget1.xml', 'www.ibm.com/private');
    
    
    deny('bob', 'http://myserver/gadget2.xml', '*');
    
    deny('*', 'http://myserver/gadget3.xml', '*');
    
    
    //denyAll(); // this means deny('*', '*', '*');
    
    
    if (/\S+@\S+\.ibm\.com/i.test(_user)) {  // Use regular expression
    
        allow(_user, '*', '*.ibm.com');  //IBM users are allowed to access IBM sites
    
    }

    Manage access

    Manage roles, credentials, users, and directories, and allow third-party access to IBM Connections data.

    Manage access by setting roles, creating superusers, allowing third-party applications to access data, making sure the administrator credentials are accurate, keeping users synchronized with the directory, managing inappropriate content, and enabling moderation.


    Roles

    Describes the roles defined for IBM Connections users on WebSphere Application Server.

    The four roles that are consistent across the applications (person, everyone, reader, and admin) should be consistently set across all of the IBM Connections services.

    Table 35. Activities roles

    J2EE Role Description
    admin Used by an administrator to manage Activities content. See Administering application content.
    everyone Can access public pages without signing in to the application. There are not many pages that allow everyone to access them. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    person Can read and write to Activities.
    reader Used exclusively by the Ajax proxy.
    search-admin Used by Search to read public and private data in order to create search indexes.
    widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Activities widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias. The user mapped to the widget-admin role must also be mapped to the person role.

    Table 36. Blogs roles

    J2EE Role Description
    admin Used by an administrator to manage Blogs configuration and content. See Administering application content.
    everyone Can access public pages without signing in to the application. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    global-moderator Users in this role can moderate content. That is, they can read, edit, delete, reject, approve, quarantine, and dismiss entries and comments, and flag inappropriate content.
    person Can read and write to Blogs.
    reader Users in this role have read access to Blogs. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Blogs.
    search-admin Used by Search to read public and private data in order to create search indexes.
    widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Blogs widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.

    Table 37. Bookmarks roles

    J2EE Role Description
    everyone Can access public pages without signing in to the application. Some examples are the Public Bookmarks and Popular Bookmarks views, as well as the login page. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    person Can read and write to Bookmarks.
    reader Users in this role have read access to Bookmarks. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Bookmarks.
    search-admin Used by Search to read public and private data in order to create search indexes.

    Table 38. Communities roles

    J2EE Role Description
    admin Used by an administrator to manage Communities content. See Administering application content.
    community-creator Users in this role can create communities. By default, this role is mapped to the WebSphere Application Server group "Everyone", but this can be changed to a more restricted user set if needed.
    dsx-admin Used by the Communities directory service extension to read both public and private data. Do not add real users to this role.
    everyone Not used.
    global-moderator

    Users in this role can see the moderation link on the navigation bar in communities. To access the moderation user interface they must also be in the Moderation global-moderator role. To actually moderate content, they must also be in the Blogs, Forums, and Files global-moderator roles. For example, for a user to moderate Blogs in a community they must be in the global-moderator roles in Communities, Moderation, and Blogs.

    person Users in this role can create communities, join a public community, or request to join a moderated community. Communities Atom API creates and updates can only be performed by a user in this role.
    reader Users in this role have read access to Communities. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Communities. This role is also used to restrict access to the Ajax proxy; it is recommended that you set reader to the WebSphere Application Server group "All Authenticated in Application's Realm" in a production environment.
    search-admin Used by Search to read public and private data in order to create search indexes.

    Table 39. Files roles

    J2EE Role Description
    admin Used by an administrator to manage Files content. See Administering application content.
    everyone This role is mapped to the WebSphere Application Server group "Everyone" by default and should not be modified. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
    files-owner Users with this role have all of the privileges of someone in the person role, but also will have a personal file stream created when they log in to files. If a user is removed from this role after they have already logged into files, they will continue to have a personal file library, but it will be hidden from the main personal files user interface for them. When changing this role, or changing members of groups in this role, consider using the Files administrative commands to browse and delete applicable personal libraries. This role does not affect who can upload files to community file libraries. It is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. You can apply this role to a subset of people in the person group to limit who can upload files.
    global-moderator Users in this role can moderate content. That is, they can read, edit, and delete community files and comments that have already been approved, and can reject or approve community files and comments that are awaiting approval. They can also quarantine content, restore or delete quarantined content, and dismiss flags on content.
    person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. When this role is mapped to "All Authenticated in Application's Realm," the reader role should be mapped to "Everyone."
    reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default. When this role is mapped to "Everyone," the person role should be mapped to "All Authenticated in Application's Realm." If this role is mapped to something other than "Everyone,' the person and reader roles must have the same mappings.
    search-admin Used by Search to read public and private data in order to create search indexes.
    widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Files widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.

    Table 40. Forums roles

    J2EE Role Description
    admin Used by an administrator to manage Forums content. See Administering application content.
    everyone Can access public pages without signing in to the application. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    global-moderator Users in this role can moderate content in a forum. That is, they can read, edit, delete, reject, approve, quarantine, and dismiss entries and comments, or content that has been flagged as inappropriate.
    person Can read and write to Forums.
    reader Users in this role have read access to Forums. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Forums.
    search-admin Used by Search to read public and private data in order to create search indexes.
    widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Forums widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.

    Table 41. Home page roles

    J2EE Role Description
    admin This role is not mapped to any users by default. This role is used to protect the Home page administrative user interface, which allows administrators to register new widgets, and to enable and disable widgets. Users in this role can see a Server metrics link in the Home page footer. Specific administrator user IDs should be mapped to this role, but you should not map this role to the WebSphere Application Server "Everyone" or "All Authenticated in Application's Realm" groups.
    everyone Applies to the Home page login page and the service configuration APIs only. This role allows users to access these resources without any authentication. By default, the role is mapped to the WebSphere Application Server group "Everyone" and should not be modified. It is used internally by the IBM Connections application, and changing the role will break the basic login function of the application.
    person Used to secure the Home page web user interface. Users must authenticate to access the Home page. Note that the Home page is not designed to work in an unauthenticated fashion, and therefore this role should not be mapped to the WebSphere Application Server group "Everyone." By default, this role is mapped to the "All Authenticated in Application's Realm" group, which means that all authenticated users can access the Home page. If you need to restrict access to a smaller set of people, modify the mapping of this role as needed.
    reader Used to access the Search APIs. This role is mapped to the WebSphere Application Server group "Everyone" by default. Modifying this role has no effect on the Home page.

    Table 42. Metrics roles

    J2EE Role Description
    metrics-report-run Grants users the authority to view and interact with global metrics. Other than administrators, only the users assigned to the metrics-report-run role can access global metrics. Whenever a user with this authorization level views the global metrics, the report information is updated automatically. For best results, limit access to a small set of users whose jobs require them to view the most recent metrics. Granting this level of access to a large number of users may slow performance, as update requests are processed in sequence
    community-metrics-run Grants users the authority to view community metrics using static reports. Other than administrators and community owners, only the users assigned to the community-metrics-run role can access community metrics. Users with this level of access see static reports, which can be refreshed by clicking the Update button in the Metrics user interface. You can map this role to everyone, or to subset of the user population. For example, you can gradually provide the community metrics feature to the user population by mapping this role to small group first, and then adding more users to the role over time.
    metrics-reader Grants users the authority to view metrics from the previous release of IBM Connections (for information, see the Connections 3.0.1 topic Collect metrics). If you upgraded to version 4, this role remains in place with its existing assignments.
     

    Table 43. Mobile roles

    J2EE Role Description
    everyone Applies to the Mobile page login page API. This role allows users to access these resources without any authentication. By default, the role is mapped to the WebSphere Application Server group "Everyone" and should not be modified. It is used internally by the IBM Connections application, and changing the role will break the basic login function of the application.
    person Used to secure all Mobile pages other than the login page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the Mobile pages. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the Mobile pages page are not meant to be available to unauthenticated users.

    Table 44. Moderation roles

    J2EE Role Description
    reader Applies to public Atom APIs. This role allows users to access these resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, mapping this role to "All Authenticated in Application's Realm" requires users to log in when accessing public Atom APIs.
    everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
    person Used to secure the Atom APIs for "top stories" or "saved stories" as well as to secure the Email preferences page in the product. Users must authenticate to access the New APIs and preferences page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the "top stories" and "saved stories" APIs and the email preferences page. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the email preferences page is not meant to be available to unauthenticated users.
    global-moderator Users in this role can see the moderation interface. To actually moderate Blogs, Forums, and community Files content, they must also be in the global-moderator role of the application. For example, to moderate Blogs they must be in the global-moderator role in Moderation and in Blogs. To moderate Blogs, Forums, and Files in communities, they must also be in the Communities global-moderator role. For example, to moderate Files in a community, they must be in the global-moderator role in Communities, Moderation, and Files. After a user is in the appropriate roles, they can read, edit, delete, reject, approve, quarantine, and restore entries and comments, dismiss flags, and flag inappropriate content.

    Table 45. News roles

    J2EE Role Description
    admin Defined in the news repository, but not used. Changing its mapping has no effect on the news repository. This role is not mapped to any users by default.
    everyone This role should not be modified. It is used to define pages which should always be available, such as the login page. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    person Used to secure the Atom APIs for Status Updates, News Feed stories, or Saved stories, as well as to secure the E-mail Preferences page in the product. Users must authenticate to access the News APIs and preferences page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the Status Updates, News Feed stories, and Saved stories APIs, and the E-mail Preferences page. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the email preferences page is not meant to be available to unauthenticated users.
    reader Applies to public Atom APIs. This role allows users to access these resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, mapping this role to "All Authenticated in Application's Realm" requires users to log in when accessing public Atom APIs.

    Table 46. Profiles roles

    J2EE Role Description
    admin Used by an administrator to manage Profiles content. See Administering application content.
    allAuthenticated Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application. Specifically, this role is used to secure the login-redirect page and is needed to correctly redirect the user back to the page they were attempting to access before the login procedure began. Never change the default value of this role.
    dsx-admin Used by the Profiles directory service extension to read both public and private data. This role secures the directory service communication when email addresses are hidden.
    everyone Users with this role can access public pages without signing in to the application. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default.
    reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default.
    search-admin Used by Search to read public and private data in order to create search indexes.

    Table 47. Search roles

    J2EE Role Description
    admin Administrative role. No default mappings are defined for this role. The installation wizard maps the person defined as the system administrator to this role.
    everyone Not used. There are no default mappings defined for this role. By default, this role is mapped to the WebSphere Application Server group "Everyone." Changing the mapping has no effect.
    person Restricts access to the user interface for the Search application and personal Atom API searches (/atom/mysearch). By default, this role is mapped to the WebSphere Application Server group "Everyone," but this can be changed to a more restricted user set if needed.
    reader Used to protect the Atom APIs with the exception of /atom/mysearch. This role allows users to access the resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, if you map this role to the WebSphere Application Server group "AllAuthenticated in Application's Realm," then users must log in before they can access the public Atom APIs.

    Table 48. Wikis roles

    J2EE Role Description
    admin Used by an administrator to manage Wikis content. See Administering application content.
    everyone Users with this role can access public pages without signing in to the application. The login page is an example. This role should not be modified. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
    everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
    person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. The reader role should be mapped to "Everyone" when this role is mapped to "All Authenticated in Application's Realm."
    reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default. The person role should be mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" when this role is mapped to "Everyone." If this role is mapped to something other than "Everyone,' the person and reader roles must have the same mappings.
    search-admin Used by Search to read public and private data in order to create search indexes.
    widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Wikis widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.
    wiki-creator Users with this role can create wikis outside of communities. Only they can see the Start a Wiki button in Wikis. This role does not affect who can create a wiki inside a community or who can create wiki pages in any wiki. It is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. This does not control whether users can create wikis in communities.


    Assign people to roles

    To assign a person or group to a role, complete the following steps:

    1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application to configure.

    2. Click Security role to user/group mapping. Find the role that want to add users to.

    3. Select the check box next to the role to assign, and then click Map users or Map groups.

    4. In the Search String box, type the name of the person or group that you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.

    5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.

    6. Repeat Steps 4 and 5 to add more users to the role.

    7. Click OK.

    8. To map a user or group to a different role for another application, repeat steps 1.7.

    9. After making your changes, click OK, and then click Save to save them.

    10. Synchronize all of your WebSphere Application Server instances.


    Related

  • Configure media galleries

  • Switch to unique administrator IDs for system level communication
  • Configure J2C Aliases for the moderation proxy service
  • Specify different system users for widget life-cycle events
  • Modify the installation in interactive mode
  • Enable forum topic posting in different deployments


    Assign people to J2EE roles

    Assign roles for IBM Connections users on WebSphere Application Server.

    See Roles for definitions of the different available roles.

    To assign a person or group to a role, complete the following steps:

    1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application to configure.

    2. Click Security role to user/group mapping. Find the role that want to add users to.

    3. Select the check box next to the role to assign, and then click Map users or Map groups.

    4. In the Search String box, type the name of the person or group that you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.

    5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.

    6. Repeat Steps 4 and 5 to add more users to the role.

    7. Click OK.

    8. To map a user or group to a different role for another application, repeat steps 1.7.

    9. After making your changes, click OK, and then click Save to save them.

    10. Synchronize and restart all your WebSphere Application Server instances.


    Related tasks

  • Administer activity stream search


    Manage stored credentials

    IBM Connections does not create nor store user names and passwords. Instead, it uses the user credentials that already exist in your LDAP directory for authentication. IBM Connections does not store administrative user IDs and passwords either. It does, however, create and store references to existing administrative user credentials. You can make changes to those references.


    User credentials

    To change a user's password, change the password in the LDAP directory that you are using to store user data. IBM Connections does not provide a method that administrators can use to change user credentials. Use the methods in place in your organization for changing user credentials. Alternatively, you can refer to the documentation provided with the LDAP directory that you are using.


    Administrative credentials

    When you install IBM Connections, it creates a set of references to the administrative user credentials it needs to access other tools and services to configure IBM Connections. Refer to the following topics for information on how to update these references.


    Change the WebSphere Application Server administrative user ID password

    Update the password for the administrative user ID used to configure IBM Connections on WebSphere Application Server.

    This is an optional procedure.

    1. Refer to the WebSphere Application Server information center: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.base.doc/info/aes/ae/uwim_adminuserpwdsettings.html

    2. WebSphere Application Server Deployment Manager user ID only: Synchronize the nodes of the cluster to propagate the change.

    3. If the administrative user ID is used in any of the J2C authentication aliases, you must update the password associated with the alias. In the WebSphere Application Server administration console, select Security > Global security.

    4. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.

    5. Click the alias name to edit it, and then change the value in the Password field.

    6. Apply and save the changes.

    7. Restart the servers hosting IBM Connections.


    Change references to database administrative credentials

    Update the aliases that reference the administrative user IDs and passwords used to manage IBM Connections DBs.

    This is an optional procedure.

    1. Change the administrative user credentials using the tools provided with the database product that you are using.

      • DB2 Configuration Assistant

      • Oracle Enterprise Manager Console

      • SQL Server Management Studio

    2. To update the reference to the administrative user credentials that you just changed, change the credential information for the corresponding J2C authentication alias. In the WebSphere Application Server administration console, select Security > Global security.

    3. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.

    4. Click the alias name to edit it. Refer to the following tables for alias information.

      Table 49. DB2 database user IDs and aliases

      Database user ID Description Alias
      LCUSER User ID of the user with a limited set of administrative privileges to access all of the application tables in the DB2 database.

      activitiesJAASAuth

      blogsJAASAuth

      communitiesJAASAuth

      dogearJAASAuth

      filesJAASAuth

      forumJAASAuth

      homepageJAASAuth

      metricsJAASAuth

      newsJAASAuth

      profilesJAASAuth

      searchJAASAuth

      wikisJAASAuth

      Table 50. Oracle database user IDs and aliases

      Database user ID Description Alias
      BLOGSUSER User ID of the user with a limited set of administrative privileges to access the Blogs table in the Oracle database. blogsJAASAuth
      DFUSER User ID of the user with a limited set of administrative privileges to access the Forums table in the Oracle database. forumJAASAuth
      DOGEARUSER User ID of the user with a limited set of administrative privileges to access the Bookmarks table in the SQL Server and Oracle DBs. dogearJAASAuth
      FILESUSER User ID of the user with a limited set of administrative privileges to access the Files table in the SQL Server and Oracle DBs. filesJAASAuth
      HOMEPAGEUSER User ID of the user with a limited set of administrative privileges to access the Home page table in the Oracle database. The same user ID administers the Home page, Search, and Updates services.

      homepageJAASAuth

      newsJAASAuth

      searchJAASAuth

      METRICSUSER User ID of the user with a limited set of administrative privileges to access the Metrics table in the SQL Server and Oracle DBs. metricsJAASAuth
      OAUSER User ID of the user with a limited set of administrative privileges to access the Activities table in the SQL Server and Oracle DBs. activitiesJAASAuth
      PROFUSER User ID of the user with a limited set of administrative privileges to access the Profiles table in the SQL Server and Oracle DBs. profilesJAASAuth
      SNCOMMUSER User ID of the user with a limited set of administrative privileges to access the Communities table in the SQL Server and Oracle DBs. communitiesJAASAuth
      WIKISUSER User ID of the user with a limited set of administrative privileges to access the Wikis table in the SQL Server and Oracle DBs. wikisJAASAuth

      Table 51. SQL Server database user IDs and aliases

      Database user ID Description Alias
      BLOGSUSER User ID of the user with a limited set of administrative privileges to access the Blogs table in the SQL Server database. blogsJAASAuth
      DFUSER User ID of the user with a limited set of administrative privileges to access the Forums table in the SQL Server database. forumJAASAuth
      DOGEARUSER User ID of the user with a limited set of administrative privileges to access the Bookmarks table in the SQL Server and Oracle DBs. dogearJAASAuth
      FILESUSER User ID of the user with a limited set of administrative privileges to access the Files table in the SQL Server and Oracle DBs. filesJAASAuth
      HOMEPAGEUSER User ID of the user with a limited set of administrative privileges to access the Home page table in the SQL Server database. The same user ID administers the Home page, Search, and Updates services.

      homepageJAASAuth

      newsJAASAuth

      searchJAASAuth

      METRICSUSER User ID of the user with a limited set of administrative privileges to access the Metrics table in the SQL Server and Oracle DBs. metricsJAASAuth
      OAUSER User ID of the user with a limited set of administrative privileges to access the Activities table in the SQL Server and Oracle DBs. activitiesJAASAuth
      PROFUSER User ID of the user with a limited set of administrative privileges to access the Profiles table in the SQL Server and Oracle DBs. profilesJAASAuth
      SNCOMMUSER User ID of the user with a limited set of administrative privileges to access the Communities table in the SQL Server and Oracle DBs. communitiesJAASAuth
      WIKISUSER User ID of the user with a limited set of administrative privileges to access the Wikis table in the SQL Server and Oracle DBs. wikisJAASAuth

    5. Change the value in the Password field to reflect the change you made in Step 1.

    6. Apply and save the changes.

    7. Restart the servers hosting IBM Connections.


    Change references to administrative credentials

    Update the aliases that reference the administrative user IDs and passwords used to handle server-to-server communication.

    This is an optional procedure.

    1. To update the aliases that manage server-to-server communication, you must edit the associated J2C authentication data for the alias. In the WebSphere Application Server administration console, select Security > Global security.

    2. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.

    3. Click the connectionsAdmin alias to edit it. You defined the current user ID and password to use for the connectionsAdmin alias during the installation. The user id and password must be one of the following values:

      • A valid user in the organization's LDAP service. Organizational security requirements may require you to change this password periodically, in which case the stored credentials will need to be updated to reflect the new password.

      • A user defined in the WebSphere Identity Manager.

    4. Update the values that have changed.

    5. Apply and save the changes.

    6. Restart the servers hosting IBM Connections.

    7. If you changed the name of the administrative user, you must update the mapping for the following J2EE roles:

      Table 52. Application J2EE roles and aliases

      Application J2EE role Alias Description
      dsx-admin connectionsAdmin Accesses user information from the Profiles or Communities DBs using the corresponding directory service extensions.
      search-admin connectionsAdmin Indexes the applications to support advanced searches across the product.
      widget-admin connectionsAdmin Accesses other applications from the Communities application to support the widgets that are available within Communities.
      See Switching to unique administrator IDs for system level communication for more details.

    8. Perform some additional steps to update the messaging bus configuration, which also relies on the connectionsAdmin alias. See Updating the messaging bus configuration when the connectionsAdmin user ID changes for more details.


    Related

  • Configure media galleries

  • Configure J2C authentication for Search
  • Switch to unique administrator IDs for system level communication
  • Update the messaging bus configuration when the connectionsAdmin user ID changes


    Switch to unique administrator IDs for system level communication

    When you install IBM Connections, you provide a user name and password for a system user account that is created by the installer to handle application-to-application communication. The installer also creates a J2C authentication alias, named connectionsAdmin. The alias is filled with the specified user and maps that user to a set of application roles. If you want to map these roles to different system user accounts, create additional J2C authentication aliases and remap the roles.

    This is an optional configuration. Only complete one of these tasks if you want to map a different user ID to the system-level roles for one or more of the IBM Connections applications.

    The connectionsAdmin is mapped to roles that perform the following tasks:

    Table 53. Roles associated with connectionsAdmin

    Role Description
    dsx-admin Used by the Profiles and Communities applications to query their corresponding DBs to retrieve user or community data. When other applications need user or community data, they use the connectionsAdmin user to authenticate with Profiles and Communities, and then request the data from Profiles and Communities.
    search-admin Used by all applications to control which user IDs can query for seedlist information. The seedlist data is used to create the global index. The Search application uses the connectionsAdmin user ID to authenticate with the other applications, and then makes queries to them on a scheduled basis to keep the index up-to-date.
    widget-admin Used by applications that make widgets available within the Communities application, such as Activities, Blogs, Files, and Wikis. People assigned to this role can run administrative commands that make changes to those managed applications, such as to create, delete, or modify membership information. The Communities application uses the connectionsAdmin user ID to authenticate with the other applications, and then passes the requests on to them.
    In addition, the connectionsAdmin user is used by the Home page application to secure the messaging bus connection.

    The connectionsAdmin does not represent the administrative user of an application; it represents a system-level user for application to application communication. To map a different user ID to one of the default roles:

    1. Perform one of the following tasks:

      • To specify a different system-level user ID for the dsx-admin, search-admin, or widget-admin roles: Create a J2C authentication alias on WebSphere Application Server :

        1. From the IBM WebSphere Application Server Integrated Solutions Console, expand Security, and then select Global security.

        2. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.

        3. Click New, and then enter an alias name, user ID, and password.

          • dsx-admin: If you are creating an alias for this role and plan to enable or have enabled single sign-on with a third-party authentication manager, specify a user ID that is present in the corporate directory, and not only in the WebSphere Identity Manager.

          • search-admin: If you are creating an alias for this role, specify an alias name with the syntax: searchapplication_nameAlias where application_name is the name of the application for which you want to create the alias. For example, searchBlogsAlias.

          • widget-admin: If you are creating an alias for this role, specify an alias name with the syntax: widgetapplication_nameAlias where application_name is the name of the application for which you want to create the alias. For example, widgetActivitiesAlias.

        4. Click OK, and then click Save

        5. Repeat steps c to d for each new role to create.

        6. Save your changes.

      • To specify a different system-level user ID for the connectionsBus role: Map the user ID to a security setting in the service integration buses defined for IBM Connections :

        1. From the WebSphere Application Server Integrated Solutions Console, select Service integration > Buses.

        2. Click the bus to which you want to map a different user ID.

          All IBM Connections buses have names that begin with Connections.

        3. Click Security > Users and groups in the bus connector role.

        4. Delete the existing user ID by selecting the check box next to the user ID and clicking Delete.

        5. To add the new user ID, click New, select User name, and then type the name of the new user ID.

        6. Click OK.

        7. Repeat steps b to f for each bus.

        8. Save the changes.

    2. If you are specifying a different system-level user ID for the widget-admin role: Edit the widget-config.xml configuration file for the application or applications affected by this change. To do so:

      1. From the profile_root\config\cells\<cellName>\LotusConnections-config directory, open the widget-config.xml file in a text editor.

      2. Change the remoteHandlerAuthenticationAlias attribute in the lifecycle element for the widgetDef (widget definition) corresponding to the application that is to be changed. Replace the current value with the name of the alias that you created; include the full name of the alias, which is likely to include a node name prefix.

      3. Repeat the previous step for each application for which you defined a new alias.

      4. Save the widget-config.xml file.

    3. If you are specifying a different system-level user ID for the dsx-admin, search-admin, or widget-admin roles: Map the user in the alias to the role you want :

      For Activities, you must map the person that you are mapping to the widget-admin role to the person role as well.

      1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application to configure.

      2. Click Security role to user/group mapping. Find the role that you created in the Role column, and then click Map users or Map groups.

      3. In the Search String box, type the name of the person or group you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.

      4. Select the user or group name from the Available box, and then move it into the Selected column by clicking the arrow button.

      5. Repeat steps i and j to add additional people or groups.

      6. Repeat steps f through k to define access levels and assign people to any other aliases that you created.

      7. Click OK.

      8. Click OK, and then click Save to save the changes.

    4. If you are specifying a different system-level user ID for the dsx-admin role: Update the value of the corresponding attributes in the LotusConnection-config.xml file. To do so, start the wsadmin client , and then complete the following steps:

      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. Use the following commands to update the alias information:

        LCConfigService.updateConfig("profiles.directory.service.extension.enabled",
         "true")

      4. Open LotusConnections-config.xml in a text editor, and then add the following values to the <sloc:serviceReference serviceName="directory"> element in the file:

        <sloc:serviceReference serviceName="directory" 
        communities_directory_service_extension_auth_alias="<alias_you_created>" 
        communities_directory_service_extension_enabled="true" 
        profiles_directory_service_extension_auth_alias="<alias_you_created>" 
        />

        ...where alias_you_created is the alias you created in Step 1.

      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 common configuration property changes for information about how to save and apply your changes.

    5. Restart the application servers hosting the applications for which you created user roles.


    Related tasks

  • Configure J2C authentication for Search
  • Specify different system users for widget life-cycle events
  • Synchronize source changes such as LDAP with Profiles
  • Change references to administrative credentials
  • Update the messaging bus configuration when the connectionsAdmin user ID changes

  • Roles


    Update the messaging bus configuration when the connectionsAdmin user ID changes

    If the connectionsAdmin alias is changed to use a different user ID than was previously configured, complete this procedure to ensure that applications can still communicate event information to the news service.

    1. Stop all IBM Connections applications.

    2. In the WebSphere Application Server administration console, select Service Integration > Buses > ConnectionsBus.

    3. Under Additional Properties, click Security.

    4. Under Authorization Policy, click Users and groups in bus connector role.

    5. Select the check box next to the existing entry of type User that contains the old user ID, and then click Delete.

    6. Click New, and then follow the wizard instructions to add the new user ID defined for the connectionsAdmin alias.

    7. Click OK, and then save the changes.

    8. From Service Integration > Buses > ConnectionsBus, click Destinations.

    9. From the list of destinations, click connections.events.

    10. In the Message Points section, click Publication Points.

    11. For each entry in the list, click the name of the publication point, for example: connections.events@LCCluster1.000-ConnectionsBus

    12. Click the Runtime tab.

    13. Under Additional Properties, click Subscriptions.

    14. Select the check box against each subscription, so that they are all selected, and then click Delete.

    15. Repeat steps 11-14 for each publication point for the connections.events destination. There will be one publication point for each cluster in your deployment.

    16. Repeat steps 9-15 for the connections.platformCommands destination.

    17. Restart all clusters.


    Related tasks

  • Switch to unique administrator IDs for system level communication
  • Change references to administrative credentials
  • Configure authorization for foreign bus connections


    Change administrative credentials for the LDAP global unique ID

    When you change the credentials of the administrative user ID that serves as the global unique ID for IBM Connections, you must also update the federated repository configuration for IBM Connections.

    This is an optional procedure.

    1. In the WebSphere Application Server administration console, expand Security, and then select Global security.

    2. Under User account repository, make sure Federated repositories is selected from the list, and then click Configure.

    3. Click the repository identifier value of the LDAP directory you are using with IBM Connections.

    4. Update the Bind ID and Bind password fields to specify a temporary LDAP ID, and then apply your changes.

    5. Synchronize the change to all application server nodes, and then stop all application servers and restart them. Verify that you can still log in to the Integrated Solutions Console after the Deployment Manager restarts.

    6. Reset the actual production bind password in LDAP.

    7. Repeat Steps 2 through 5 to replace the temporary values specified for the Bind ID and password with the new ones.

    8. Restart the servers hosting IBM Connections.


    Change the password for the mail administrative user

    If mail is configured to be sent from a dedicated mail server that requires authentication and you must update the credentials associated with it, you can change the password associated with mail.

    This is an optional procedure.

    1. Log into the IBM websphere Application Server Integrated Solutions Console, and then click Resources > Mail > Mail Sessions.

    2. Select Cell scope, and then click the session with the mail/notification JNDI name.

    3. In the Outgoing Mail Properties section, change the value in the Password field, verify the changed password, and then apply and save your changes.

    4. Restart the servers hosting IBM Connections.


    Manage users

    As employees come and go from your organization, the corporate directory changes, and there are some steps that you, as the administrator, must take to make sure that those changes are reflected in the product by keeping the IBM Connections membership tables up-to-date with the changes that occur in your corporate directory.

    If the Profiles application is installed, when you inactivate a user or make changes to user data, such as change a person's last name or email address in the Profiles database, that change is automatically pushed out to the membership and login tables of the other IBM Connections applications.

    If Profiles is not installed in your deployment, you must apply the changes to the membership tables for each application separately. The only way to update user data in the membership tables for the other applications is through a set of administrative synchronization commands.


    Related tasks

  • Synchronize source changes such as LDAP with Profiles
  • Retrieve member information
  • Delete user files from the system
  • Excluding inactive users from search results


    User life cycle details

    With version 3, support was added to the product to better identify whether people in the directory are "active," meaning current employees or "inactive," meaning were once listed in the directory, but have since left the company.

    This feature enables users who are "inactive" to be kept in the product membership and login tables as opposed to having to be removed from the product DBs entirely. This change both conserves the data the inactive user created and makes it possible for inactive employees to return to the organization and regain access to their previously created data.

    This feature implements the following behavior:

    • In searches and membership selection fields, only active people are displayed by default.

    • Useful data that people no longer in the company contributed to IBM Connections applications does not have to be removed; it can remain for use by others, but the product user interface reflects the fact that the contributing user is currently inactive.

    • People who return to the company can be reactivated and can regain access to their old data.

    • Support is available to search for inactive people specifically.


    Manage users when the Profiles application is installed

    Manage users is easier if the Profiles application is installed and you accept the default configuration in which the Profiles directory service extension is used to retrieve data from the Profiles database instead of retrieving it from the LDAP directory. Starting with version 3, when you make changes to user status and data in the Profiles database, the changes are automatically propagated to the other application DBs.

    You can use one of the following methods to update user data in the Profiles database:

    • Profiles Administrative API

    • Profiles administrative commands

    • IBM Tivoli Directory Integrator scripts


    Related

  • Troubleshoot user data propagation


    Manage user data using the Profiles Administration APIs

    Use the Profiles Administration APIs to synchronize data between the Profiles database and the corporate directory. You can use the APIs as an alternative to running IBM Tivoli Directory Integrator scripts to initiate changes.

    See Profiles Administration API for more details.


    Related

  • Profiles Administration API


    Manage user data using Profiles administrative commands

    Use administrative commands to manage Profiles users by setting their status to inactive.

    The commands in this topic are provided only as a last resort to allow the administrator to modify the data associated with a specific user in the Profiles and application DBs. User data is normally automatically updated from the repository using the IBM Tivoli Directory Integrator scripts or the Profiles Administration API. The commands to update, activate, and inactivate users can introduce discrepancies between the application DBs and the repository if not used carefully. It is very strongly advised that you check the data of the user in the repository prior to using these commands to avoid introducing discrepancies.

    These commands should not be used to propagate directory ID changes. If the Profiles database contains an updated directory ID for a user, it will not be able to identify that user to other component applications that contain an earlier version. These commands can be useful for propagating other profile updates. If profiles in other applications remain out of synch after TDI or admin API commands have been issued, see Synchronize user data using administrative commands.

    Install and configure the IBM HTTP Server before attempting to synchronize data between the Profiles database and other application DBs. See Configuring IBM HTTP Server for details. You can manage users in Profiles to allow for situations in which employees leave the organization. For example, you can set a user's status to inactive, which allows you to reuse the associated email address and login details for new employees. You can also reactivate a user's status in situations where the user leaves the organization temporarily. For example, if a profile owner goes on sabbatical or personal leave, you can set his status to inactive and then reactivate the user's status when he returns.

    When you set a user's status to inactive, that user's name is displayed in italic, gray text in membership lists, and their name is not returned in searches of the company directory. The inactive user's name no longer displays when you use type-ahead, and the person no longer receives email notifications from IBM Connections.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    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 commands to manage the user life cycle:

      Table 54. Profiles user life-cycle commands

      Command Description
      ProfilesService.inactivateUser(String user_email_addr) Inactivates the user with the specified email address.

      After you run this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to make sure the user's information is updated consistently across the application DBs. The status of inactive users can be reactivated at a later time using the ProfilesService.activateUserByUserId command.

      For example:

      ProfilesService.inactivateUser("john.smith@example.com")
      ProfilesService.inactivateUserByUserId(String userID) Inactivates the user with the specified user ID. This command has the same behavior as the ProfilesService.inactivateUser command, except that it takes a user ID instead of an email address as an argument.

      After you run this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to make sure the user's information is updated consistently across the application DBs. The status of inactive users can be reactivated at a later time using the ProfilesService.activateUserByUserId command.

      The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.

      For example:

      ProfilesService.inactivateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")
      ProfilesService.activateUserByUserId(String user_external_id, updated_properties_list) Activates the user with the specified external ID with new properties, which are passed as parameters using updated_properties_list. The default status of any user in IBM Connections is active.

      The user_external_id parameter is the unique ID defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the Profiles database.

      The valid properties for updated_properties_list are:

      • email

      • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.

      • logins. The list of logins stored in the PROFILE_LOGIN table.

      • displayName

      • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.
      You should specify at least one of the properties that will allow the user to log in, and it must be specified using a name-value pair.

      The status change and all property updates are propagated to all the installed IBM Connections applications.

      Examples:

      ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="jsmith@example.com", loginId="jsmith")

      ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="ajretired1@example.com", logins=["alanjones1","ajonesRetired1"])

      ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="speters_Retired1@example.com")
      ProfilesService.updateUser(String user_email_addr, updated_properties_list) Replaces the existing properties for the user with the specified email address with new properties, which are passed as parameters using updated_properties_list.
      The valid properties for updated_properties_list are:

      • email

      • displayName

      • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.

      • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.

      • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
      The properties are all optional and they must be specified using name-value pairs. The updated values are pushed out to all the applications in IBM Connections using a platform command.

      For example, the following command updates the email address and the login for the user john.smith@example.com.

      ProfilesService.updateUser("john.smith@example.com", email="update_email@example.com", loginId="updated_login")
      The following command replaces the existing list of logins with the new one, ("login1", "login2").

      ProfilesService.updateUser("john.smith@example.com", logins=["login1, "login2"])
      ProfilesService.updateUserByUserId(String userID, updated_properties_list) Replaces the existing properties for the user with the specified user ID with new properties, which are passed as parameters using updated_properties_list. This command has the same behavior as the ProfilesService.updateUser command, but it takes a user ID instead of an email address as an argument.

      The valid properties for updated_properties_list are:

      • email

      • displayName

      • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.

      • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.

      • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
      The properties are all optional and they must be specified using name-value pairs. The updated values are pushed out to all the applications in IBM Connections using a platform command.
      The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.

      For example:

      ProfilesService.updateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="update_email@example.com", loginId="updated_login")
      ProfilesService.swapUserAccessByUserId(String userToActivate, String userToInactivate) Associates the following properties of the external ID assigned to the person returning to the organization with the external ID used by the person before leaving the organization:

      • email

      • uid. The value stored in the PROF_UID field in the EMPLOYEE table.

      • guid. The value stored in the PROF_GUID field in the EMPLOYEE table.

      • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.

      • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
      The displayName property is not changed; it is assumed to be the same.

      Users can have access to the data associated with one or the other ID only. When you swap IDs to give a person access to the data associated with an old ID, he loses access to any data he created using the new ID. Run this command soon after the user returns to the organization to limit the amount of new data he can create and subsequently lose access to as a result of the swap.

      The following parameters are required.

      Parameters:

      userToActivate

      Current user ID of the person before leaving the organization and had his user state set to inactivate. Data that was created by this person and that is associated with this ID exists in the Lotus Connections DBs and you want the person to be able to regain access to it.

      userToInactivate

      New user ID that was assigned to the person upon his return to the organization.

      Example: ProfilesService.swapUserAccessByUserId("DRcuidk001retired13","DRcuidk001rehired25") These changes are propagated across all the installed applications in IBM Connections.

      ProfilesService.publishUserData(String user_email_addr) Publishes an update command to all the IBM Connections applications for the user with the specified email address.

      The command publishes the data that is currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, you can use this command to force all the applications to resynchronize their data.

      For example:

      ProfilesService.publishUserData("john.smith@example.com")
      ProfilesService.publishUserDataByUserId(String userID) Publishes an update command to all the IBM Connections applications for the user with the specified user ID. This command has the same behavior as the ProfilesService.publishUserData command, except that it takes a user ID instead of an email address as an argument.

      The command publishes the data that is currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, you can use this command to force all the applications to resynchronize their data.

      The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.

      For example:

      ProfilesService.publishUserDataByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")


    Related

  • Configure IBM HTTP Server
  • Synchronize user data using administrative commands

  • Start the wsadmin client
  • Delete or inactivate users in the Profiles database
  • Synchronize source changes such as LDAP with Profiles


    Manage user data using Tivoli Directory Integrator scripts

    There are a number of scenarios in which you might want to synchronize changes between the Profiles database and the LDAP directory, using IBM Tivoli Directory Integrator.

    When you want to update user information in the Profiles database, the model typically used is to update the information in the LDAP directory and then synchronize the changes back to the Profiles database. For example, if your organization has taken over a new division, you can add new employees to Profiles by importing their details into the LDAP directory and then synchronizing the changes to the Profiles database. One way to keep your profiles data synchronized with changes to the LDAP directory is to use the sync_all_dns task. For more information, see Synchronizing LDAP directory changes with Profiles.

    However, there might be instances in which your organization wants to allow users to update their information directly in the Profiles database. For example, if users want to update their personal cell phone details, as administrator, you might allow them to make the changes in Profiles themselves. These changes must be synchronized back to the LDAP directory from Profiles. To start the synchronization process, you need to define values for the DSML server-related properties in the profiles_tdi.properties file and then run the appropriate process_draft_updates script. For more information, see Synchronizing user data between Profiles and LDAP.

    Although it is not expected to be a frequent occurrence, there might also be instances in which you want to change your LDAP directory. In this scenario, you can run scripts that are provided with IBM Connections to synchronize the user information used in Profiles with the user information stored in your new LDAP directory. For more information, see Updating Profiles when changing LDAP directory.

    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
  • Developing custom Tivoli Directory Integrator assembly lines for Profiles
  • Add supplemental content to Profiles

  • Tivoli Directory Integrator commands


    Synchronize source changes such as LDAP with Profiles

    As administrator, you need to synchronize changes from your LDAP directory to the Profiles database to ensure that your organizational information is kept up-to-date. Use the sync_all_dns task to keep your profiles data synchronized with changes to the LDAP directory. IBM recommends that you run this task on a regular basis.

    If your LDAP directory has a data size limitation, consider using the source_ldap_iterate_with_filter property set to true when synchronizing changes from the LDAP directory back to the Profiles database. This property replaces the sync_all_dns_forLarge and collect_dns_iterate scripts used in earlier releases. Profiles is the repository for information about the people in your organization within IBM Connections. Typically, this data is retrieved from an LDAP or other corporate source which is the master copy. When data changes in the source, you will want these updates reflected in Profiles and throughout Connections. For example, if an employee moves department or leaves the company, or if your organization has taken over another division and you want to import new hires into the Profiles database, you update the LDAP directory and then synchronize the changes to the Profiles database.

    For data sources, such as LDAP, the sync_all_dns command can be used to take changes from the source and apply them to the Profiles database. If you want to keep the Profiles database in a close synchronized state with your LDAP directory, run this task nightly or at another frequency that suits you. During synchronization, the entries in the Profiles database are compared to the mapped values from the source. Updates are then applied to existing records, new records are added, and no longer found records are removed based on configuration settings. Because this task performs a complete comparison of the search scope with the Profiles database, be sure to allow sufficient time for it to run. As with the initial data population, the mapping values configured in map_dbrepos_from_source.properties are compared to determine if an update is needed. If you configure extension attributes, that information is also compared and synchronized.

    The sync_all_dns task creates temporary files that are used during the synchronization process so you need to allocate sufficient disk space. Set the location of these files and whether to delete or retain them after synchronization using the sync_updates_working_directory=sync_updates and sync_updates_clean_temp_files=false properties.

    If you are troubleshooting a problem, you should change the sync_updates_clean_temp_files=false setting to false to retain the temporary files for diagnosis.

    In addition to the temporary files, the following files in the TDI solution directory record the changes made during synchronization. When set to true, the sync_updates_show_summary_only property shows only the records that need to be changed, but does not make the changes. See Understanding how the sync_all_dns task works for more information.

    • employee.adds

    • employee.delete

    • employee.error

    • employee.skip

    • employee.update

    Like the other IBM Tivoli Directory Integrator tasks, the sync_all_dns command has its own log file that shares the same name as the task. You can check the log to see whether the task finishes successfully, and look for error information if necessary. You can also check the ibmdi.log file. This file is a system log that records detailed information about the task when it is run. All the Tivoli Directory Integrator log files are located in the TDI\logs folder.

    To synchronize LDAP directory changes with Profiles, perform the following steps.

    1. In addition to the general Tivoli Directory Integrator configuration properties, you can set the following properties in the profiles_tdi.properties file to control the synchronization process. For more information about Tivoli Directory Integrator configuration properties, see Tivoli Directory Integrator solution properties for Profiles.

      With the exception of sync_delete_or_inactivate, these properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes and process_ad_changes commands.

      Option Description
      perform_deletion_for_sync Controls whether the specified delete action is performed as part of the sync_all_dns task. Set this property to true when you want to delete or mark as inactive those users who are no longer in the Profiles database.

      The command checks the value of the property and acts using the following logic:

      • If perform_deletion_for_sync=false then perform neither the delete nor the inactivate action.

      • If perform_deletion_for_sync=true then look at the sync_delete_or_inactivate property.

      • Based on the value of the sync_delete_or_inactivate property (either delete or inactivate), perform the specified action.

      source_ldap_iterate_with_filter

      This configuration should be used if the size of the data to be retrieved from LDAP exceeds the search limit from the LDAP. For example, if your search parameters would return 250K records but your LDAP only allows 100K to be returned at a time, this parameter must be used.

      If the data is too large, an LDAP size limit exceeded error message is generated. To configure this mechanism, see the Populating a large user set topic.

      When set to true, this specifies that the default iterations assembly line use the collect_ldap_dns_generator.js file to iterate over a set of LDAP search bases and filters. The cconfig setting replaces the sync_all_dns_forLarge and collect_dns_iterate scripts used in earlier releases.

      The default value is false.

      This parameter is not configurable when using the population wizard.

      sync_check_if_remove

      Specifies the name of an optional custom delete hook assembly line. By default, the assembly line's name is set to sync_all_dns_check_if_remove. For more information about this property, see Customize the logic used for the delete operation.

      The sync_updates_double_check property must also be set to use this functionality.

      sync_delete_or_inactivate

      Controls what happens to a user record when the delete action is performed. The value must be either delete or inactivate and is case sensitive. By default, the property is set to inactivate so that users are not deleted. The inactive state is propagated to all the other IBM Connections applications.

      This property cannot be used with the sync_all_dns, process_tds_changes, and process_ad_changes commands.

      For more information about this property, see Customize the logic used for the delete operation.

      For information about automating the delete user or inactivate user process, see Using supplied scripts to delete inactive users based on inactivity length.

      sync_updates_clean_temp_files

      When set to true, this property deletes temporary files after the synchronization process is completed.

      sync_updates_double_check

      Uses the custom deletion-checking assembly line that is defined in the sync_check_if_remove property to perform a double check. The logic of the default double-check assembly line is to match on the distinguishedName mapping (usually $dn). If that match fails, the user is assumed to no longer be in the LDAP directory and is deleted.

      sync_updates_hash_field

      This property is used to match a record in the Profiles database with the corresponding record in the source. Choose a value that will not change, so that the match will remain intact between the source and the Profiles database.

      If the value in this field in the source changes, the match will be broken and unintended actions may take place, for example the existing database information for this person could be deleted if the corresponding match in the source is no longer accessible.

      The supported values for this field are guid, uid, and email.

      If the value of the hash field in the source has changed, you must set this property to a different value that has not changed. For example, if you have not changed the value of email, you can set it to email.

      The default value is uid.

      sync_updates_hash_partitions

      Number of partitions to divide the temporary files into. The default of 10 is sufficient in most cases. If the file size gets too large, this value can be increased.

      sync_updates_show_summary_only

      When set to true, this property shows only the records that need to be changed, but does not make the changes.

      sync_updates_working_directory

      The directory where the working files are stored. The path can be relative to the Tivoli Directory Integrator solution directory or an absolute path.

    2. Optional: If you are storing data from multiple LDAP branches in the same database, and you want to keep these areas synchronized with the LDAP directory, then you also need to synchronize them separately or distinctly. To accomplish this task, you can set the following properties in the profiles_tdi.properties file:

      These properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes and process_ad_changes commands.

      Option Description
      sync_source_url_enforce=true Synchronizes only those records that have a matching URL. When set to true, it limits the scope of the set of data in the database and skips the records that do not match the source URL. When set to false, it deletes the records that do not match the source URL. The default value is false.

      sync_source_url_override=true Updates the source_url field if it doesn't match when the employee is being updated.

      sync_store_source_url=true Stores the source LDAP URL in the prof_source_url field in the database. The source LDAP URL is needed to determine the source of the data to correctly synchronize it.

      When storing the sync_store_source_url property in the Profiles database, the data format of prof_source_url in the Profiles database is as follows:

      ldap://{hostname}:port/ldap_search_base?ldap_search_filter

    3. Optional: When the sync_all_dns task is performed, it generates a lock file in the Tivoli Directory Integrator solution directory to prevent other customers from starting another sync_all_dns process in the same Tivoli Directory Integrator solution. The name of the lock file is sync_all_dns.lck. When the sync_all_dns process has finished successfully, the lock file is automatically deleted. However, if the process did not complete, the lock file won't be deleted. In this case, you can delete it yourself, or run the clearLock.sh or clearLock.bat command, located in the Tivoli Directory Integrator solution directory.

    4. Process changes using one of the following options:

      • IBM AIX or Linux:

        chmod +x sync_all_dns.sh

        ./sync_all_dns.sh

      • Microsoft

        Windows:

        sync_all_dns.bat


    Example

    This sample employee table illustrates results from a scenario in which you have pulled users A, B, and C from ldap_branch1 and users X, Y, and Z from ldap_branch2.

    Table 55. Example employee table correlating initial employee UID and DN values

    uid distinguishedName (DN)
    A ldap_branch1
    B ldap_branch1
    C ldap_branch1
    X ldap_branch2
    Y ldap_branch2
    Z ldap_branch2
    To synchronize the ldap_branch2 users, set the following properties:

    • source_ldap_url=ldap_branch2

    • sync_store_source_url=true

    • sync_source_url_enforce=true

    • sync_source_url_override=false

    By setting these properties, you get updates for the ldap_branch2 users X, Y, and Z, but not for users A, B, and C. Updates are not provided for users A, B, and C because their PROF_SOURCE_URL does not match the Tivoli Directory Integrator property source_ldap_url. When you set sync_source_url_enforce to true, the script skips users A, B, and C. When you set sync_source_url_enforce to false, users A, B, and C are deleted from the database.

    To move the ldap_branch1 users to another branch of the LDAP directory , ldap_branch3, set the following properties:

    • source_ldap_url=ldap_branch3

    • sync_store_source_url=true

    • sync_source_url_enforce=true

    • sync_source_url_override=true
    This configuration retrieves the users from ldap_branch3, and finds users A, B, and C but not users X, Y, and Z. It matches users A, B, and C because the hash field is the same. The synchronization updates in the Profiles database are shown in the following table:

    Table 56. Example employee table correlating changed employee UID and DN values

    uid distinguishedName
    A ldap_branch3
    B ldap_branch3
    C ldap_branch3
    X ldap_branch2
    Y ldap_branch2
    Z ldap_branch2


    Related

  • Manage users

  • Switch to unique administrator IDs for system level communication
  • Customize the logic used for the delete operation
  • Manage user data using Profiles administrative commands
  • Update Profiles when changing LDAP directory

  • Tivoli Directory Integrator solution properties for Profiles
  • Batch files for processing Profiles data


    Synchronize IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes

    To keep your profiles synchronized with your LDAP directory, use the generic sync_all_dns command. However, if your LDAP directory is IBM Tivoli Directory Server or Microsoft Active Directory, you can use the process_tds_changes or process_ad_changes commands. The process_tds_changes and process_ad_changes commands do not support synchronizing multiple LDAP directories or multi-branch LDAP directories. If you have populated your profiles database with data from multiple locations, running the process_tds_changes and process_ad_changes commands applies changes related to the current LDAP directory only.

    To synchronize Tivoli Directory Server and Microsoft Active Directory LDAP directory changes with Profiles, perform the following steps.

    1. Update the change log properties in the profiles_tdi.properties file so that the changes to the LDAP directory can be reflected back to the Profiles database. The change log properties are the set of properties that begin with <LDAP_type>_changelog_*.

    2. Process changes using one of the following options:

      • For Tivoli Directory Server, use the following script to process changes made to the LDAP directory and have those changes made to the corresponding records in your database repository:

        • IBM AIX or Linux:

          chmod +x process_tds_changes.sh

          ./process_tds_changes.sh

        • Microsoft

          Windows:

          process_tds_changes.bat

      • For Microsoft Active Directory, use the following script to process changes made after the initial population:

        • AIX or Linux:

          chmod +x process_ad_changes.sh

          ./process_ad_changes.sh

        • Microsoft

          Windows:

          process_ad_changes.bat

    3. The process_tds_changes task keeps track of the changelog number in a persistent field. If your LDAP directory is reset, you can do one of the following:

      • Delete the changelog number value using the following script:

        • AIX or Linux:

          chmod +x reset_changelog_state.sh

          ./reset_changelog_state.sh

        • Microsoft

          Windows:

          reset_changelog_state.bat

      • Set a particular value using the following script and passing it the count value to set:

        • AIX or Linux:

          chmod +x set_changelog_count.sh

          ./set_changelog_count.sh

        • Microsoft

          Windows:

          set_changelog_count.bat


    Synchronize user data between Profiles and the LDAP directory

    To update profiles data, you typically update the LDAP directory first and then synchronize the changes to the Profiles database. However, there are some cases where you might want to allow your users to make their own changes to their profiles, and these changes need to be written from the Profiles database back to the LDAP directory.

    Be sure to install and configure the IBM HTTP Server before attempting to synchronize data between the Profiles database and the LDAP server. See Configuring IBM HTTP Server for more information. You can ensure that data in the LDAP directory is kept current by synchronizing any changes made to the Profiles directory back to the LDAP server. For example, users in your organization might need to update their cell phone details in Profiles. They cannot change the LDAP directory directly and, as administrator, you can allow them to make the changes directly in Profiles. These changes need to be reflected back to the LDAP directory using the drafting process.

    The draft table stores values that you edit and which you specify using the draftableAttribute element in the profiles-config.xml file. For example:

    <profileDataModel>
       <!-- =================================================================================== -->
       <!-- This section is used to define attributes that are updated via the drafting process -->
       <!-- In most deployments you should never edit the config for this section.   -->
       <!-- Example: <draftableAttribute>displayName</draftableAttribute>  -->
       <!-- Example: <draftableExtensionAttribute extensionIdRef="tieline"/>  -->
       <!-- =================================================================================== -->
       <draftableAttribute>telephoneNumber</draftableAttribute>
    </profileDataModel>
    The Profiles database is updated immediately with the specified values.

    You must configure a Directory Services Markup Language (DSML) server service to receive the update requests. The Profiles application does not provide this service because each implementation of an LDAP server is unique.

    To synchronize changes between the draft table and the LDAP server, you must run a script that initializes a daemon process that monitors the Profiles database for updates and, when one is made, formats the update as a DSML request and transmits it to a configured DSML server.

    To synchronize changes from the Profiles database back to your LDAP directory.

    1. Define values for the DSML server-related properties in the profiles_tdi.properties file. The DSML server-related properties are the properties with names that begin with monitor_changes_ and dsml_server_. Typically, you must update the following properties:

      • monitor_changes_dsml_server_url

      • monitor_changes_dsml_server_username

      • monitor_changes_dsml_server_password

    2. After providing values for the necessary properties, start the synchronization server process by running the following scripts:

      • IBM AIX or Linux:
        chmod +x process_draft_updates.sh
        ./process_draft_updates.sh

      • Microsoft

        Windows:
        process_draft_updates.bat

      The process_draft_update script tracks the database change record number in a persistent field. Your task cannot run successfully in the following situations:

      • You recreate the Profiles database after you have already run the IBM Tivoli Directory Integrator Solution at least once.

      • You clear the content of the CHG_EMP_DRAFT and EMP_DRAFT tables manually.

      In such situations, reset the persistent field and run the script again. You can reset the persistent field by performing one of the following steps:

      • Delete the database change record number value using the following script:

        • AIX or Linux:
          chmod +x reset_draft_iterator_state.sh
          ./reset_draft_iterator_state.sh

        • Microsoft

          Windows:
          reset_draft_iterator_state.bat

      • Set a particular value using the following script and pass it the count value to set:

        • AIX or Linux:
          chmod +x set_draft_iterator_count.sh
          ./set_draft_iterator_count.sh

        • Microsoft

          Windows:
          set_draft_iterator_count.bat


    Related

  • Configure IBM HTTP Server

  • Synchronize user identification data between Communities and the LDAP directory
  • Change Profiles configuration property values
  • Use the Profiles database as the user directory

  • Activities administrative commands


    Understand how the sync_all_dns process works

    Use the sync_all_dns process to keep your profiles data synchronized with changes to the LDAP directory. The sync_all_dns process is a long running process comprised of multiple phases.

    As each phase of the sync_all_dns process runs, console output indicates current progress. The number of records in the LDAP source, and in the Profiles database, enable you to estimate the running time of the process.

    The properties mentioned in this topic reside in the profiles_tdi.properties file.

    Temporary files are created during synchronization and stored in the directory denoted by the sync_updates_working_directory=sync_updates property. By default, the temporary files are deleted at the end of synchronization. If you want to keep the files or need to troubleshoot problems, set sync_updates_clean_temp_files=false to ensure that the temporary files are not deleted.


    Phase 1

    The first phase processes the database. Progress is output every 10,000 records including a timestamp.

    Example:

    CLFRN1275I: Begin to hash records in database.
    CLFRN0028I: 20120806100604 Iterations: 10000.
    CLFRN1269I: Finish hash records in database.


    Phase 2

    The second phase processes the source with the same progress indicators as Phase 1.

    Example:

    CLFRN1271I: Begin to hash records in source repository.
    CLFRN0028I: 20120806110738 Iterations: 10000.
    CLFRN0028I: 20120806110937 Iterations: 20000.
    CLFRN0028I: 20120806111137 Iterations: 30000.
    CLFRN1273I: Finish hash records in source repository.


    Phase 3

    The third phase performs a comparison between the data retrieved in Phase 1 and 2.

    Example:

    **********
    CLFRN1268I: After processing partition 0, 3,772 records added to creates.ldiff; 1,947 records added to deletes.dbids.
    **********
    CLFRN1268I: After processing partition 1, 3,823 records added to creates.ldiff; 1,951 records added to deletes.dbids.
    **********
    ...
    **********

    This comparison determines if an operation should occur on a particular record from the LDAP source or from the Profiles database.

    Because the operation is not complete at this point in the processing, the numbers listed in this phase do not always match the final phase numbers.

    The processing is delimited by the number of partitions specified by the sync_updates_hash_partitions=10 property.

    The creates.ldiff and deletes.dbids files included in this example are stored in the location specified by the sync_updates_working_directory=sync_updates property.


    Phase 4

    The fourth phase performs the configured delete operation using the deletes.dbids file from Phase 3 for input.

    Example:

    CLFRN1270I: Begin processing the data to be deleted or inactivated.
    CLFRN0028I: 20120806122644 Iterations: 10000.
    CLFRN1272I: Finish processing the data to be deleted or inactivated.

    The operation is determined by the following properties:

    • sync_delete_or_inactivate=delete . Determines the action to be performed if a record is no longer found in the source LDAP but is present in the Profiles database.

      If you want to perform additional processing during this phase, you can create and configure a custom delete option. See Customize the logic used for the delete operation for details.

    • sync_updates_double_check=true

    • sync_check_if_remove={name-of-your-adapter.xml}:/AssemblyLines/{name-of-your-custom-delete-al}


    Phase 5

    The fifth phase performs the add or update operations, using the create.ldiffs file from Phase 3 for input.

    Example:

    CLFRN1276I: Begin processing the data to be added.
    CLFRN0028I: 20120806124006 Iterations: 10000.
    CLFRN0028I: 20120806124513 Iterations: 20000.
    CLFRN0028I: 20120806125021 Iterations: 30000.
    CLFRN1274I: Finish processing the data to be added.


    Summary phase

    A summary is displayed at the end of the sync_all_dns process.

    Example:

    CLFRN0037I: After synchronization, added or modified records is 37971, deleted or inactivated record
    s is 19551, unchanged records 0, and failure records is 0. 

    Lists of the users for each of the operations are stored in the following files in the solution directory. You can examine these files when the synchronization process has completed. These files are not considered temporary and are not removed at the end of the synchronization process.

    • employee.adds . These records were added to the database

    • employee.delete . These records were deleted or inactivated in the database

    • employee.error . There was an error processing these records

    • employee.skip . These records were not changed in the database

    • employee.update . These records were updated in the database


    Update Profiles when changing LDAP directory

    When you need to change to a new LDAP directory, you must synchronize the user data stored in profiles with the information in your new LDAP directory. You can run a command that synchronizes the information in the Profiles database with the user information stored in your new LDAP deployment.

    You must ensure that the values of either the uid or the email address in the existing data source match those in the new deployment LDAP directory. If neither of these properties have matching values, you cannot use the scripts provided with IBM Connections to synchronize the IDs.

    To use the scripts provided with IBM Connections to synchronize the IDs and update Profiles:

    1. Open the profiles_tdi.properties file from the IBM Tivoli Directory Integrator directory on the system that hosts the Profiles application in a text editor, and edit the following properties to match the values of the corresponding properties in the LDAP system:

      • source_ldap_url

      • source_ldap_user_login

      • source_ldap_user_password

      • source_ldap_search_base

      • source_ldap_search_filter

      • source_ldap_use_ssl
      For more information about these properties and how they are used, see Tivoli Directory Integrator properties.

    2. Ensure that the guid property in the map_dbrepos_from_source.properties file is set to the appropriate value for your environment:

      • IBM Tivoli Directory Server:

        guid=ibm-entryUuid

      • IBM Lotus Domino Directory:

        guid={function_map_from_dominoUNID}

      • Microsoft Active Directory:

        guid={function_map_from_objectGUID}

      • Sun Java System Directory Server:

        guid=nsuniqueid

      • eNovelle System Directory Server:

        guid={unction_map_from_GUID}

    3. Identify a database attribute, either uid or email, with the same value per member in the old LDAP deployment as in the and the new deployment, and then set the sync_updates_hash_field property in the profiles_tdi.properties file to this attribute. The names of the LDAP attributes are immaterial.

      sync_updates_hash_field=uid

    4. Synchronize the data so that the values from the new LDAP deployment are updated in the Profiles database by running the following script:

      • IBM AIX or Linux:

        chmod +x sync_all_dns.sh
        ./sync_all_dns.sh

      • Microsoft

        Windows:

        sync_all_dns.bat
      For more information about the properties that you can set when synchronizing LDAP data with Profiles, see Synchronizing LDAP directory changes with Profiles.


    Related tasks

  • Map fields manually
  • Synchronize source changes such as LDAP with Profiles

  • Tivoli Directory Integrator solution properties for Profiles
  • Batch files for processing Profiles data


    Delete or inactivate users in the Profiles database

    You can use an IBM Tivoli Directory Integrator assembly line command to delete or inactivate users in the Profiles database. You can use the delete_or_inactivate_employees assembly line command to delete specific users from the Profiles database or set their status to inactive.

    To delete or inactivate specific users from the Profiles database:

    1. Create a text file named delete_or_inactivate_employees.in that contains the distinguished names and user IDs for the users that you want to delete from the database. Use the following format to represent a user:

      $dn:user_dn
      uid:user_uid
      .

      ...where:

      • user_dn corresponds to the PROF_SOURCE_UID in the Profiles database.

      • user_uid corresponds to the PROF_UID in the Profiles database.

      When deleting multiple users, there must be a period separator (.) between each entry. The "." must be added after the row containing the user's UID. If the separator is omitted, an error occurs when you use the delete command to delete the users from the database.

      Do not add a space after the colon and before the value. Here is an example of an entry from the delete_or_inactivate_employees.in file:

      $dn:cn=Amy Jones3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
      uid:Amy Jones3
      .
      When loading multiple users, there must be a period separator between each entry.

      For example:

      $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. Place the file in the Tivoli Directory Integrator location specified for your deployment. For more information, see Configuring Tivoli Directory Integrator.

    3. Run the delete_or_inactivate_employees.sh or delete_or_inactivate_employees.bat script to delete the users from the database. The following table shows the properties that are used by the command and their default values. These properties can be found in the profiles_tdi.properties file.

      The file path is relative to the TDI solution directory.

      Table 57. Properties used with the delete_or_inactivate_employees command

      Property Description
      delete_or_inactivate_employees_simple_file File that you created in Step 1, which lists the people to be deleted or inactivated. The default value is delete_or_inactivate_employees.in.
      sync_delete_or_inactivate Specifies whether to delete or inactivate the people listed in the file specified using the delete_or_inactivate_employees_simple_file property. The options are:

      delete

      Removes the user from the Profiles database and, if the user exists in member or login tables for any of the other applications, deletes the user from those applications. The person.s email address is removed, all login values associated with the person are removed, and the photo and pronunciation files associated with the employee are deleted from the photo and pronunciation tables. You cannot add deleted users back into the directory and you cannot recover any data that they created after you delete them.

      inactivate

      Sets the person's status to inactive. Unlike deleting people, when you inactivate people, you can reinstate them later if necessary. See Managing user data using Profiles administrative commands for more details. Any data created by the inactive person is preserved. An inactive person is identifiable in the product user interface because the person's name is greyed out, but information they contributed, to a community or forum, for example, is retained. An inactive person.s name is not included in searches and membership selection fields.

      The default value is inactivate.

      The inactivation of the person is propagated to the member and login tables for all the applications.


    Related tasks

  • Manage user data using Profiles administrative commands
  • Configure Tivoli Directory Integrator
  • Customize the logic used for the delete operation

  • Batch files for processing Profiles data


    Customize the logic used for the delete operation

    You can customize the delete logic to use when deleting users from the Profiles database. IBM Connections provides a plug-in point for defining and using custom IBM Tivoli Directory Integrator (TDI) assembly lines that contain their own delete logic as part of the sync_all_dns task. This delete logic is used to identify when a user needs to be deleted from the Profiles database. An assembly line named sync_all_dns_check_if_remove, which checks whether a user should be deleted, is provided by default. You can add custom delete logic without making changes to the existing profiles_tdi.xml file.

    1. Configure your development environment for creating a delete logic script by following the steps in the topic, Set up your development environment.

    2. Define an assembly line that contains your delete logic in the file. Your assembly line must return one of the following values:

      • remove. Specifies that the current entry should be added to the delete list.

      • updated. Specifies that the current entry should be updated, not deleted.
      These values are case-sensitive.

      Return the value as follows:

      1. Retrieve the checkResult attribute field from the work object into your assembly line. The attribute name is case-sensitive.

      2. Set your checking result to the value of the checkResult attribute.
      For example:

      checkingResult = work.getAttribute("checkResult");
      checkingResult.setValue("updated");

      For more information about how to create an assembly line, go to the following web page:
      http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_7.0/CreatingyourfirstassemblyLine.htm

    3. Use the publish feature to export the assembly line as a Tivoli Directory Integrator adapter.

      1. Right-click the assembly line in the Navigator and select Publish.

      2. Enter the name of the adapter in the Package ID field.

      3. Set the following directory in the File Path field, and then click Finish.
        profiles_tdisoln/packages

    4. 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.

    5. Open the profiles_tdi.properties file from the following location:

      tdisol.tar|zip/tdisol/TDI

    6. Set the following properties in the file:

      sync_updates_double_check

      Specifies whether your checking assembly line is used. When set to true, your deletion-checking assembly line is used. When set to false, the checking operation is not performed. The default value is false.

      For example:

      sync_updates_double_check=true

      sync_check_if_remove

      Specifies the name of your checking assembly line:

      sync_check_if_remove=name_of_your_adapter_xml_file:/AssemblyLines/name_of_your_assemblyline
      By default, the assembly line's name is set to sync_all_dns_check_if_remove.

      For example, if you publish the assembly line with the file name deleteCheckRoutines and the assembly line is example_check_if_user_really_deleted, use the following statement to set this property:

      sync_check_if_remove=deleteCheckRoutines:/AssemblyLines/example_check_if_user_really_deleted

      sync_delete_or_inactivate

      Controls what happens to a user record when the delete action is performed. This property can be set to one of the following values:

      • delete. Specifies that the user record is deleted.

      • inactivate. Specifies that the user record is inactivated.

        The inactive status is propagated to the member and login tables for all the applications. An event is generated for each of the following: Activities, Blogs, Bookmarks, Communities, Files, Forums, Profiles, Wikis, and News (which includes both Home page and Search). These events inactivate the user in every application by removing the user from the login tables and setting the user's status to 1 in all member tables.

      These values are case-sensitive so type them with care. The default value is inactivate.

      For example:

      sync_delete_or_inactivate=inactivate

    7. Save your changes to the profiles_tdi.properties file.


    Related tasks

  • Set up your development environment
  • Delete or inactivate users in the Profiles database
  • Synchronize source changes such as LDAP with Profiles


    Manage users when the Profiles application is not installed

    If the Profiles application is not installed, you must manage changes to user status and data in each application database independently. The only way to update user data in the DBs for the other applications is through a set of administrative synchronization commands.

    These commands can also be used on IBM Connections deployments that do have Profiles installed to resolve situations

    ...where an application's membership database table needs to be corrected.


    Synchronize user data using administrative commands

    Synchronize user data between the IBM Connections application membership tables and the configured directory for the deployment.

    Each Connections application has its own database with membership tables containing a users external ID and user data related to that application. These DBs must be synchronized with the configured directory in the deployment. The configured directory is typically the Profiles database in deployments where Profiles is installed and Profiles integration is enabled. If Profiles is not installed or is installed but Profiles integration is not enabled, then the configured directory is the corporate LDAP directory.

    The commands documented in this topic synchronize user data between the application DBs and the configured directory in your environment. They also log entries in the application_name\UlcSyncCmd.log file that reports updated data items.

    When Profiles is installed, you should not generally use these commands. Profiles automatically synchronizes its user data with the application DBs. Also, there is a set of Profiles administration commands for synchronizing in that environment. However, you can use these commands to resolve situations where an application database needs to be corrected. For example, if synchronization occurs for all but one application and you have a mismatch in that application.s database.

    Many of the synchronization commands have a matching preview command that shows you what the synchronization command would do if you ran it. For example, the FilesMemberService.previewSyncAllMembersByExtId command generates a log showing what the FilesMembersService.syncAllMemberByExtId command would do if you ran it. This can be useful when mismatches are suspected. The logs are located in the standard logging directory for the server, for example where the cluster.sSystemOut.log file is located, and the name is application_name\UlcSyncCmd.log. Output is appended if the log file already exists.

    You should run preview versions of commands before running the actual commands. When you are sure the command will do what you want, run the actual command.

    The following commands, identified by the leading wsadmin> parameter, update the Communities membership database.

    1. Initialize the Communities commands and then preview what the synchronize all command would do.

      wsadmin>execfile("communitiesAdmin.py")
      wsadmin>CommunitiesMemberService. previewSyncAllMembersByExtId({"updateOnEmailLoginMatch":
      "true", "verbose" : "true"}
      UpDt ExtId: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1XX Name: Jane Doe has a superseded external ID,
      and would have been updated: New ExtId: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1
      [2012-08-07 14:50:54] Additional application possibly-stale member data: Email:
      jane_doe@us.acme.com Logins: [Doe, jane_doe@us.acme.com, Jane Doe]
      [2012-08-07 14:50:54] Directory service basic user data: Display name: Jane Smith Update
      External id: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1
      [2012-08-07 14:50:54] Directory service email and logins: Email: sTestuser5@janet.iris.com
      Logins: [Smith, Jane Smith, jane_doe@us.acme.com]

      The command reveals that the user.s external ID in Communities is obsolete.

    2. Run the following command to update the user.s external ID. Note that the preview sync all users command has been replaced by the more specific sync by email. You could use the syncAllMembersByExtId() parameter associated with the preview but it is best to use the most specific command.

      wsadmin>CommunitiesMemberService.syncMemberExtIdByEmail("jane_doe@us.acme.com ")
      
      CLFWY0263I: The synchronize command found that active member Jane Smith [current external id:
      f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1XX, application id 6a716827-5fc8-438a-beb2-777f6f5d96df]
      could not be matched via external id, but could be matched via login or email to external id
      f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1. 
      The member was updated because this action was enabled by the command.

    Only use the commands in this topic to synchronize user data in the following situations:

    • Profiles is not installed, or Profiles integration is disabled.

    • You have just migrated from an earlier version of Connections.

    • You want to synchronize data for a specific application or a specific person in a specific application.

    • You want to determine if any application member data is out of sync with the configured directory.


    Administrative commands

    Use the following commands to update the identifying data and state (active or inactive) of the users listed in the application database, except for Profiles

    ...where you would use Tivoli Directory Integrator (TDI) to synchronize users in the Profiles database with a source LDAP database.

    The use of square brackets indicates that the enclosed parameters are optional; the square brackets are not part of the command line.

    The application_name variable represents the name of the application. The following options are available:

    • Activities

    • Blogs

    • For Bookmarks, specify Dogear

    • Communities

    • Files

    • Forums

    • News repository: The Home page, News repository, and Search applications share the same database, so running the synchronization command against News repository applies to all three areas.

    • Profiles

    • Wikis

    • Metrics

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

    This checks to see if the external ID found in the member database table is present in the configured directory as follows:

    • If the external ID is present, then the command gets the display name, email address, and login names from the configured directory and updates the application database tables with the values from the directory, if they are different. This refresh update operation is not logged to the output file.

    • If a match for the user's external ID is not found in the directory, then the command uses the email address and login names contained in the application database tables to continue to search for the user in the configured directory. When none of the credentials match the user is inactivated. How the command works when a match on the login names or email address is found differs depending on the parameter you specified with the command:

      Parameter: updateOnEmailLoginMatch: String. Options are true or false. The default is false.

      true

      Specifies that when a match is found in the configured directory based on the login names or email address of the user, the external ID in the application database is automatically updated with the external ID in the configured directory.

      false

      Specifies that when a match is found in the configured directory based on the login names or email address of the user, the external ID in the application database is written to the application_nameUIcSyncCmd.log file. You can manually make the update after confirming that the change should be made.

    • If a match for the user's external ID is not found in the configured directory, nor is a match found for the user's email address and login names, then the state of the user is changed to inactive in the application database.

    When none of the credentials match, the Boolean (true or false) parameter is ignored; the user is always inactivated.

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

    The preview command reports the action the corresponding syncAllMembersByExtId command would take (or not take) depending on the updateOnEmailLoginMatch parameter value. The results are placed in the application_nameUlcSyncCmd.log file.

    There are two optional parameters, multiLine and verbose, both of which take a Boolean string value. The default value is true for multiLine and false for verbose. If multiLine is true, each action report is broken into multiple short lines to make it easier to read. If multiline is false, each action report is a single line for ease of searching the file programmatically, for example with a grep utility. If verbose is false, only out of sync results are reported independent of the value of updateOnEmailLoginMatch. This includes members that would simply be refreshed. A member is refreshed if the member is active and the external ID is a match, but the display name, email, or the logins don.t match. If verbose is true, all members are reported, including active and inactive members.

    The format of each reported action is timestamp, action code, action data and action message. The code is a four letter code, listed at the end of this section. At the end of the file five numbers are reported. These are also explained at the end of this section. At the very end of the file is a number that is the total actionable items found.

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

    This determines whether the user identified by the first parameter, which is an eternal ID, should be is active or inactive by checking the configured directory for the external ID. The main purpose of this command is to reactivate a user.

    This is a complicated command that should be used carefully, particularly when swap is allowed.

    You can perform the following tasks with this command:

    • When only currentExternalId parameter is provided, the intent is to correct the state information for that user in the application database.

      Parameters:

      currentExternalId

      String. Unique external ID that represents a user. The command looks for this external ID in the application member table. If it does not find the ID, an error is generated. If the member is found, but is currently defined as inactive, an attempt is made to activate the member. To do so, the command looks up whether the member exists in the configured directory, and if so, then the member is activated in the application member table and the associated display name, email and login values for that member are restored. When this action is taken, the update is logged in the applicationUIcSyncCmd.log file. If the member is found and is currently defined as "active" in the application database, the code first looks up currentExternalId in the configured directory. If currentExternalId is not found, the command attempts to find the member by email or login value. If this succeeds, the external ID is updated along with a refresh of display name, email, and logins, and the change is logged. If this does not succeed, then the user is inactivated and the change is logged.
      Example:

      CommunitiesMemberService.syncMemberByExtId("F8E59CA4-7FE1-4195-AA96-A49CE5F8E17F")

    • When multiple parameters are provided, the intent is to activate the user identified by currentExternalId with the identity of the user defined by the newExtId. This command might be used when a user has application content, such as a Community, on the server but then leaves the company. The user is removed from the LDAP and the user's state is set to inactive in the application database tables. However, if that person is rehired by the company, the person is added back into LDAP and is assigned a new external ID. For this person to gain access to their old content, you can use the following command to swap their external IDs.

      Parameters:

      currentExternalId

      String. Unique ID that represents a user.

      newExtId

      Optional. String. If you provide this parameter:

      1. The same person is being represented by two different external IDs: the currentExternalId is in the application database where the member is marked as inactive and the newExtId, is stored in the configured directory.

      2. The newExtId updates that person.s external ID in the application database and the person is marked active.

      Only use this command when you are sure that the two IDs represent the same person.

      allowExtIdSwap

      Optional. String. Accepts the values true or false. The default value is false. Specifies whether to swap the new and current ID of the user in the two records that represent the same person. This parameter is only needed if the user was previously employed by the organization and existed in the application member tables with the current ID, departed the organization, and was given a new ID upon returning. After that person logs in to an application for the first time with their new ID, the new ID is added to the application member tables. If you want this new user to have access to the content that she created previously using the current ID, provide this parameter and set it to true. However, be sure to run this command soon after the person returns because once the IDs are swapped, the user is not able to access any new content that she created using the new ID, just her previous content. You cannot merge the data associated with the current and new IDs. If you provide this parameter and set it to false, an error message is displayed in the wsadmin client that indicates that the command could not complete because the newExtId already exists.
      Example:

      CommunitiesMemberService.syncMemberByExtId("7d71d8b2-7de511df-80b6c81b-5330ca0e", 
       {"newExtId": "7d71d8b3-7de511df-80b6c81b-5330ca0e", "allowExtIdSwap": "true"})

    application_nameMemberService.inactivateMemberByEmail("email-address")

    This marks the person identified by email-address as inactive in the application's membership database tables, for example it changes the state of the specified user to inactive. In addition, the email address and login names for this user are removed from the application's database tables. The user's external ID and Display Name are not modified. The command also writes a status message to the application_nameUlcSyncCmd.log file indicating that the user has been deactivated.

    Parameter:

    email-address

    String. Email address of the user you want to mark as inactive in the application membership database tables.

    application_nameMemberService.inactivateMemberByExtId("externalID")

    This marks the person identified by external ID as inactive in the application's membership database tables. This command changes the state of the specified user to inactive. In addition, the email address and login names for this user are removed from the application's database tables. The user's external ID and Display Name are not modified. The command also writes a status message to the application_nameUlcSyncCmd.log file indicating that the user has been deactivated.

    Parameter:

    externalID

    String. Unique ID that represents the user you want to mark as inactive in the application membership database tables.

    application_nameMemberService.getMemberExtIdByEmail("email")

    This retrieves the external ID of the person identified in the email parameter and returns it to the wsadmin console. The external ID returned from this command can be used as input to some of the other wsadmin commands that require the user's external ID as an input parameter.

    Parameter:

    email

    String. Email address of the user whose external ID you want to retrieve.
    Example:

    • Command:

      wsadmin>CommunitiesMemberService.getMemberExtIdByEmail("userB@example.com")

    • Result:

      510b99c0-0101-102e-8923-f78755f7e0ed

    application_nameMemberService.getMemberExtIdByLogin("login")

    This retrieves the external ID of the person identified in the login parameter and returns it to the wsadmin console. The external ID returned from this command can be used as input to some of the other wsadmin commands that require the user's external ID as an input parameter.

    Parameter:

    login

    String. Login name of the user whose external ID you want to retrieve.
    Example:

    • Command:

      wsadmin>CommunitiesMemberService.getMemberExtIdByLogin("User A")

    • Result:

      806edb40-e8ba-102e-91cd-d74ea1c96b51


    Additional administrative commands

    The following commands were available in previous releases. Some have been updated to enable you to change the user state of a person from active to inactive or inactive to active. You might want to use these commands in the following cases:

    • To synchronize a batch of users from a file based on their login names and emails instead of external IDs.

    • To synchronize a particular user by login name or email, instead of by external ID.
    The application_name variable represents the name of the application. The following options are available:

    • Activities

    • Blogs

    • For Bookmarks, specify Dogear

    • Communities

    • Files

    • Forums

    • News repository: The Home page, News repository, and Search applications share the same database, so running the synchronization command against News repository applies to all three areas.

    • Profiles

    • Wikis

    The application_nameMemberService.syncAllMemberExtIds() command was deprecated in version 3.

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

    The command application_nameMemberService.syncBatchMemberExtIds(filename) was deprecated in version 2.5. Use this command or the syncBatchMemberExtIdsByLogin(loginFile) command instead.

    This synchronizes a list of users contained in the specified text file. The text file must define one email address per line. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's display name and any additional login names are refreshed if needed, so that they match those in the configured directory. The refresh operation is not logged.

    If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table is updated with the external ID in the configured directory. Also, the user's display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the following allowInactivate input parameter is set to true or false.

    Parameters:

    emailFile

    String. Path and name of text file that contains one entry per line of user email addresses (jdoe@example.com).

    allowInactivate

    String. Options are true or false. Specify one of these values to allow changes to the state of the user.

    If true, the user is inactivated in the member table of the application database if there is no match. The user's email and login names are deleted from the table and the state flag is set to inactive.

    If false or null, the user is not made inactive. Instead, a log message is written to the log file.

    For example:

    ActivitiesMemberService.syncBatchMemberExtIdsByEmail("c:/foo/bar/my_sync_file.txt", 
     { "allowInactivate":"true"})

    application_nameMemberService.previewSyncBatchMemberExtIdsByEmail("emailFile"[, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )

    See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.

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

    The command application_nameMemberService.syncBatchMemberExtIds(filename) was deprecated in version 2.5. Use this command or the application_nameMemberService.syncBatchMemberExtIdsByEmail(emailFile) command instead.

    This synchronizes a list of users contained in the specified text file. The text file must define one login name per line. For each login name, if a match is found the command checks the external ID in the application member table against the value in the configured directory to see if it matches. If the external ID matches, then the user's email address and display name and any additional login names are refreshed if needed so that they match those in the configured directory. The refresh operation is not logged.

    If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table in the application database is updated with the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false (see the following explanation of the two flags).

    Parameters:

    loginFile

    String. Path and name of a text file that contains one user login name entry per line.

    allowInactivate

    String. Options are true or false. Specify one of these values to allow changes to the state of the user.

    If true, the user is inactivated in the member table of the application database if there is no match. The user's email and login names are deleted from the table and the state flag is set to inactive.

    If false or null, the user is not made inactive. Instead, a log message is written to the log file.
    This command does not return anything.

    For example:

    ActivitiesMemberService.syncBatchMemberExtIdByLogin("c:/foo/bar/login_sync_file.txt", 
     { "allowInactivate":"false"})

    application_nameMemberService.previewSyncBatchMemberExtIdsByLogin("loginFile" [, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )

    See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.

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

    The command application_nameMemberService.syncMemberExtId(java.lang.String key) was deprecated in version 2.5. Use this command or the syncMemberExtIdByLogin(java.lang.String loginName) command instead.

    This synchronizes the member record in the application member table identified by the member's email address parameter. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's email address and display name and any additional login names are refreshed as needed so that they match those in the configured directory. The refresh operation is not logged.

    If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table is updated with the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false (see the following explanation of the two flags).

    Parameters:

    email

    String. A user's email address.

    allowInactivate

    String. Options are true or false. Specify one of these values to allow changes to the state of the user.

    If true, the user is inactivated in the member table of the application database if there is not match. The user's email and login names are deleted from the table and the state flag is set to inactive.

    If false or null, the user is not made inactive. Instead, a log message is written to the log file.

    For example:

    ActivitiesMemberService.syncMemberExtIdByEmail("jdoe@example.com", 
     {"allowInactivate":"false"})

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

    See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.

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

    The command application_nameMemberService.syncMemberExtId(java.lang.String key) was deprecated in version 2.5. Use this command or the application_nameMemberService.syncMemberExtIdByEmail(java.lang.String emailAddress) command instead.

    This synchronizes the member record in the application member table identified by the user login name parameter. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's email address and display name and any additional login names are updated so that they match those in the configured directory. The refresh operation is not logged.

    If the external ID is not found n the configured directory, then a synchronize operation is performed and the user's external ID in the member table is updated with that of the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false.

    Parameters:

    name

    String. User login name.

    allowInactivate

    String. Options are true or false. Specify one of these values to allow changes to the state of the user.

    If true, the user is inactivated in the member table of the application database if there is not match. The user's email and login names are deleted from the table and the state flag is set to inactive.

    If false or null, the user is not made inactive. Instead, a log message is written to the log file.

    For example:

    ActivitiesMemberService.syncMemberExtIdByLogin("jdoe", {"allowInactivate":"true"})

    To understand the .preview. version of the command see the explanation of preview under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.

    application_nameMemberService.previewSyncMemberExtIdByLogin("name"[, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ])

    See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.


    Related tasks

  • Synchronize remote application data with the Communities database
  • Use administrative commands
  • Manage user data using Profiles administrative commands
  • Manage Communities administrators - obsolete

  • Activities administrative commands
  • Communities administrative commands
  • Files administrative commands
  • Forums administrative commands
  • News administrative commands
  • Profiles administrative commands
  • Wikis administrative commands
  • Home page administrative commands


    Sample user management scenarios

    The following scenarios address some of the common tasks involved in managing user data within an organization.

    User management commands allow the administrator to push LDAP changes from Profiles to the other applications so that as data in Profiles is added and updated, these changes can be easily captured and propagated to the rest of IBM Connections. An extension hook to IBM Tivoli Directory Integrator is also provided, allowing administrators to add custom logic for determining if a user has left the system or has been affected by a human resources action that might prevent Tivoli Directory Integrator from being able to match their old employee record with their new employee record. Examples of such actions typically include users moving from part-time to full-time or transferring from one country to another.


    Related tasks

  • Manage user data using Profiles administrative commands
  • Customize the logic used for the delete operation


    Improve directory synchronization

    Use this procedure to help keep track of users as they transition from part-time to full-time or from one country to another and enable your IBM Tivoli Directory Integrator solution to handle actions that could otherwise lead to orphaned user data.

    To strengthen your Tivoli Directory Integrator (TDI) scripts, your organization must maintain data in the LDAP directory that allows you to connect the old employee record with the new employee record. Certain HR-related actions can result in orphaned user data by causing the value in the uid field in the LDAP directory to change. Tivoli Directory Integrator uses the uid field to synchronize data so any action that changes the value of the field will cause the user to appear as a completely new user to the Tivoli Directory Integrator scripts. Examples of HR actions that can have this effect include moving users from part-time to full-time or from one country to another country.

    To strengthen your Tivoli Directory Integrator solution, define and use a custom assembly line that specifies the delete logic to use to identify when a user needs to be deleted from the Profiles database.

    1. Configure your development environment for creating a delete logic script by following the steps in the topic, Set up your development environment.

    2. Define an assembly line that contains your delete logic in the file. Your assembly line must return one of the following values:

      • remove. Specifies that the current entry should be added to the delete list.

      • updated. Specifies that the current entry should be updated, not deleted.
      These values are case-sensitive.

      Return the value as follows:

      1. Retrieve the checkResult attribute field from the work object into your assembly line. The attribute name is case-sensitive.

      2. Set your checking result to the value of the checkResult attribute.
      For example:

      checkingResult = work.getAttribute("checkResult");
      checkingResult.setValue("updated");

      For more information about how to create an assembly line, go to the following web page:
      http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_7.0/CreatingyourfirstassemblyLine.htm

    3. Use the publish feature to export the assembly line as a Tivoli Directory Integrator adapter.

      1. Right-click the assembly line in the Navigator and select Publish.

      2. Enter the name of the adapter in the Package ID field.

      3. Set the following directory in the File Path field, and then click Finish.
        profiles_tdisoln/packages

    4. 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.

    5. Open the profiles_tdi.properties file from the following location:

      tdisol.tar|zip/tdisol/TDI

    6. Set the following properties in the file:

      sync_updates_double_check

      Specifies whether your checking assembly line is used. When set to true, your deletion-checking assembly line is used. When set to false, the checking operation is not performed. The default value is false.

      For example:

      sync_updates_double_check=true

      sync_check_if_remove

      Specifies the name of your checking assembly line:

      sync_check_if_remove=name_of_your_adapter_xml_file:/AssemblyLines/name_of_your_assemblyline
      By default, the assembly line's name is set to sync_all_dns_check_if_remove.

      For example, if you publish the assembly line with the file name deleteCheckRoutines and the assembly line is example_check_if_user_really_deleted, use the following statement to set this property:

      sync_check_if_remove=deleteCheckRoutines:/AssemblyLines/example_check_if_user_really_deleted

      sync_delete_or_inactivate

      Controls what happens to a user record when the delete action is performed. This property can be set to one of the following values:

      • delete. Specifies that the user record is deleted.

      • inactivate. Specifies that the user record is inactivated.

        The inactive status is propagated to the member and login tables for all the applications. An event is generated for each of the following: Activities, Blogs, Bookmarks, Communities, Files, Forums, Profiles, Wikis, and News (which includes both Home page and Search). These events inactivate the user in every application by removing the user from the login tables and setting the user's status to 1 in all member tables.

      These values are case-sensitive so type them with care. The default value is inactivate.

      For example:

      sync_delete_or_inactivate=inactivate

    7. Save your changes to the profiles_tdi.properties file.


    Related tasks

  • Set up your development environment


    Use the LDAP directory as the user directory

    Edit configuration property settings to disable IBM Connections directory service extensions.

    Be sure that you have configured the LDAP directory properly before you configure it to be the user directory. See Set up federated repositories for more details.

    IBM Connections directory service extensions are protocols that propagate Profiles data between the applications. When the directory service extension is enabled, you can use the Profiles database to store user information instead of having to access the LDAP directory for each request. If you install the Profiles application, the Profiles database is set up to be the user directory for IBM Connections by default. If you decide to use the LDAP directory as the user directory instead, you can disable the Profiles directory service extension.

    When you disable the Profiles directory service extension, LDAP services handle authentication, group membership search, and all user profiles queries except browser based searches requested within the Profiles application.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    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. Use the following command to disable the Profiles directory service extension:

      LCConfigService.updateConfig("profiles.directory.service.extension.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 common configuration property changes for information about how to save and apply your changes.


    Related tasks

  • Start the wsadmin client


    Use the Profiles database as the user directory

    Edit configuration property settings to enable IBM Connections directory service extensions.

    You only need to perform this task if you did not install the Profiles application initially and now want to install Profiles and set its database as the user directory for IBM Connections.

    IBM Connections directory service extensions are protocols that propagate Profiles data between the applications. When the directory service extension is enabled, you can use the Profiles database to store user information instead of having to access the LDAP directory for each request. If you install the Profiles application, the Profiles database is set up to be the user directory for IBM Connections by default.

    When you set the Profiles database to be the user directory, only authentication and group membership search requests are sent to LDAP; the Profiles directory handles all user profile search requests

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    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. Use the following command to enable the Profiles directory service extension:

      LCConfigService.updateConfig("profiles.directory.service.extension.enabled","true")

    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 common configuration property changes for information about how to save and apply your changes.


    What to do next

    Enable single sign-on between all the applications. For more information, see the Enabling single sign-on between all applications topic.


    Related tasks

  • Start the wsadmin client
  • Enable single sign-on between applications
  • Synchronize user data between Profiles and the LDAP directory
  • Edit configuration files
  • Add applications to the SSL trust store
  • Forcing users to log in before they can access an application
  • Apply common configuration property changes


    Groups

    In IBM Connections 4, content owners can use LDAP groups to control access to resources in the Communities, Activities, Files, and Wikis applications. For this reason, it is important to consider the effect that updating LDAP groups will have on the existing membership of these resources.

    For example, if a user is given access to content in IBM Connections via group membership and is then removed from that group, they might still receive email notifications and activity stream updates relating to that content until they log into the relevant application that contains the content. When the user logs in, the access controls are updated to reflect current group membership and any following subscriptions to content that is no longer accessible are removed at this time.

    For more information about how group access works in different applications, refer to the help for the Communities, Activities, Files, and Wikis applications.


    Related

  • Manage membership in Communities
  • Manage activity membership
  • Administer Files
  • Administer Wikis

    Customize the deployment

    Perform optional tasks to customize your IBM Connections deployment.


    Hide email addresses

    Run a script provided with the product to configure IBM Connections to prevent email addresses from being displayed in the product and protect the privacy of your users.

    Install all of the applications and test notifications to make sure that your mail servers are set up correctly before you configure the product to prevent email addresses from being displayed. Also, edit the notification-config.xml file to define a valid email address for the global administrator and alternate addresses for the different types of notifications sent by each application. See Defining valid administrator email address for more details.

    Do not configure IBM Connections to hide email addresses if you are using any of the IBM Connections extensions. The extensions, such as the IBM Connections Plug-in for Notes or IBM Connections Plug-in for Sametime, require addresses to be exposed because they rely on email addresses to identify users. See the Extending section of the product documentation for a list of available IBM Connections extensions. When you prevent emails from displaying, email addresses are hidden in the following places:

    • Members fields. When you begin to type a name into a name field, such as while adding members or creating a name field in an activity entry, a list of options is displayed. By default, this list is composed of email addresses. If you configure IBM Connections to hide email addresses, the list is composed of display names instead.

    • URLs. email addresses are often sent as parameters in URLs generated by actions that you can perform in the product. This setting prevents the email address from being used in URLs. A customer ID is used instead.

    • Notifications. Some actions that you perform in the product generate email notifications. For example, when you add members to an activity, they receive email notifications informing them about the activity. Other notifications are generated automatically by the server. For example, automatic notifications are sent to activity owners to warn them that an activity will be marked complete due to lack of use. When you indicate that you do not want to expose email addresses, all emails are shown to originate from the administrator email address defined for the application in the notification-config.xml file. In addition, the email addresses of the recipients are added to the blind carbon copy (BCC) field of the notification, which hides recipient email addresses from recipients.

    • Profiles business card. The email address that usually is displayed in business cards is not displayed nor is the Send Mail button.
    Note to programmers: If you configure IBM Connections to keep email addresses private, you cannot use the email parameter to represent a person in GET requests sent to retrieve Atom feeds. Instead, you must use the userid parameter. See Determining whether email addresses are hidden in the Developing section for more details.

    To hide email addresses, complete the following steps:

    1. Open a command prompt, and then change to the following directory on the WebSphere Application Server hosting the IBM Connections server:

      • AIX or Linux:

        /opt/IBM/Connections/ConfigEngine

      • Microsoft

        Windows:

        C:\IBM\Connections\ConfigEngine

    2. Enter the following command to run the script that configures IBM Connections to hide email addresses on the WebSphere Application Server profile to which you installed the applications. For a network deployment, run it on the system hosting the deployment manager, which is typically the first node.

      • AIX or Linux:

        ./ConfigEngine.sh action-hide-email > /tmp/hide_email.log 2>&1 

      • Microsoft

        Windows:

        ConfigEngine.bat action-hide-email > D:/hide_email.log 2>&1 
      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat action-hide-email > D:/hide_email.log 2>&1 

    3. You must perform some additional steps to remove email address references from user profiles. Follow the steps in the topic Configuring advanced search.

    4. Restart the server.


    Related

  • Integrate with other products

  • Define valid administrator email addresses
  • Configure Profiles directory search options
  • Enable single sign-on between applications
  • Change common configuration property values
  • Apply common configuration property changes


    Expose email addresses

    If you configured IBM Connections to prevent email addresses from being displayed, and later decide to allow email addresses to be exposed in the product, perform this procedure.

    Only perform this procedure if you configured IBM Connections to prevent email addresses from being displayed. See Hide email addresses for more details.

    1. Open a command prompt, and then change to the following directory on the WebSphere Application Server hosting IBM Connections:

      • AIX or Linux:

        /opt/IBM/Connections/ConfigEngine

      • Microsoft

        Windows:

        C:\IBM\Connections\ConfigEngine

    2. Enter the following command to run the script that configures IBM Connections to display email addresses on each WebSphere Application Server profile to which you installed an application:

      • AIX or Linux:

        ./ConfigEngine.sh action-expose-email > /tmp/expose_email.log 2>&1 

      • Microsoft

        Windows:

        ConfigEngine.bat action-expose-email > D:/expose_email.log 2>&1
      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat action-expose-email > D:/expose_email.log 2>&1

    3. You must perform some additional steps to add the email address references that were removed from user profiles. Follow the steps in the topic Configuring advanced search.

    4. Restart the servers.


    Related tasks

  • Change common configuration property values
  • Apply common configuration property changes
  • Enable single sign-on between applications
  • Configure Profiles directory search options


    Enable users to set a language preference

    By default, the IBM Connections user interface (UI) is displayed in the language identified in the locale settings of the web browser being used. You can set it up to allow users to explicitly select the language in which the product is displayed.

    Before you begin this procedure, determine which subset of supported languages you want to support. For a full list of the languages that are supported by IBM Connections, see Supported languages.

    After performing this procedure, users can select a language from the language selector in the product's menu bar.

    You can also use this configuration to force the user interface to be displayed in only a single language. For example, to display the user interface in French only, you can use the following settings: enabled=true, defaultLanguage=fr, and make sure that no language elements are defined. To enable users to set their language preference, 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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    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. Navigate to the working directory specified in the previous step and open LotusConnections-config.xml in a text editor.

    4. Find the <languageSelector> element, and then make the following changes:

      1. Change the value of the enabled attribute from false to true.

      2. By default, the defaultLanguage attribute is blank and the product user interface is displayed in the language specified as the preferred language by each user's web browser. You can use the defaultLanguage attribute to define a fallback language in which to display the user interface if the preferred language is not one that is supported by IBM Connections. The language that you specify here is displayed in the language selector in the product's navigation bar. Set the language using the exact strings listed in the following example.

        Use the language code iw to specify Hebrew.

      3. The default cookie name is lcLang. If you want to change it, specify a name in the cookieName attribute.

      4. No cookie domain is used by default, but you can specify a domain by adding the domain name of your deployment as the value of the cookieDomain attribute. The domain name must be a valid, fully qualified domain name of the server where the cookie resides. For example: .acme.com. Note that the domain name begins with a period (.). When you provide this value for the cookie domain property, you enable the language setting to work across multiple servers, such as both profiles.acme.com and activities.acme.com.

      5. By default, the cookie persists for the duration of the web browser session. To create a persistent cookie that has an expiry date of ten years from the date it was created, set the usePermanentCookie to true.

      6. Within the <languageSelector> element, add one <language> element for each language that you want users to be able to select from the language selector list in the product menu bar. Include a lang attribute that specifies the ISO country code associated with the language. Provide the language name as it should be displayed in the list as the value of the language element. Specify non-Latin characters in JavaScript-escaped unicode format. You can only specify languages that the product supports. For a list of languages, see Supported languages.

        Also, remove any of the language elements that are included in the languageSelector element by default if you do not want them to be displayed from the drop-down list of language options in the product menu bar. They are English, French, Chinese, and Arabic. For example:

        <languageSelector 
         enabled="true" 
         defaultLanguage="" 
         cookieName="conxnsCookie"
         cookieDomain=".acme.com" 
         usePermanentCookie="true">
          <language lang="en">English</language>
          <language lang="zh">\u4e2d\u6587\uff08\u7b80\u4f53\uff09</language>
          <language lang="zh_tw">\u4e2d\u6587 (\u7e41\u9ad4)</language>
          <language lang="ja">\u65e5\u672c\u8a9e</language>
          <language lang="ko">\ud55c\uad6d\uc5b4</language>
          <language lang="fr">Fran\u00e7ais</language>
          <language lang="de">Deutsch</language>
          <language lang="it">Italiano</language>
          <language lang="es">Espa\u00f1ol</language>
          <language lang="pt_br">Portugu\u00eas (Brasil)</language>
          <language lang="cs">\u010ce\u0161tina</language>
          <language lang="da">Dansk</language>
          <language lang="nl">Nederlands</language>
          <language lang="fi">suomi</language>
          <language lang="el">\u0395\u03bb\u03bb\u03b7\u03bd\u03b9\u03ba\u03ac</language>
          <language lang="hu">Magyar</language>
          <language lang="no">Norsk (Bokm\u00e5l)</language>
          <language lang="pl">polski</language>
          <language lang="pt">Portugu\u00eas (Portugal)</language>
          <language lang="ru">\u0420\u0443\u0441\u0441\u043a\u0438\u0439</language>
          <language lang="sl">sloven..ina</language>
          <language lang="sv">Svenska</language>
          <language lang="tr">T\u00fcrk\u00e7e</language>
          <language lang="iw">\u05e2\u05d1\u05e8\u05d9\u05ea</language>
          <language lang="ar">\u200f\u0627\u0644\u0639\u0631\u0628\u064a\u0629\u200f</language>
          <language lang="ca">Catal\u00e0</language>
          <language lang="kk">\u049a\u0430\u0437\u0430\u049b\u0448\u0430</language>
          <language lang="th">\u0e44\u0e17\u0e22</language>
        </languageSelector>
        The following table identifies the languages based on the lang property value:

        Table 58. Language code values

        Lang property value Language
        ar Arabic
        ca Catalan
        cs Czech
        da Danish
        de German
        en English
        el Greek
        es Spanish
        fi Finnish
        fr French
        hu Hungarian
        it Italian
        iw Hebrew
        ja Japanese
        kk Kazakh
        ko Korean
        nl Dutch
        no Norwegian
        pl Polish
        pt Portuguese
        pt_br Brazilian Portuguese
        ru Russian
        sl Slovenian
        sv Swedish
        th Thai
        tr Turkish
        zh Simplified Chinese
        zh_tw Traditional Chinese

    5. Save your changes to LotusConnections-config.xml.

    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 common configuration property changes for information about how to save and apply your changes.


    Related

  • Supported languages
  • Index settings

  • Start the wsadmin client
  • Apply common configuration property changes
  • Enable dictionaries
  • Enable users to specify email notification preferences


    Change application URLs

    Change the context root of URLs that point to IBM Connections applications.

    If you decide to change the context roots of the applications, do so before you map the applications to IBM HTTP Server or before you edit the IBM HTTP Server configuration file for any other reason,such as to redirect HTTP requests to support third-party authentication mechanisms.

    This is an optional task.

    The web address for an IBM Connections application contains a default context root value. After installing the application, you can change this value to a different context root to conform to corporate restrictions or to policies that limit

    ...where server applications can be deployed and how they can be addressed.

    For example, the Blogs application is available from your_host_server/blogs by default. You can change that base web address to your_host_server>/IBMConnectionsBlogs to differentiate it from any other available blogging service or to conform to corporate guidelines. To change the context root of an application:

    1. Log into the WebSphere Application Server Integration Solutions Console for the server hosting the IBM Connections application for which you want to change the context root.

    2. Expand Applications > Application Types, and then select WebSphere enterprise applications.

    3. Click the name of the server hosting the application with the context root to change, and then under Web Module Properties, click Context Root For Web Modules.

    4. Edit the values in the Context Root column of the table to change the term that identifies the application. The paths must continue to begin with a forward slash (/) and must not contain spaces.

      Do not specify a single forward slash (/) as the full context root because it prevents applications from being able to retrieve Atom feeds properly. Using the default application context ("/") is not supported.

    5. Click OK, and then click OK from the server properties page to save the change.

    6. 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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    7. Update the IBM Connections configuration file to reflect this context root change. 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")

    8. Update the value of the href prefix :

      LCConfigService.updateConfig("<web_module_name.href.prefix",
       "new_context_root_value")

      ...where:

      web_module_name

      Name of the web module for the application. Each application has one or more web modules that are configured in WebSphere Application Server. The options are the following:

      Table 59. Application web modules

      Application or Service name Web modules
      Activities activities
      Blogs blogs
      Communities communities
      Dogear dogear
      Files files
      Forums forums
      Home page homepage, news
      Metrics metrics
      Mobile mobile
      Moderation moderation
      Profiles personTag, profiles
      Search search
      Wikis wikis

      new_context_root_value

      Value you defined for the application's web UI context root in Step 4.

      Do not specify a single forward slash (/) as the full context root because it prevents applications from being able to retrieve Atom feeds properly.

      For example, to change the context root of the Profiles application, you would use the following commands:

      LCConfigService.updateConfig("profiles.href.prefix","/contacts")
      LCConfigService.updateConfig("personTag.href.prefix","/contacts")

    9. Save your changes to LotusConnections-config.xml.

    10. 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 common configuration property changes for information about how to save and apply your changes.

    11. Files and Wikis only: Perform the following steps:

      1. Check out the Files and Wikis configuration files. See the topic Changing configuration property values in the Administering Files and Administering Wikis sections of the product documentation.

      2. Locate the following property:

        <security>
           <logout href="/files/ibm_security_logout" />
        </security>

      3. Change it to this:

        <security>
           <logout href="new_context_root_value>/ibm_security_logout" />
        </security>

    12. Perform either of the following actions to update existing links to uploaded files:

      • Update the old links manually.

      • Redirect requests made to links that contain the old context root to links with the new one :

        You can only use this option if the old and new context roots are defined on the same IBM HTTP Server.

        1. Open the configuration file for the IBM HTTP Server. It is called httpd.conf and is located in the following directory:

          AIX: /usr/IBM/HTTPServer/conf

          Linux: /opt/IBM/HTTPServer/conf

          Microsoft

          Windows: C:\IBM\HTTPServer\conf

        2. Uncomment the following line or add it if it is not present:

          LoadModule rewrite_module modules/mod_rewrite.so

        3. Add redirection rules for each application for both HTTP and secure HTTP. The following XML is an example of redirection rules added for the Blogs application:

          Listen 0.0.0.0:443
          <VirtualHost  *:443>
          RewriteEngine on
          RewriteRule /blogs/(.*) https://<your_host_server>/LotusConnectionsBlogs/$1 [R,L]
          ServerName  <your_host_server>
          SSLEnable
          </VirtualHost>
          SSLDisable
          
          RewriteEngine on
          RewriteRule /blogs/(.*) http://<your_host_server>/LotusConnectionsBlogs/$1 [R,L]

        4. Save and close the httpd.conf file, and then restart the IBM HTTP Server.

    13. Regenerate the plugin-cfg.xml file for the IBM HTTP Server in the WebSphere Application Server Integrated Solutions Console. To do so:

      1. Open the WebSphere Application Server Integrated Solutions Console.

      2. Expand Servers > Server Types, and then select Web servers.

      3. Select the check box next to the IBM HTTP Server name. For example: webserver1.

      4. Click Generate Plug-in to regenerate the plugin-cfg.xml file.

      5. If necessary. click Propagate Plug-in to copy the plugin-cfg.xml file from the local directory where the Application Server is installed to the remote machine.

    14. Restart the IBM HTTP Server.

    15. Rebuild the search index by deleting the index and letting the indexing task recreate it when it runs. By default, the indexing task runs every 15 minutes. See Deleting the index for more information.

    16. Update any non-browser clients to point to the new URL. See the client documentation for required steps.

    17. Run the BlogsAdminService.fixBrokenUrls command to fix the absolute URLs used by embedded images and attachments in Blogs. See Replacing URLs in Blogs.

    18. If you have many users with bookmarks or email links to the original URL, consider creating a landing page for the old URL that redirects to the new URL.


    Related

  • Optional post-installation tasks

  • Start the wsadmin client
  • Apply common configuration property changes
  • Delete the index
  • Change Files configuration property values
  • Change Wikis configuration property values
  • Replace URLs in Blogs


    Add Sametime awareness though the Sametime client

    If you have an IBM Sametime 8.0.1 client or later and the Profiles application deployed, you can enable presence awareness in IBM Connections.

    This is an optional configuration.

    When you enable presence awareness in IBM Connections, a person's online status is indicated by a set of icons and an associated status message that is available from the person's profile and business card. Presence awareness tells you whether the person is available to chat, busy in a meeting, or away from their computer.

    You must have the following software enabled to be able to add presence awareness to IBM Connections:

    • IBM Sametime 8.5 or later stand-alone client.

      Alternatively, you can use Sametime embedded in Notes if the Notes client version is Notes 8.5 or later.

    • IBM Sametime 8.0.1 stand-alone client.

      Alternatively, you can use IBM Sametime embedded in Notes if the Notes client version is Notes 8.0.2 with Interim Application Release 1 (IFR1). When using Sametime 8.0.1, the following limitations apply:

      • Users defined in the Sametime directory must have the same email address as the users defined in the Profiles directory.

    • The Profiles application of IBM Connections must be deployed.

    SSL support: If you have configured the product to send traffic over SSL, presence awareness can be retrieved over SSL for the following Sametime clients:

    • IBM Sametime 8.5 or later standalone client

    • Notes 8.5.1 or later embedded client
    For more information about enabling SSL for Sametime, refer to the documentation provided with the Sametime SDK, which is available from the following web site: http://www.ibm.com/developerworks/lotus/downloads/toolkits.html

    After downloading the toolkit, the documentation can be found in the <sdk>/client/connectWebApi/doc/ConnectWebApiDevguide.pdf directory.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    2. Edit the profiles-config.xml file to indicate that you want to enable awareness. Start the wsadmin client. Use the following commands to access and check out 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. 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. From the temporary directory to which you checked out the configuration files, open the profiles-config.xml file in a text editor.

    4. Find the <sametimeAwareness> element, and then set the enabled attribute equal to true, specify web addresses for the href and ssl_href attributes, and specify which input type should be used for identifying the person: an email address or a user ID. For example:

      <sametimeAwareness 
       enabled="true" 
       href="http://localhost:59449/stwebapi"  
       ssl_href="http://localhost:59449/stwebapi" 
       sametimeInputType="email" />

      If IBM Connections is configured to hide email addresses, define the user ID as the input type by setting the sametimeInputType attribute equal to uid. For example:

      <sametimeAwareness 
       enabled="true" 
       href="http://localhost:59449/stwebapi"  
       ssl_href="http://localhost:59449/stwebapi" 
       sametimeInputType="uid" />

    5. Sametime 8.5 stand-alone and Notes 8.5.1 embedded client only: If you have configured the product to send traffic over SSL, edit the ssl_href attribute to specify the web address with the HTTPS protocol. For example:

      <sametimeAwareness 
       enabled="true" 
       href="http://localhost:59449/stwebapi"  
       ssl_href="https://localhost:59669/stwebapi" 
       sametimeInputType="email" />
      Do not make this change for releases earlier than Sametime 8.5 or the Notes 8.5.1 embedded client or awareness will stop working properly.

    6. Save and close the profiles-config.xml file.

    7. Check in the changed configuration files using the following wsadmin client command:

      ProfilesConfigService.checkInConfig()

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

    9. If you are using a Sametime client that is embedded in a version of Notes later than 8.0.2 (IFR1), configure Notes to display awareness information because it is disabled by default. To do so:

      1. Exit the Notes client.

      2. Open the plugin_customization.ini file in a text editor.

        By default, the plugin_customization.ini file is stored in the following directory:

        C:\notes\framework\rcp

      3. Search for the com.ibm.collaboration.realtime.webapi/startwebContainer property. If it is set to false, set it equal to true. If you do not find it, add the property using the follow syntax:

        com.ibm.collaboration.realtime.webapi/startwebContainer=true

      4. Save and close the plugin_customization.ini file.

    10. Stop and restart the WebSphere Application Server hosting the Profiles application.

    11. Start the stand-alone Sametime client or Notes client in which Sametime is embedded.

      It is not recommended that you run more than one Sametime client on a single machine at one time. If awareness does not seem to be enabled in IBM Connections, make sure you do not have an earlier version of the Sametime client running on your machine. If you do, stop the clients and be sure to restart the Sametime Connect 8.0.1 client or the Sametime client embedded in Notes 8.0.2 (IFR1) or later before restarting any other clients.

    12. Confirm that this procedure worked by accessing one of the IBM Connections applications, and then opening a person's business card. It may take a few seconds for the person's presence information to display the first time.


    Related tasks

  • Start the wsadmin client

  • Common configuration properties


    Add Sametime awareness through the Sametime server

    If you have an IBM Sametime Proxy server configured in your enterprise and have the Profiles application deployed, you can enable presence awareness and simple chats in IBM Connections.

    This is an optional configuration.

    You must have the following software enabled to be able to add presence awareness to IBM Connections:

    Complete the following procedures before attempting to enable awareness.

    When you enable presence awareness using the Sametime Proxy server, a person's online status is indicated by a set of icons and an associated status message that is available from the person's profile and business card. Presence awareness tells you whether the person is available to chat, busy in a meeting, or away from their computer. In addition to seeing a person's availability, you can carry on a chat with that person even when no Sametime client is installed.

    SSL support: If you have configured the product to send traffic over SSL, presence awareness can be retrieved over SSL. For more information about enabling SSL for Sametime, refer to the documentation provided with the Sametime SDK, which is available from the following web site: http://www.ibm.com/developerworks/lotus/downloads/toolkits.html

    After downloading the toolkit, the documentation can be found in the sdk/client/connectWebApi/doc/ConnectWebApiDevguide.pdf directory.

    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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    2. Use the wsadmin client to access and check out the IBM Connections extension 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 LotusConnections-config (LCC.xml) file:

        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.checkOutLcConfig("/opt/temp","foo01Cell01")

        • Microsoft

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

    3. From the directory you specified as the working directory in the previous step, open the LCC.xml file in a text editor, and then find the sametimeProxy service section:

      <sloc:serviceReference enabled="false" isConnectClient="false" serviceName="sametimeProxy" ssl_enabled="false">
      <sloc:href>
      <sloc:hrefPathPrefix/>
      <sloc:static href="admin_replace" ssl_href="admin_replace"/>
      <sloc:interService href="admin_replace"/>
      </sloc:href>
      </sloc:serviceReference>

    4. Set the attributes according to the following example:

      <sloc:serviceReference enabled="true" isConnectClient="true" serviceName="sametimeProxy" ssl_enabled="true"><sloc:href><sloc:hrefPathPrefix/>
      <sloc:static href="http://sametimeProxyServer.enterprise.example.com" ssl_href="https://sametimeProxyServer.enterprise.example.com:9444"/>
      <sloc:interService href="https://sametimeProxyServer.enterprise.example.com:9444"/>
      </sloc:href>
      </sloc:serviceReference>
      Where:

      • sloc:serviceReference enabled="true" displays the Sametime action bar in Connections and connects to Sametime via the specified Sametime Proxy server.

      • ssl_enabled="true" connects to the Sametime proxy server on the secure port.

      • isConnectClient="true" automatically connects to Sametime via the UIM client, rather than the Sametime Proxy server.

    5. Scan your LCC.xml file for any third party applications that are enabled in your environment. If the third party application is not configured to the reverse proxy, add 'isExternal' attribute to the service as shown in following example:

      <sloc:serviceReference enabled="true" serviceName="sametimeProxy" ssl_enabled="true" isConnectClient="true"><sloc:href> <sloc:hrefPathPrefix/> 
      <sloc:static href="http://sametimeProxyServer.enterprise.example.com" ssl_href="https://sametimeProxyServer.enterprise.example.com:9444" isExternal="true"/> 
      <sloc:interService href="https://sametimeProxyServer.enterprise.example.com:9444"/> 
      </sloc:href> '
      </sloc:serviceReference>

    6. Save and close the LCC.xml file.

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

      LCConfigService.checkInLcConfig(working_directory,cell_name)

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

      synchAllNodes()

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

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

    11. Confirm that this procedure worked by accessing one of the IBM Connections applications, and then opening a person's business card. It may take a few seconds for the person's presence information to display the first time. If you can start a chat with the person, then enabling awareness through the proxy server was successfully completed.


    Disable an application

    You might decide to disable an application temporarily for maintenance or if, for example, you are deploying the product and this application is not yet ready for use.

    Only perform this task if you want to disable an application temporarily.

    Do not disable applications that are used by all of the other applications, such as the News or Search applications.

    1. Open the Integrated Solutions Console of the WebSphere Application Server that is hosting the application.

    2. Expand Applications > Application Types, and then select WebSphere enterprise applications.

    3. Click the name of the application to disable.

    4. Click Target specific application status.

    5. Select the check box next to the cluster name, and then click Disable Auto Start.

    6. Click Save to save your changes.

    7. Click Apply, and then click OK.

    8. 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

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

    9. Remove the link to the application from the navigation bar by editing the IBM Connections configuration file.

      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")

    10. To see a list of the properties and their current settings, use the following command:

      LCConfigService.showConfig()

    11. Enter the following commands:

      LCConfigService.updateConfig("application_name.enabled", "false")
      LCConfigService.updateConfig("application_name.ssl.enabled", 
       "false")

      ...where application_name is the name of the application that you are disabling.

    12. 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 common configuration property changes for information about how to save and apply your changes.

    13. Stop the WebSphere Application Server clusters, and then restart the WebSphere Application Server clusters.


    Related tasks

  • Start the wsadmin client
  • Apply common configuration property changes
  • Change common configuration property values


    Disable microblogging

    You can remove microblogging functionality from your deployment by disabling the microblogging service reference in LotusConnections-config.xml. Microblogging is enabled by default in IBM Connections.

    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. Disable the microblogging service in LotusConnections-config.xml automatically removes all the features provided by the service. The options that enable users to post status updates are removed from the product user interface, and the indexing process associated with the microblogging service is also disabled.

    When you disable microblogging:

    • Users cannot post status updates in IBM Connections

    • Users cannot post messages to other users' profiles or to communities

    • Status updates cannot be searched from the Search user interface

    Existing status updates are not removed from the user interface, and are still visible in the Home page, Profiles, and Communities applications.

    To disable microblogging in your deployment, complete the following steps.

    1. 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")

    2. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values : LCConfigService.showConfig()

    3. To disable microblogging capabilities across IBM Connections, enter the following command:

      LCConfigService.updateConfig("microblogging.enabled","false")


    What to do next

    Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.


    Related

  • Administer microblogs

  • Apply common configuration property changes


    Disable the social analytics service

    The social analytics widgets help users to discover how they are connected to other users and content, and suggest network contacts and content that might interest them. The social analytics service is enabled by default.

    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. Disable the social analytics service automatically removes all the features provided by the service, including the social analytics widgets that are available in Profiles, Communities, and the Home page. The indexing process associated with the social analytics service is also disabled.

    When you disable the social analytics service, the following widgets are removed from the user interface:

    • Do You Know (Profiles)

    • Recommendations (Communities)

    • Recommendations (Home page)

    • Who Connects Us? (Profiles)

    • Things in Common

    You disable the social analytics service by using wsadmin commands to set the sand.enabled and sand.ssl.enabled properties in LotusConnections-config.xml to false. For more information about changing common configuration properties, see Changing common configuration property values.

    <sloc:serviceReference serviceName="sand" 
            enabled="false"
            ssl_enabled="false">
            <sloc:href>
                <sloc:hrefPathPrefix>/news/common/sand</sloc:hrefPathPrefix>
            <sloc:static href="admin_replace" ssl_href="admin_replace"/>
            </sloc:href>
        </sloc:serviceReference>

    To disable the social analytics service, complete the following steps.

    1. 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")

    2. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values : LCConfigService.showConfig()

    3. To disable the social analytic service, enter the following commands:

      LCConfigService.updateConfig("sand.enabled","false")
      LCConfigService.updateConfig("sand.ssl.enabled","false")


    What to do next

    Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.


    Related

  • Social analytics widgets

  • Excluding specific users from the social analytics service
  • Change common configuration property values
  • Apply common configuration property changes

  • Common configuration properties


    Add or remove sections from the help system's table of contents

    If you installed a subset of the IBM Connections applications, remove the help files associated with the applications that you did not install from the help table of contents. If you add an application, or install IBM Connections Mail, you can add that product's help to the table of contents.

    This procedure is not required. The help system enables users to navigate from the help for one application to another application by providing a table of contents that lists each application as a separate section and includes help topics within the section. However, if you choose to install only a subset of the available applications, manually remove the other help sections from the help system table of contents after installing the product or users see help for applications to which they do not have access. You can also add help if you add an application.

    1. Start the wsadmin client from the following directory of the system where you installed the deployment manager:

      app_server_root\profiles\dm_profile_root\bin

      You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.

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

      execfile("connectionsConfig.py")

    3. Enter the following command to specify which applications you want to include in the help system's table of contents:

      If you want to add an extra application to the existing help, you still need to list all the applications for which you are already providing help. Only the help files for applications that you list as parameters in the LCConfifigHelp.setHelp command will appear in the table of contents.

      LCConfigHelp.setHelp("temp_directory","application_name","application_name")

      ...where:

      • temp_directory is the name of a temporary directory on your system. The directory you specify can be any directory, but it must exist before you enter the command. When you enter the command, an XML file called helpData.xml is added to this directory and is used by the command.

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

      • application_name is the name of the application whose help section you want to include in the table of contents. List each application name separated by commas. The options are:

        • activities

        • blogs

        • bookmarks

        • communities

        • files

        • forums

        • homepage

        • profiles

        • wikis

        • icmail
      For example, if you installed all the applications except Wikis and Connections Mail, you can run the following command to include all sections but Wikis and Connections Mail in the help system:

      LCConfigHelp.setHelp("c:/temp","activities","blogs","bookmarks","communities","files","forums","homepage","profiles")

    4. To force the table of contents in the help system to reflect the change, stop the help application, and delete the temporary help directory on each node where help runs.

      For example, delete the following directory:
      C:\IBM\WebSphere\AppServer\profiles\AppSrv01\temp\node-name\cluster-name\Help.

      This directory is recreated when the application restarts.


    Results

    When a user opens the product help system, the table of contents lists only those sections that you wanted it to include.

    If a help topic links to a topic in a section that you have removed from the help system, the link text continues to be displayed, but returns an error when clicked.


    Related tasks

  • Start the wsadmin client

    Administer Activities

    Configure Activities to best meet the needs of your environment.

    For example, if you have limited disk space, you can specify smaller maximum file upload sizes or decrease the interval of time after which unused activities are marked complete. If you want to gauge how many people are using the product and to what extent, you can collect statistics and retrieve metrics on usage. You can also perform tasks such as synchronizing members IDs between the Activities database and the LDAP server and enabling virus scanning.

  • Activities error messages

    Change Activities configuration property values

    Configuration settings control how and when various Activities operations take place. You can edit the settings to change the ways that activities behave. Configure Activities using scripts accessed with the wsadmin client. These scripts use the AdminConfig object available in WebSphere Application Server wsadmin client to interact with the Activities configuration file. Changes to Activities configuration settings require node synchronization and a restart of the Activities server before they take effect.


    Related tasks

  • Start the wsadmin client
  • Apply common configuration property changes


    Check out the Activities configuration files

    You can edit the Activities configuration files in two ways: by using the wsadmin client or by editing the configuration XML files directly. In both cases, you must first check out the configuration files and later check them back in using the wsadmin client.

    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. Access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    3. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values :

      ActivitiesConfigService.showConfig()

    4. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly. To change an Activities configuration setting, do one of the following command:

      • To edit a property using the wsadmin client, use the following command:

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

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

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

      • 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.


    What to do next

    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 details.


    Activities configuration properties

    Edit Activities configuration properties to change the default behavior of the activities created by your users.

    The following list identifies the Activities configuration properties that you can edit.

    activeContentFilter.enabled

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

    This property accepts the following String values: true or false.

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

    jobs.30MinStats.enabled

    Specifies whether to run the job that saves statistics for Activities to disk every 30 minutes. This property accepts the following String values: true or false.

    jobs.30MinStats.interval

    Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*

    jobs.AutoComplete.autoCompletionPeriod

    Determines the time period in days that an activity must be inactive before it is automatically completed. This property accepts a number value specified as a String.

    jobs.AutoComplete.enabled

    Specifies whether or not to run the job that automatically completes inactive activities. This property accepts the following String values: true or false.

    jobs.AutoComplete.interval

    Determines the frequency with which to run the job that automatically completes inactive activities. This property accepts a chronological expression specified as a String.*

    jobs.AutoComplete.prenotification

    Specifies whether an activity owner is notified before an inactive activity is automatically completed. This property accepts the following String values: true or false.

    jobs.DailyStats.enabled

    Specifies whether to run the job that saves statistics for Activities to disk daily. This property accepts the following String values: true or false.

    jobs.DailyStats.interval

    Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*

    jobs.DatabaseRuntimeStats.enabled

    Specifies whether to run the job that periodically collects database statistics for Activities. This property accepts the following String values: true or false.

    jobs.DatabaseRuntimeStats.interval

    Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*

    jobs.TrashAutoPurge.daysRetention

    Determines the number of days that data must have been deleted for before being purged from the system. This property accepts an number value specified as a String.

    jobs.TrashAutoPurge.enabled

    Specifies whether or not to run the job that permanently removes content from the Activities trash. This property accepts the following String values: true or false.

    jobs.TrashAutoPurge.interval

    Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*

    objectStore.id

    This property cannot be modified by the Administrator using the ActivitiesConfigService.updateConfig command. It is configured initially during installation, and its value is displayed using the ActivitiesConfigService.showConfig command.

    This property displays a String value of filesystem which cannot be changed.

    objectStore.maxConcurrentDownloads

    Determines the number of threads that are simultaneously dedicated to servicing file download requests in the Activities server.

    This property accepts a number value specified as a String.

    *For information on how to format the value of an interval attribute, see Scheduling tasks.


    Related

  • Securing applications from malicious attack
  • Schedule tasks

  • Start the wsadmin client
  • Apply common configuration property changes
  • IBM Connections configuration property values


    Apply property changes in Activities

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

    You must perform the check in during the same wsadmin session in which you checked out the files for the changes that you made to take effect.

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

      ActivitiesConfigService.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 Activities application.


    Related tasks

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


    Change the save frequency of entries

    Edit configuration property settings to change how frequently work in activity entries is automatically saved.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    As users create or edit entries, their work is automatically saved every 5 minutes, unless you change the interval. If users leave an entry in an unsaved state when they accidentally close their browser, the next time they log in, a notification appears in the My Activities view reminding them that they have an unsaved entry. Autosave is not meant for backing up. This feature is provided to help you recover from unexpected events.

    To change how frequently their work is automatically saved

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. From the temporary directory to which you just checked out the oa-config.xml file, open the file in a text editor.

    3. Edit the elements in the file to set how frequently entries are automatically saved. The save interval is in minutes.

      <Autosave interval="5"/>

      Delete this element does not turn off the autosave feature. If you delete the element, entries are saved at the default interval of 5 minutes.

    4. Save and close the oa-config.xml file.

    5. After editing, check the configuration files back in. You must do so during the same wsadmin session in which you checked them out for the changes to take effect. You must also restart the server. See Applying property changes for details.

    6. After restarting the Activities server, review the WebSphere Application Server SystemOut.log file to ensure that the Activities application was able to initialize with the modified configuration.

    Run Activities administrative commands

    Use administrative commands to perform tasks that manipulate Activities content.

    Administrative commands interact with the Activities application and its resources through scripts. These scripts use the AdminControl object available in WebSphere Application Server wsadmin tool to interact with the Activities server. Each script uses managed Java beans (MBeans) to get and set server administration properties.

    Unlike with configuration properties, when you use these commands to change server administration properties, you do not have to check out any files nor restart the server for the changes to take effect. You do, however, need to understand a bit about how to manipulate Java objects. When you perform server operations using the commands, the activities, member information, and access level information are represented as hash tables. Many of the commands, in fact, return a vector of hash tables that represent Activities resources. Commands you can use to perform tasks, such as deleting, archiving, and restoring activities, all take parameters formatted as vectors of hash tables. See Narrow down results for some tips on how to retrieve a distinct set of activities or other resources that you can then pass to commands that perform server tasks.

    When an administrative command is invoked, a SOAP request is made to the Activities application. The number of seconds that the wsadmin client waits for a response to a SOAP request is specified in the com.ibm.SOAP.requestTimeout property specified in the soap.client.props file in the following directory: {WAS_HOME}\profiles\{PROFILE_NAME}\properties. If an Activities command takes longer to complete than the value of the com.ibm.SOAP.requestTimeout property, an error is displayed on the wsadmin console, and any value returned from the invoked method is lost. The Activities command continues to be processed by the Activities application, but the connection that the Activities application had to the client that invoked it is gone. This detail is important to note because some Activities commands take a long time to run. For example, in a system with a large number of Activities, the ActivityService.fetchActivities() command can take a long time to complete. You can monitor the status of these operations by scanning the SystemOut.log file for success and failure messages.

    To increase the time interval that passes before a request fails, edit the com.ibm.SOAP.requestTimeout property in the soap.client.props file. This property is a configuration property, so after editing the property, you must restart the server for the change to take effect.


    Related tasks

  • Narrow down results


    Activities administrative commands

    Use administrative commands to run administrative tasks on the server.

    The following sections define the administrative commands that you can use when working with Activities. Each section describes the commands for a specific service. The MemberService and ActivityService commands are described in the first two sections because they are the most commonly used services. The remaining sections describe the remaining services in alphabetic order.


    ActivitiesMemberService

    • The ActivitiesMemberService is the same as the MemberService. MemberService was deprecated in version 2.5.

    • The ActivitiesMemberService.updateMemberExtId(java.lang.String oldId, java.lang.String newId) command was deprecated in version 2.5.

    • The ActivitiesMemberService.syncAllMemberExtIds() and ActivitiesMemberService.updateMember(java.util.Hashtable pb) commands were deprecated in version 3.

    ActivitiesMemberService.fetchCommunitiesByName (java.lang.String name)

    Returns a list of communities with names that begin with the specified string. Return a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one community.

    Parameters:

    name

    The name of a community. You can provide the first word or words and any communities with names that begin with that word or words is returned. For example, "Sales community".

    This command was added in version 2.5.

    ActivitiesMemberService.fetchMemberByEmail(java.lang.String mail)

    Returns a member identified by the supplied email address. Return a java.util.Hashtable object that describes the member.

    Parameters:

    mail

    A member's email address specified as a String value. For example, "paul_smith@example.com".

    ActivitiesMemberService.fetchMemberById(java.lang.String id)

    Returns a member identified by the supplied Activities ID. The member can be either an individual user or a group. The returned value is a java.util.Hashtable object that describes the member.

    Parameters:

    id

    The member's unique ID as issued by the Activities application. Set the ID as a String value. For example, "ACF1093191092345B4DB336C9B5BF9000055".

    ActivitiesMemberService.fetchMemberByLogin(java.lang.String name)

    Returns a member whose login name is an exact match of the supplied login name. The returned value is a java.util.Hashtable object that describes the member. This command does not return groups.

    Parameters:

    name

    The login name specified as a String value. For example, "Paul Smith".

    ActivitiesMemberService.fetchMemberByName(java.lang.String name)

    Returns a member whose name is an exact match of the supplied name. Return both users and groups. The returned value is a java.util.Hashtable object that describes the member.

    Parameters:

    name

    The member or group name specified as a String value. For example, "Paul Smith".

    ActivitiesMemberService.fetchMembers(java.lang.String filter)

    Returns a set of members whose names match the string you specify. Each member can be either an individual user or a group. The set is returned as a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one member.

    Parameters:

    filter

    Search query string; indicate a wildcard using an asterisk (*). The string is case insensitive.

    For example, the following command returns any user or group whose name ends with "Smith":

    ActivitiesMemberService.fetchMembers("*Smith")

    ActivitiesMemberService.getMemberExtIdByEmail("email")

    See Synchronizing user data using administrative commands for information about this command.

    ActivitiesMemberService.getMemberExtIdByLogin("login")

    See Synchronizing user data using administrative commands for information about this command.

    ActivitiesMemberService.inactivateMemberByEmail("email")

    See Synchronizing user data using administrative commands for information about this command.

    ActivitiesMemberService.inactivateMemberByExtId("externalID")

    See Synchronizing user data using administrative commands for information about this command.

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

    See Synchronizing user data using administrative commands for information about this command.

    ActivitiesMemberService.syncAllMemberExtIds()

    This command was deprecated in version 3. See Synchronizing user data using administrative commands for information about the new and updated synchronization commands you can use instead.

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

    See Synchronizing user data using administrative commands for information about this command.

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

    See Synchronizing user data using administrative commands for information about this command.

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

    See Synchronizing user data using administrative commands for information about this command.

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

    See Synchronizing user data using administrative commands for information about this command.

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

    See Synchronizing user data using administrative commands for information about this command.


    ActivityService

    ActivityService.deleteActivities (java.util.Vector activities)

    Moves the specified activities to the Trash view. Activities 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 one activity that could not be deleted. A returned empty vector indicates complete success.

    Parameters:

    activities

    Vector of hash tables describing the activities to be deleted. For example, joesactivities.

    ActivityService.exportSyncedResourceInfo (filePath,eventType)

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

    Parameters:

    filePath

    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/activity_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: ActivityService.exportSyncedResourceInfo("C:/temp/activity_output.xml","community")

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

    ActivityService.fetchActivities()

    Gets a list of all the activities, except those that are in the Trash view.

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

    ActivityService.fetchActivitiesByCommunityExId (java.lang.String communityUUID)

    Gets a list of the community activities associated with a specific community. Returns a java.util.Vector; each object in the vector is a java.util.Hashtable that describes a community activity.

    Parameters:

    communityUUID

    The unique ID of the community. For example, "f29b4e8e-6fad-44f4-9fca-58c46f29c38d". To find out the unique ID of a community, use ActivitiesMemberService.fetchCommunitiesByName to retrieve the community of interest, and then get the value of the externalId key of that community from the hashtable.

    This command was added in version 2.5.

    ActivityService.fetchActivitiesByDate(java.lang.String dateType, java.lang.String beginTime, java.lang.String endTime, java.lang.String lastUUID)

    Gets a list of activities that were created or modified between a date range. The maximum number of activities in the returned list is 50. To obtain all of the activities that match the criteria if the number is greater than 50, call this method in a loop providing the UUID of the 50th activity 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 activity.

    Parameters:

    dateType

    Date field of interest. Options are created and modified.

    beginTime

    Start timestamp of the range, using a yyyy.mm.dd format.

    endTime

    Finish timestamp of the range, using a yyyy.mm.dd format.

    lastUUID

    Unique ID of the last activity retrieved from a previous call of this command. Specify empty double quotes if you expect less than 50 activities in the response, or if you are running this command for the first time.

    For example, the following command gets the first set of 50 activities that were created from 1 Mach 2008 through 31 March 2008:

    ActivityService.fetchActivitiesByDate("created","2008.03.01","2008.03.31","")

    This command does not return activity templates that were created during the specified date range. This command does include in the activities that it returns any activities present in the Trash view that were created during the specified date range.

    ActivityService.fetchActivityById(java.lang.String activityId)

    Gets the activity identified by the given universal identifier. Returns a java.util.Hashtable object that describes the activity.

    Parameters:

    activityId

    Unique identifier of the activity. For example, "3F9G09219392F4733F40F82A4E8D5F000083".

    ActivityService.fetchActivitiesByMember(java.util.Hashtable member)

    Gets a list of activities to which the specified member has access, except those that are in the Trash view. This command does not return community activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity. It does not provide any results if the specified member is a group or a community.

    Parameters:

    member

    java.util.Hashtable object representing the member returned from the MemberService object. For example, jane.

    ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)

    Gets a list of activities that are owned by the specified member, except those that are in the Trash view. This command does not return community activities either. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity.

    Parameters:

    member

    java.util.Hashtable object representing the owner returned from the MemberService object. For example, paul_smith.

    ActivityService.fetchActivitiesCreatedByMember(java.util.Hashtable member)

    Gets a list of activities that were created by the specified member, except those that are in the Trash view. This command does not return community activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity.

    Parameters:

    member

    java.util.Hashtable object representing the member returned from the MemberService object. For example, paul_smith.

    ActivityService.fetchCompletedActivities()

    Gets a list of all completed activities in the service, which are activities that have been marked complete and are displayed in the Completed view. Completed activities are not included in the Trash view; it is not until a completed activity is deleted that it is moved to the Trash view.

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

    ActivityService.fetchDeletedActivities()

    Gets a list of all deleted activities in the service. These are activities that are currently in the Trash view.

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


    AccessControlService

    You cannot use the AccessControlService commands to fetch, set, or delete access to community activities. See Communities administrative commands for information about the command you can use to add a person to a community.

    AccessControlService.deleteAccess(java.util.Vector activities, java.util.Vector members)

    Removes access privileges to the specified activities for the specified members. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be deleted. A returned empty vector indicates success.

    Parameters:

    activities

    Vector of hash tables representing the activities whose access will be modified. For example, joesactivities.

    members

    Vector of hash tables representing the members returned from the MemberService object.

    AccessControlService.fetchAccess(java.util.Hashtable activity)

    Gets a list of all of the members that have access to the specified activity. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one entry, either a user or group, in the access list. The elements returned in the Hashable are:

    • displayName

    • email: Returns for members only, not groups.

    • externalId

    • loginNames: Returns for members only, not groups.

    • memberId

    • memberType

    • role

    • staticProfile

    Parameters:

    activity

    Hash table representing the activity.
    The following code is an example of what is returned by this command:

    [{memberId=675G09219107D9BB025252223E2BC9000001, displayName=Amy Jones, loginNames=[Amy Jones, ajones@acme.com], staticProfile=false, externalId=3AB586F4-A4D2-43C8-92DB-2DC3B2291803, email=ajones@acme.com, memberType=person, role=owner}, {memberId=D76G0921910768409A3F871F14596C000088, displayName=Amy Jacobs, loginNames=[Amy Jacobs, ajacobs@acme.com], staticProfile=false, externalId=DE1D832B-1024-43B1-A12C-F1B643C2B6A2, email=ajacobs@acme.com, memberType=person, role=reader}, {memberId=812G09219107D9BB025252223E2BC900000A, displayName=ajonesgroup, staticProfile=false, externalId=41565591-1A33-4F9B-88D9-335D96BFB3B2, memberType=group, role=reader}]

    AccessControlService.setMembersAccess(java.util.Vector activities, java.util.Vector members)

    Sets the specified members as members with author access to the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

    Parameters:

    activities

    Vector of hash tables representing the activities whose access will be modified.

    members

    Vector of hash tables representing the members returned from the MemberService object.

    In 2.5, this command named changed from setMemberAccess to setMembersAccess.

    AccessControlService.setOwnerAccess(java.util.Vector activities, java.util.Hashtable owner)

    Sets the specified member as an owner of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

    Parameters:

    activities

    Vector of hash tables representing the activities whose access will be modified.

    owner

    Hash table representing the member returned from the MemberService object.

    AccessControlService.setOwnersAccess(java.util.Vector activities, java.util.Vector owners)

    Sets the specified members as owners of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

    Parameters:

    activities

    Vector of hash tables representing the activities whose access will be modified.

    owners

    Vector of hash tables representing the members to whom you want to give owner access.

    This command was added in version 2.5.

    AccessControlService.setReadersAccess(java.util.Vector activities, java.util.Vector members)

    Sets the specified members as readers of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

    Parameters:

    activities

    Vector of hash tables representing the activities whose access will be modified.

    members

    Vector of hash tables representing the members returned from the MemberService object.

    In 2.5, this command named changed from setReaderAccess to setReadersAccess.

    AccessControlService.syncAllCommunityShares()

    Updates the Activities data store to reflect changes made to the name or access level of a community. If the community no longer exists, the membership of the activity is updated to remove the community.

    This command was added in version 3.


    ActivitiesConfigService

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

    Checks Activities configuration files out to a temporary directory.

    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. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".

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

    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:

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

    • Microsoft

      Windows:

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

    ActivitiesConfigService.showConfig()

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

    ActivitiesConfigService.updateConfig("property_name", "new_value")

    Updates configuration properties.

    property_name

    See Activities configuration properties for configuration properties and descriptions.

    new_value

    The new value for the property. Acceptable values for properties can be restricted, for example to either true or false. See Activities configuration properties for configuration properties and descriptions.

    ActivitiesConfigService.checkInConfig()

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


    ActivitiesScheduler

    ActivitiesScheduler.getTaskDetails(java.lang.String taskName)

    Gets the list attributes of the named task. Returns a java.util.Hashtable object that contains the attributes.

    Parameters:

    taskName

    Name of the task specified as a String value. For example:

    • "30MinStats"

    • "ActivityAutoCompleteJob"

    • "DailyStats"

    • "DatabaseRuntimeStats"

    • "TrashAutoPurgeJob"

    ActivitiesScheduler.pauseSchedulingTask(java.lang.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

    Name of the task specified as a String value. For example:

    • "30MinStats"

    • "ActivityAutoCompleteJob"

    • "DailyStats"

    • "DatabaseRuntimeStats"

    • "TrashAutoPurgeJob"

    ActivitiesScheduler.resumeSchedulingTask(java.lang.String taskName)

    Resumes the start of a paused task. Returns a 1 to indicate that the task has been resumed.

    Parameters:

    taskName

    Name of the task specified as a String value. For example:

    • "30MinStats"

    • "ActivityAutoCompleteJob"

    • "DailyStats"

    • "DatabaseRuntimeStats"

    • "TrashAutoPurgeJob"


    ArchiveService

    ArchiveService.createActivities(java.lang.String directory, java.util.Vector activities)

    Creates new activities from the previously exported activities specified by the vector. If an activity being imported with this command already exists, a second activity is created. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be created. A returned empty Vector indicates success.

    Parameters:

    directory

    Directory on the file system from which to import the activities. For example, "C:/AllExports".

    activities

    Vector of hash tables; each hash table describes an Activity to be created. For example, allexports.

    ArchiveService.deleteActivities(java.lang.String directory, java.util.Vector activities)

    Deletes the previously exported activities specified by the vector from the specified directory. Use this command to delete activities from the archive repository, not from the Activities server or database. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be deleted. A returned empty vector indicates success.

    Parameters:

    directory

    Archive directory on the file system from which to delete the activities. For example, "C:/AllExports".

    activities

    Vector of hash tables; each hash table describes an activity to be deleted. For example, janesactivities.

    ArchiveService.exportActivities(java.lang.String directory, java.util.Vector activities)

    Exports the activities specified by the Vector into the specified directory; this method will overwrite an activity if it already exists in the specified directory. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be exported. A returned empty Vector indicates success.

    Parameters:

    directory

    Directory on the file system to which to export the activities. For example, "C:/temp/zips".

    activities

    Vector of hash tables; each hash table describes an activity to be exported. For example, activities.

    ArchiveService.fetchActivities(java.lang.String directory)

    Gets a list of all archived activities in the specified directory. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory.

    Parameters:

    directory

    Directory on the file system that contains the archived activities. For example, "C:/AllExports".

    ArchiveService.fetchActivitiesByMember(java.lang.String directory , java.util.Hashtable member)

    Gets a list of all archived activities in the specified directory to which the specified member has access. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory. This command does not return community activities.

    Parameters:

    directory

    Directory on the file system that contains the archived activities. For example, "C:/AllExports".

    member

    Hash table representing the members returned from the MemberService object. For example, paul_smith.

    Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.

    ArchiveService.fetchActivitiesByOwner(java.lang.String directory , java.util.Hashtable member)

    Gets a list of all archived activities in the specified directory that are owned by the specified member. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable objects describing an archived activity in the directory. This command does not return community activities.

    Parameters:

    directory

    Directory on the file system that contains the archived activities. For example, "C:/AllExports".

    member

    Hash table representing the owners of archived activities returned from the MemberService object. For example, paul_smith.

    Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.

    ArchiveService.fetchActivitiesCreatedByMember(java.lang.String directory, java.util.Hashtable member)

    Gets list of all archived activities in the specified directory that were created by the specified member. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory. This command does not return community activities.

    Parameters:

    directory

    Directory on the file system that contains the archived activities. For example, "C:/AllExports".

    member

    Hash table representing the member who created the archived activities returned from the MemberService object. For example, jane.

    Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.

    ArchiveService.importActivities(java.lang.String directory, java.util.Vector activities)

    Imports the activities specified by the Vector whose archives are located in the specified directory into the Activities application. This method overwrites an activity if it already exists. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be imported. A returned empty Vector indicates success.

    Parameters:

    directory

    Directory on the file system from which to import the activities. For example, "c:/temp/zips".

    activities

    Vector of hash tables; each hash table describes an activity to be imported. For example, activitiesToImport.


    ListService

    ListService.filterActivitiesByName(inList, toMatch)

    Represents a script that can be used to filter or narrow down a list of activities matching certain criteria. This script is useful for locating a subset of activities that can then be used as input for a subsequent command. A typical example is creating a list of activities for export. Returns a list of activities whose Title field matches the pattern criteria.

    Parameters:

    inList

    Previously fetched list of activities.

    toMatch

    Java regular expression pattern representing match criteria. This pattern is used to search the title of the activity. 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 brackets ([]). For example, [Gg] matches either an upper or lower case G.

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

    Example:

    execfile("activitiesAdmin.py")
    
    
    # Fetch all activities and save
    # to variable named "all"
    
    all=ActivityService.fetchActivities()
    
    # From the list of all activities,
    # Extract activities whose name 
    # begins with "Sales"
    
    sales=ListService.filterActivitiesByName(all,"Sales.*")
    
    # Activities in "all" that begin 
    # with "Sales" are saved in the 
    # variable named "sales". The 
    # variable "sales" can be used as 
    # input for other commands, such 
    # as the command to export 
    # activities. The following command
    # will export all the activities 
    # whose name begins with "Sales" to
    # the /opt/foo folder.
    
    ArchiveService.exportActivities(
     "/opt/foo", "Sales.*")


    StatisticsService

    StatisticsService.fetchStatistic(java.lang.String key)

    Gets a server statistic.

    Returns a java.lang.Integer or java.util.Hashtable object containing statistic data defined using the following keys:

    invocations

    Number of times the function has been invoked.

    total

    Total amount of time that is consumed by this operation.

    minimum

    Minimum amount of time that a single invocation lasted.

    maximum

    Maximum amount of time that a single invocation lasted.

    average

    Average amount of time that a single invocation lasted.

    The list of available statistics for your server can be found at: http://yourservername.company.com/activities/service/html/serverstats

    Use any of the statistics listed in this table as input to this command. The statistics listed as Stop Watch Statistics are similar to parent statistics and, when you use one of them as the key, it returns a hash table containing statistics for invocations, total, minimum, maximum, and average.

    Parameters:

    key

    Name of the statistic to be returned specified as a String value.

    StatisticsService.fetchStatistics()

    Gets all system statistics. Returns a java.util.Hashtable object with server statistics data.


    TrashCollectionService

    TrashCollectionService.fetchTrash()

    Gets all of the objects that are currently in the Trash view. Returns a java.util.Vector object that contains a set of hash tables; each hash table describes an object in the trash.

    TrashCollectionService.purgeTrash(java.util.Vector trashVector)

    Permanently removes the objects in the trashVector parameter from the Activities application. Returns a java.util.Vector of java.util.Hashtables object; each hash table describes an object in the trash that could not be purged.

    Parameters:

    trashVector

    A vector of hash tables; each hash table describes an object in the trash to be purged (obtained using the TrashCollectionService.fetchTrash command).

    TrashCollectionService.undeleteTrash(java.util.Vector trashVector)

    Restores previously deleted objects from the Trash view. Returns a java.util.Vector object that contains java.util.Hashtable objectss; each Hashtable describes an object in the trash that could not be restored from the trash.

    Parameters:

    trashVector

    A vector of hash tables; each hash table describes an object in the trash to be restored (obtained using the TrashCollectionService.fetchTrash command).


    Related

  • Synchronize user data using administrative commands

  • Manage member access to activities
  • Export activities
  • Get a list of activities
  • Synchronize user data between Profiles and the LDAP directory
  • Run administrative commands
  • Compare remote application data with the Communities database
  • Synchronize remote application data with the Communities database

  • Communities administrative commands


    Example: Activities administrative session

    The following sample is a typical Activities administrative session. Reference this example to see how various administrative commands are used.

        EXAMPLE OF USING ACTIVITIES ADMINISTRATIVE COMMANDS
    # The following example adds two new members to existing activities.
    # User manager@company.com will be added to all activities where user 
    # employee1@company.com is a member. This user will be added with "owner"
    # access to those activities. Next, user employee2@company.com will be
    # added as a member to all activities that employee1@company.com has access
    # to, but with "author" access.
    
    # Create a member object by using their email and assign the value that is returned
    # to a variable.
    
    wsadmin>employee1=ActivitiesMemberService.fetchMemberByEmail("employee1@company.com")
    wsadmin>employee2=ActivitiesMemberService.fetchMemberByEmail("employee2@company.com")
    wsadmin>manager=ActivitiesMemberService.fetchMemberByEmail("manager@company.com")
    
    # Call the ActivityService to fetch all activities that employee1 is a member of.
    
    wsadmin>activities=ActivityService.fetchActivitiesByMember(employee1)
    
    # Call AccessControlService to add 'manager' to all of 'employee1' activities as 
    # new owner
    
    wsadmin>AccessControlService.setOwnerAccess(activities,manager)
    
    # Call the AccessControlService to add 'employee2' to all of 'employee1' 
    # activities as a new member (with author access).  Because the 
    # AccessControl.setMembersAccess command is expecting the second argument 
    # (member to be added) to be a "vector", the first 3 commands convert the value 
    # that is stored in the variable "employee2" from a "Hashtable"
    # into a "Vector" and stores the new vector in the variable "newMembers".
    
    wsadmin>from java.util import Vector
    wsadmin>newMembers=Vector()
    wsadmin>newMembers.add(employee2)
    wsadmin>AccessControlService.setMembersAccess(activities,newMembers)
    
    
    
    # Export all activities of which a person is a member to location "c:/temp/zips".
    # Create a member object by using their email and assign it to the variable 
    # "member".
    wsadmin>member=ActivitiesMemberService.fetchMemberByEmail("employee@company.com")
    
    # Call the ActivityService to fetch all of the standard activities and assign the 
    # result to the variable "activities".
    
    wsadmin>activities=ActivityService.fetchActivitiesByMember(member)
    
    # Call export to export their activities to the given directory
    wsadmin>ArchiveService.exportActivities("c:/temp/zips",activities)
    
    
    
    # Import all activities from the archives in a directory
    
    # From a previous export, locate the directory of activity zip files to import, 
    # and type:
    wsadmin>activitiesToImport=ArchiveService.fetchActivities("c:/temp/zips")
    
    # Call the ArchiveService to import the activities. If they already exist in the 
    # system, the activities are overwritten.
    
    wsadmin>ArchiveService.importActivities("c:/temp/zips",activitiesToImport)
    
    
    # Create new activities from the previously exported archives in a directory
    # From a previous export, locate the directory of activity zip files to import, 
    # and type:
    wsadmin>activitiesToImport=ArchiveService.fetchActivities("c:/temp/zips")
    
    # Alternatively, if it's preferable not to overwrite existing activities, call
    # 'createActivities' instead to create copies. Notice, this command will generate 
    # new UUIDs for all the imported activities.
    
    wsadmin>ArchiveService.createActivities("c:/temp/zips",activitiesToImport)
    


    Get a list of activities

    Use administrative commands to retrieve lists of activities 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 Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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. Get a list of the activities and entries using one of the following commands:

      • To get a list of all the activities created by your users except those in the trash:

        ActivityService.fetchActivities()

      • To get a list of deleted activities, which are activities that have been moved to the Trash view, but have not been permanently deleted yet. They are not permanently deleted until the Trash view is purged.

        ActivityService.fetchDeletedActivities()

      • To get a list of activities that have been marked Completed:

        ActivityService.fetchCompletedActivities()

      • To get a list of activities that were created or modified within a specified date range:

        ActivityService.fetchActivitiesByDate(java.lang.String dateType, 
         java.lang.String beginTime, java.lang.String endTime, 
         java.lang.String lastUUID)

        This command does not return activity templates that were created during the specified date range, but does include in the activities that it returns any activities present in the Trash view that were created during the specified date range.

        Parameters:

        dateType

        Date field of interest. Options are created and modified.

        beginTime

        Start timestamp of the range, using a yyyy.mm.dd format.

        endTime

        Finish timestamp of the range, using a yyyy.mm.dd format.

        lastUUID

        Unique ID of the last activity retrieved from a previous call of this command. Specify empty double quotes if you expect less than 50 activities in the response, or if you are running this command for the first time.

        For example, the following command gets the first set of 50 activities that were created from 1 March 2008 through 31 March 2008:

        ActivityService.fetchActivitiesByDate("created","2008.03.01","2008.03.31","")

      • To get an activity with a specified universal identifier:

        ActivityService.fetchActivityById(java.lang.String uuid)
        You can find the universal identifier of an activity by using other fetch commands. The hash table of an activity includes an activityID, such as activityId=3F9G09219392F4733F40F82A4E8D5F000083. For example:

        ActivityService.fetchActivityById("3F9G09219392F4733F40F82A4E8D5F000083")

      • To get a list of activities filtered by member, complete the following steps:

      1. Retrieve information about the member by whom you want to filter the activities and save it to a variable :

        variable=MemberService.fetchMemberByName(java.lang.String member)
        For example:

        jane=MemberService.fetchMemberByName("Jane Fairfax")

      2. You filter the activities using this member information in the following ways:

        • To get a list of activities that were created by the member:

          ActivityService.fetchActivitiesCreatedByMember(java.util.Hashtable member)
          For example:

          ActivityService.fetchActivitiesCreatedByMember(jane)

        • To get a list of standard activities to which the member has access:

          ActivityService.fetchActivitiesByMember(java.util.Hashtable member)

        • To get a list of standard activities of which the member is the owner:

          ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)

        fetchActivitiesByMember() and fetchActivitiesByOwner() only return standard activities; they do not return community activities.

    3. See Narrow down results for information on how filter the list of results into a smaller subset.


    Related tasks

  • Start the wsadmin client
  • Narrow down results
  • Manage member access to activities
  • Export activities

  • Activities administrative commands


    Narrow down results

    Use standard Java code or the filtering command provided by the ListService object to retrieve a subset of activities or entries on which you would like to perform an operation.

    1. When you use a command to retrieve a set of resources, use a variable to store the returned data. For example, the following code stores the objects returned from the fetchTrash() command, which are formatted as a java.util.Vector of hash tables that represent activities and entries in the Trash view, in the alltrash variable:

      alltrash=TrashCollectionService.fetchTrash()

    2. Do one of the following:

      • Use the ListService.filterActivitiesByName() command to narrow down the results that you stored in the alltrash variable. For example, the following command finds only those activities in the alltrash variable that have an activity name that begins with "AJ78" and stores them in the myactivity variable:

        myactivities=ListService.filterActivitiesByName(alltrash, "AJ78.*")

      • Use standard Java to parse the returned vector of hash tables and collect a subset of them in the myactivities variable.

    3. Pass the variable containing the subset of resources that you want to operate on into the command. For example, to restore the collected subset of activities that are currently in the Trash view, you could use the following command:

      TrashCollectionService.undeleteTrash(myactivities)


    Related tasks

  • Run Activities administrative commands
  • Get a list of activities
  • Purging specific activities or entries from the trash
  • Restore deleted activities

    Manage activity membership

    Use administrative commands to change member access levels and synchronize member IDs.

    When the name of a group that is used in an activity is renamed in LDAP, the old group name still appears on the Members page of the activity.


    Related

  • Groups


    Retrieve member information

    Use administrative commands to retrieve a single activity member or a list of activity members.

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

    Some of the other administrative commands, such as ActivityService.fetchActivitiesByMember(java.util.Hashtable member) take the java.util.Hashtable variable as a parameter. You can use this procedure to retrieve member information and save it as a java.util.Hashtable variable.

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 any of the following commands to retrieve a list of activity members:

      • To return a list of members or groups whose names match the search criteria:

        ActivitiesMemberService.fetchMembers(java.lang.String name)
        This command returns a vector of hash tables. Each hashtable represents a member or group. For example, the following command:

        ActivitiesMemberService.fetchMembers("Jane Fairfax")
        returns the following vector [], which contains a single hash table {}:

        [{memberId=FBFG092191072384B4DB336C9B5BF9000043, displayName=Jane Fairfax, 
        loginNames=[jfairfax@acme.com, Jane Fairfax], staticProfile=false, 
        externalId=3901C921-E104-40BC-8AAA-C947146C8F68, email=jfairfax@acme.com, 
        memberType=person}]
        This command uses a wildcard character to fetch all members or groups that begin with the word Acme:

        ActivitiesMemberService.fetchMembers("Acme*")
        It returns the following vector which contains two hash tables: one for Acme Sales and one for Acme Marketing.

        [{memberId=0BEG7F00000145EAB17F33E66924AA00009D, displayName=Acme Marketing,
         staticProfile=false, externalId=46b4a55a-47ae-4e29-ae8c-03c42d83f1cc, 
         memberType=group}
        {memberId=7DG09218G7F00000145EAB17F33E669007, displayName=Acme Sales, 
         staticProfile=false, externalId=12c4c66a-44aa-4e31-ae44-01c42c83f1ab, 
         memberType=group}]

      • To retrieve information about a member or group using a name as input:

        ActivitiesMemberService.fetchMemberByName(java.lang.String name)
        For example:

        ActivitiesMemberService.fetchMemberByName("Paul Smith")
        returns a hash table that contains information for the one member that matched the name passed in as a parameter:

        {memberId=ACF1093191092345B4DB336C9B5BF9000055, displayName=Paul Smith, 
         loginNames=[paul_smith@acme.com, Paul Smith], staticProfile=false, 
         externalId=12345678-ABCD-44BC-8BBB-C947146C8F12, email=paul_smith@acme.com,
         memberType=person}

      • To retrieve information about a member using the person's login name as input:

        ActivitiesMemberService.fetchMemberByLogin(java.lang.String name)
        For example, if you pass in the value of the Paul Smith:

        ActivitiesMemberService.fetchMemberByLogin("Paul Smith")
        it returns the following hash table, which represents Paul Smith:

        {memberId=FBFG092191072384B4DB336C9B5BF9000043, displayName=Paul Smith, 
        loginNames=[paul_smith@acme.com, Paul Smith], staticProfile=false, 
        externalId=3901C921-E104-40BC-8AAA-C947146C8F68, 
        email=paul_smith@acme.com, memberType=person}

      • To retrieve information about a member using the person's email address as input:

        ActivitiesMemberService.fetchMemberByEmail(java.lang.String mail)
        For example:

        ActivitiesMemberService.fetchMemberByEmail("paul_smith@acme.com")
        returns a hash table that contains information for the one member that matched the name passed in as a parameter:

        {memberId=ACF1093191092345B4DB336C9B5BF9000055, displayName=Paul Smith, 
         loginNames=[paul_smith@acme.com, Paul Smith], staticProfile=false, 
         externalId=12345678-ABCD-44BC-8BBB-C947146C8F12, email=paul_smith@acme.com,
         memberType=person}

      • To retrieve information about a member or group using their unique member ID as input:

        ActivitiesMemberService.fetchMemberById(java.lang.String id)
        For example, if you pass in the value of the memberID returned for Paul Smith:

        ActivitiesMemberService.fetchMemberById("ACF1093191092345B4DB336C9B5BF9000055")
        it returns the following hash table, which represents a single member named Paul Smith:

        {memberId=ACF1093191092345B4DB336C9B5BF9000055, displayName=Paul Smith, 
         loginNames=[paul_smith@acme.com, Paul Smith], staticProfile=false, 
         externalId=12345678-ABCD-44BC-8BBB-C947146C8F12, email=paul_smith@acme.com,
         memberType=person}


    What to do next

    See Managing users for information about how to update the data associated with a member.


    Related

  • Manage users

  • Start the wsadmin client


    Manage member access to activities

    Use administrative commands to change the level of access that members have to one or more activities.

    You cannot use the AccessControlService commands to fetch, set, or delete access to community activities. See Communities administrative commands for information about the commands you can use to add a person to a community.

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

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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. Find the hash table identifier for the activity or activities for which you want to edit the access levels. Fetch the ActivityID from the output by running the following command.

      ActivityService.fetchActivities() 

    3. Identify the activity or activities to edit from the returned list. See Get a list of activities for more information. For example:

      ActivityService.fetchActivities()
      		 ActivityService.fetchDeletedActivities()
      		 ActivityService.fetchCompletedActivities()
      		 ActivityService.fetchActivitiesByDate(java.lang.String dateType, java.lang.String beginTime,
      					 java.lang.String endTime, java.lang.String lastUUID)
      		 ActivityService.fetchActivityById(java.lang.String uuid)
      		 ActivityService.fetchActivitiesCreatedByMember(java.util.Hashtable member)
      		 ActivityService.fetchActivitiesByMember(java.util.Hashtable member)
      		 ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)

    4. Enter the following commands to see the current access levels of the members of a single activity:

      ActivityService.fetchActivityById(java.lang.String uuid)
      For example:

       myactivities=ActivityService.fetchActivityById(bb34202c-74a4-4f12-97a5-baad003ba021) 

      AccessControlService.fetchAccess( java.util.Hashtable activity)
      For example:

      AccessControlService.fetchAccess(myactivities)

    5. Create a variable that contains information about one or more people to whom you would like to grant access to the activities. Do one of the following:

      • If you are defining the owner of an activity, save the member information as a hash table variable. The setOwnerAccess command expects the member parameter to be provided in hash table format. To do so, use the following command:

        ActivitiesMemberService.fetchMemberByName(java.lang.String name)
        For example:

        jane=ActivitiesMemberService.fetchMemberByName("Jane Fairfax")

      • If you are granting author or reader access, save the member information as a vector variable. The setMemberAccess and setReaderAccess commands expect the member parameter to be provided in vector format. A vector can represent one person or multiple people. A vector contains one or more hash tables. Each hash table contains information for a single person. To save member information as a vector variable, use the following command:

        ActivitiesMemberService.fetchMembers(java.lang.String filter)
        For example:

        allFairfaxes=ActivitiesMemberService.fetchMembers("*Fairfax")
        or

        frank=ActivitiesMemberService.fetchMembers("Frank Fairfax")

    6. Use the following commands to make the access level changes to make:

      • To grant many people owner-level access to one or more activities:

        AccessControlService.setOwnersAccess( java.util.Vector activities, 
         java.util.Hashtable owner)

      • To grant one person owner-level access to one or more activities:

        AccessControlService.setOwnerAccess( java.util.Vector activities, 
         java.util.Hashtable owner)
        For example:

        AccessControlService.setOwnerAccess(myactivities,jane)

      • To grant one person or many people author-level access to one or more activities:

        AccessControlService.setMembersAccess(java.util.Vector activities, 
         java.util.Vector members)
        For example:

        AccessControlService.setMembersAccess(activities,allFairfaxes)

      • To grant one person or many people reader-level access to one or more activities:

        AccessControlService.setReadersAccess(java.util.Vector activities, 
         java.util.Vector members)
        For example:

        AccessControlService.setReadersAccess(activities,frank)

      • To deny access to a set of members:

        AccessControlService.deleteAccess(java.util.Vector activities, 
         java.util.Vector members)


    Related tasks

  • Start the wsadmin client
  • Get a list of activities

  • Activities administrative commands

    Manage uploaded files

    Protect the performance of your implementation of Activities by designating a size limit for the files that can be uploaded to the site and adding to or moving the content store associated with Activities.


    Set limits on uploaded files

    Edit configuration property settings to limit the types of files that can be uploaded into Activities, the maximum size of an uploaded file, and the number of server threads concurrently dedicated to downloading files from Activities to clients.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    The Activities content store is used to store files that users upload to their activities.

    To set limits on uploaded files

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. From the temporary directory to which you just checked out the oa-config.xml file, open the file in a text editor.

    3. Edit the elements in the <objectStore> section of the file to set limits on the files that can be uploaded.

      • To prevent users from being able to upload files of a specific type to Activities, add a <sizeLimits> element block to the <objectStore> section. For each file type to disable, create a <limit> element. Set the mimeFilenameRegex attribute of the <limit> element equal to the file extension of the file type to prevent users from uploading. Set the value of the limit element to 0. For example, the following element prevents users from being able to upload executable files:

        <sizeLimits>
           <limit mimeFilenameRegex=".*\.exe">0</limit>
        </sizeLimits>
        Tip: When you specify a value for the mimeFilenameRegex attribute, you are specifying a regular expression. Regular expressions are normally case sensitive, and in the 1.0.x releases were treated as such. With release 2.0, the filter has been enhanced to be case insensitive. For example, if you specify <limit mimeFilenameRegex=".*\.exe">, the tool will filter any files with a .exe extension regardless of the case in which the letters EXE are specified.

      • To limit the size of all files uploaded to the Activities content store, modify the value of the <limit> element for the entry with the .* extension. Set the new maximum size value in bytes. For example, the following property settings specifies that all files must be smaller than 10.5 MB:

        <limit mimeFilenameRegex=".*">10500000</limit>

      • To limit the number of threads that are allowed to concurrently respond to requests to download files from the Activities content store, edit the value of the <max-concurrent-downloads> element. For example, the following property settings allows the server to permit a maximum of 10 downloads at one time:

        <max-concurrent-downloads>10</max-concurrent-downloads>

    4. To remove a file upload limitation, delete the <limit> element representing the file type to permit users to upload.

    5. To enable unlimited simultaneous downloads, remove the <max-concurrent-downloads> element.

    6. Save and close the oa-config.xml file.

    7. 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. You must also restart the server. See Applying property changes for details.

    8. After restarting the Activities server, review the WebSphere Application Server SystemOut.log file to ensure that the Activities application was able to initialize with the modified configuration.


    Example

    The following lines of XML provides an example of oa-config.xml file content that describes a <sizelimit> configuration. In this example, files with .exe, .sh, .bat, and .oa extentions cannot be uploaded to Activities, the maximum file size of an uploaded file is approximately 10MB, and the number of concurrent downloads is limited to 5.

    <sizeLimits>
           <limit mimeFilenameRegex=".*\.exe">0</limit>
           <limit mimeFilenameRegex=".*\.bat">0</limit>
           <limit mimeFilenameRegex=".*\.sh">0</limit>
           <limit mimeFilenameRegex=".*\.oa">0</limit>
           <limit mimeFilenameRegex=".*">10485760</limit>
    </sizeLimits>
    
    <max-concurrent-downloads>5</max-concurrent-downloads>


    Related tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities


    Define multiple content stores for Activities

    You can configure Activities to use a different content store instead of the one defined at installation time. You might want to add a content store if the current disk space reaches capacity or you augment your infrastructure and there is a new drive with more disk space available, for example. If you have a version 3.0.1 or earlier implementation of Activities, you can add a content store to take advantage of the enhanced content store implementation that was introduced in version 4.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    The Activities content store is used to store files and other content that users add to their activities. During product installation, you can modify the location on disk on which the content store is created. If you want to change the location of the content store after installing Activities, complete this procedure to do so. You must maintain the existing content store because it continues to hold any files uploaded and stored in the original content store. Only new files are added to the new content store. The files in the existing content store become read-only; if you edit a file stored in the old content store, the revised version of the file is stored in the new content store and the previous version is marked for deletion from the old content store.

    With release 4, the Java object used to define the content store changed. The new implementation provides the following enhancements:

    • Resources from one activity are distributed and stored across multiple directories. In previous releases, the resources were all stored in subdirectories of a single directory. The new method helps to prevent busy implementations from reaching the maximum number of allowed subdirectories. For example, a directory on an EXT2 or EXT3 file system or Journal File System (JFS) and JFS2 on AIX allows for a maximum of 32K subdirectories only. When the maximum number of subdirectories is reached, the administrator must add a new content store to the deployment.

    • Improves the security of the files attached to activity entries. The new implementation uses a unique identifier to name the file instead of the name given to it by the person uploading it. It also stores metadata associated with the file, such as its mime type and user-defined name, separately so that someone with access to the disk cannot view the file without doing so through the product user interface.

    To change content stores:

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. From the temporary directory to which you just checked out the oa-config.xml file, open the file in a text editor.

    3. Find the existing <store> element, which defines the current content store location. Copy the <store> element, and then paste it after the existing <store> element.

    4. Edit the default attribute of the existing <store> element; change its value to false.

      Only one <store> element can have the default attribute set to true. If you change to a new content store, you must retain the original store, or any data that was saved there will be inaccessible and will adversely affect the existing activities. When you add a new content store, and set its default attribute to true, you are indicating that new content will be saved to the new content store; existing content remains in the existing content store and is read-only.

    5. Modify the new <store> element to point to the new file system location.

      <id> element

      Specify a unique name for the file system. This name must contain no more than 32 characters.

      Activities relies on the <id> element to map to the content store configuration. Do not change the value of the <id> element after the system is in use.

      root.directory property

      Edit the value of the property to reflect the file path of the new file system location using one of the following formats:

      • File path to a network share directory using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name.

      • Name of the WebSphere Application Server environment variable that defines the file store location. For example: ${ACTIVITIES_CONTENT_DIR}. Using this syntax to define the directory location makes it easier to change the value of the content store path information later, if necessary, because you only need to edit the value of the variable to automatically update it in the many places it is referenced from.
      Set the same value on each node to which you install Activities.

      For example:

      <store 
        default="false" 
        class="com.ibm.openactivities.objectstore.filesystem.FileSystemObjectStore">
          <id>filesystem</id>
          <property name="use.historic">false</property>
          <property name="root.directory">
           \\enterprise.server\LotusConnections\Data\activities\content
          </property>
      
      </store>
      <store 
        default="true" 
        class="com.ibm.openactivities.objectstore.filesystem.ContentStore">
          <id>filesystem2</id>
          <property name="use.historic">false</property>
          <property name="root.directory">${ACTIVITIES_CONTENT_DIR}</property>
      </store>

    6. Save and close the oa-config.xml file.

    7. 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 details.

    8. After restarting the Activities server, review the WebSphere Application Server SystemOut.log file to ensure that the Activities application was able to initialize with the modified configuration.


    Related tasks

  • Move the content store
  • Start the wsadmin client
  • Apply property changes in Activities


    Move the content store

    You can change the location of the content store used by the Activities application from the location defined at installation time. You might want to change the location of the content store if you augment your infrastructure and there is a new drive with more disk space available, for example.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    The Activities content store is used to store files and other content that users add to their activities. If you want to change the location of the content store after installing Activities, you can do so by performing the steps in this procedure. If you want to maintain the existing content store, you can create a new content store in addition to the existing one. See Defining multiple content stores for more information.

    To move the content store:

    1. The location of the content store is defined in the oa-config.xml file using one of the following formats:

      • File path to a network share directory in Universal Naming Convention (UNC) format. For example: \\server_name\share_name. Set the same directory on each node to which Activities is installed.

      • WebSphere Application Server environment variable which contains the file path information. For example: ${ACTIVITIES_CONTENT_DIR}

    2. If the file path is defined in UNC format only: You must edit the oa-config.xml configuration file. Use the wsadmin client to access and check out the configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

      3. From the temporary directory to which you just checked out the oa-config.xml file, open the file in a text editor.

      4. Find the existing <store> element, which defines the current content store location. Edit the following property of the <store> element to point to the new directory location:

        root.directory property

        Edit the value of the property to reflect the file path of the new file system location.

        Do not change the value of the <id> element. Activities relies on the <id> element to map to the content store configuration.

      5. Save and close the oa-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 details.

    3. If the file path is defined using a WebSphere Application Server environment variable: Edit the value of the variable :

      1. Use an administrator ID, log into the WebSphere Application Server Integrated Console associated with the profile to which you installed Activities.

      2. Expand Environment, and then click WebSphere Variables.

      3. Find the ACTIVITIES_CONTENT_DIR environment variable from the list, and then edit its value.

      4. Save, and then apply your changes

    4. Copy the content store data from the old content store location to the new location.

    5. Restart the Activities application.

    6. After restarting the Activities server, review the WebSphere Application Server SystemOut.log file to ensure that the Activities application was able to initialize with the modified configuration.

    7. After the content store is successfully copied to the new location, you can remove the original content store.


    Related tasks

  • Define multiple content stores for Activities


    Back up Activities data

    Activities stores data in both a database and the file system. You should backup both sets of data on a regular basis.

    1. From the WebSphere Application Server Integrated Solutions Console, stop the Activities application or cluster.

    2. Back up the OPNACT database according to the database documentation provided by your database vendor.

      Backup the database before backing up the content store on the file system.

    3. Backup the directory on the file system that contains the Activities data according to the documentation provided by your file system vendor. To determine the location of the Activities directory, get the value of the ACTIVITIES_CONTENT_DIR WebSphere Application Server variable for the relevant server :

      1. Open the WebSphere Application Server Integrated Solutions Console.

      2. Select Environment > WebSphere Variables.

      3. Click Show filter function.

      4. Ensure that WebSphere Variables displays in the Filter dropdown menu.

      5. Enter ACTIVITIES_CONTENT_DIR into the Search term(s) text box and click Go. A variable called ACTIVITIES_CONTENT_DIR displays in the search results. Take a note of the value of this variable as the index location for the relevant server.

    4. Restart the Activities application or cluster.


    Related tasks

  • Restore Activities data
  • Compare remote application data with the Communities database


    Restore Activities data

    You can restore Activities data to a previously backed up version.

    This procedure assumes that you have been backing up the Activities database and content store on a regular basis.

    1. From the WebSphere Application Server Integrated Solutions Console, stop the Activities application or cluster.

    2. Stop the Search service or cluster.

    3. Restore the OPNACT database from the latest backed up version according to the database documentation provided by your database vendor.

      Restore the database before restoring the content store on the file system.

    4. Restore the data in the directory on the file system that contains the Activities data according to the documentation provided by your file system vendor.

    5. Delete the IBM Connections index. Refer to the instructions in the Deleting the index topic.

    6. Restart the Search application or cluster.

    7. Restart the Activities application or cluster.

    8. If you have any community activities, you must perform some additional step to make sure that the Activities database and Communities database are synchronized with the same activities data. To do so, complete the steps described in the Comparing remote application data with the Communities database topic.


    Related tasks

  • Compare remote application data with the Communities database
  • Maintain application DBs
  • Delete the index
  • Back up Activities data

    Integrate Activities with IBM Lotus Quickr

    After you have finished collaborating with your team on a file in an activity, you can publish the finished product to an IBM Lotus Quickr library to share it with a larger group or to store the file.


    Enable users to publish file attachments to Lotus Quickr

    Edit the configuration property settings of Activities to allow users to publish file attachments from an activity to an IBM Lotus Quickr library.

    Before you can complete this procedure, you must have Lotus Quickr deployed in your environment and know the fully qualified domain names of all the Lotus Quickr servers that you want users to be able to publish to.

    Decide which type of authentication to use between the Activities and Lotus Quickr servers, and perform any required prerequisite tasks to support the authentication type that you decide to use. You must choose between the following options:

    Single sign-on

    By default, the Activities application assumes that single sign-on (SSO) is configured between the Activities server and the Lotus Quickr servers. As a result, when Activities users select the Lotus Quickr servers that they want to publish file attachments to, they are not prompted for user names and passwords. To support this functionality, you must first enable SSO with Lotus Quickr. See Enabling single sign-on with Lotus Quickr.

    Basic authentication

    If for some reason you do not want to or cannot set up SSO between the Activities and Lotus Quickr servers, Activities users are prompted for a user name and password when they try to publish file attachment to Lotus Quickr. To ensure that those credentials are not sent unprotected over HTTP, you must take the following steps:

    • Configure IBM Connections to force traffic on the Activities server to be sent over a secure channel. See Forcing traffic to be sent over SSL.

    • Specify HTTPS as the protocol for the servers that you define in Step 4.

    • Do not perform Step 5.

    • Perform Step 6.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. From the temporary directory to which you checked out the Activities configuration file, open the oa-config.xml file in a text editor.

    3. Set the enabled attribute of the <PublishFile> element to true.

    4. Create one <server> element for each Lotus Quickr server to support. In the server element, specify the fully qualified domain name of the Lotus Quickr server to allow your users to publish files to. Include the port number.

      For example:

      <PublishFile enabled="true" allowCustomServers="false" requireSSO="true">
            <server>http://quickr.example.com:8085</server>
            <server>http://quickr.southwest.example.com:8080</server>
      </PublishFile>
      If the Quickr serves are protected by TAM, use the junction name in the URL. For example:

      <PublishFile enabled="true" allowCustomServers="false" requireSSO="true">
            <server>http://TAM.quickr.example.com:8085/Quickr_junction</server>
            <server>http://TAM.quickr.southwest.example.com:8080/Quickr_junction</server>
      </PublishFile>
      If you are not setting up single sign-on between the Activities and Lotus Quickr servers, specify the servers using the HTTPS protocol. For example:

      <PublishFile enabled="true" allowCustomServers="false" requireSSO="false">
            <server>https://quickr.example.com:8085</server>
            <server>https://quickr.southwest.example.com:8080</server>
      </PublishFile>
      The first server that you specify in the list becomes the default server that is displayed in the Server field in the dialog box from which the user selects the Lotus Quickr library to which to publish a file. If a user selects a different Lotus Quickr server from the Server field, that server becomes the default.

    5. If, instead of specifying a finite list of servers that users can save files to, you want users to be able to save files to any Lotus Quickr server hosted within a specific domain, set the allowCustomServers attribute to true .

      For example:

      <PublishFile enabled="true" allowCustomServers="true" requireSSO="true">
      </PublishFile>

      Perform this step only if you are setting up SSO between the Activities and Lotus Quickr servers. Keeping the value of this attribute set to false prevents users from typing in server names that specify the HTTP protocol instead of HTTPS.

    6. If you decide to not set up SSO between the Activities and Lotus Quickr servers, change the value of the requireSSO attribute to false.

      For example:

      <PublishFile enabled="true" allowCustomServers="false" requireSSO="false">
      		<server>https://quickr.example.com:8085</server>
      		<server>https://quickr.southwest.example.com:8080</server>
      </PublishFile>
      When you make this change, you must perform the steps necessary to force the Activities server traffic to be sent over SSL. See Forcing traffic to be sent over SSL.

    7. Save and close the oa-config.xml file.

    8. 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 details.


    Related tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities
  • Enable single sign-on for Lotus Quickr
  • Forcing traffic to be sent over SSL


    Define a list of supported Lotus Quickr servers

    After you configure the Activities server to allow file attachments to be published to IBM Lotus Quickr, you must provide a list of the supported Lotus Quickr servers to the proxy server, so that it honors any requests made for access to one of the supported Lotus Quickr servers.

    You must have Lotus Quickr deployed in your enterprise before you can perform this procedure. You must have administrative access to the WebSphere Application Server to which Activities is installed. This is an optional task. Perform this task if you want users to be able to publish files that have been attached to activity entries from Activities to a Lotus Quickr library.

    1. Go to the WebSphere Application Server Integrated Solutions Console for the server hosting the deployment manager.

    2. Expand Resources > Resource Environment, and then click Resource Environment Providers.

    3. Click QuickrWhitelistProvider from the list, and then click Custom properties.

    4. Create one custom property for each Lotus Quickr server to enable users to publish documents to. To create a custom property, enter values in the following fields:

      If you upgraded a stand-alone deployment which was already configured to integrate with Lotus Quickr to a network deployment, you must recreate these custom properties for the provider on the cluster's cell. The custom properties must be redefined because they are lost when you federate the node into a cluster.

      name

      Create a property name that begins with the term allow. For example:

      allowQuickrPrimary.example.com

      value

      Set the fully qualified domain name of the Lotus Quickr server or its IP address. Do not specify the protocol, nor any port numbers.

      To enable users to publish files to several servers within a specific domain, specify the parent domain in this field. You must start the string with a period (.). For example, if you were to specify .acme.com, the proxy would allow the file to be published to all of the servers that are available from subdomains of acme.com. If you want users to be able to type in a server that is hosted within this domain, set the allowCustomServers attribute of the <PublishFile> element to true in the oa-config.xml file.

      The provider does not convert IP addresses to domain names nor the other way around. If the server is requested using both identifiers, create two properties: one property that specifies the domain name in the value field and one that specifies the IP address in the value field.

    5. Repeat the previous step multiple times to add every server that you defined in the oa-config.xml file when you performed the previous procedure: Enabling users to publish file attachments to Lotus Quickr.

    Manage trash

    Use administrative commands and edit configuration property settings to move activities and entries to the Trash view, empty the trash, restore activities and entries from the Trash view, mark inactive activities complete, and perform other trash management tasks.


    Complete activities that are not being used

    Edit configuration property settings to disable the removal of inactive activities from the My Activities view, to change the amount of time an activity must be inactive before it is marked complete by the server, or to disable the warning notification that is sent to activity owners before an activity is marked complete.

    When an activity is marked complete, it moves from the My Activities view to the Completed view. The default interval is 90 days. Before starting this procedure, determine the amount of time to allow an idle activity to remain in the active views before it is marked complete and moved to the Completed view.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. If email notifications are enabled, Activities warns the owner of an activity that has not been modified in the specified time frame that the activity will be marked complete. This allows the owner to modify the activity to keep it active and prevent it from being marked complete. You can enable and disable this email notification application. If you do not want to automatically move activities into the Completed view, you can also disable this job.

    To remove an activity that is not being used:

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. Display the current configuration settings :

      ActivitiesConfigService.showConfig() 
      From the returned list, look at the current values of the settings that begin with jobs.AutoComplete and determine which property values you want to change:

      jobs.AutoComplete.autoCompletionPeriod

      Defines the number of days of inactivity that must pass before an activity is automatically marked complete. Set the value in days. The default value is 90.

      jobs.AutoComplete.prenotification

      Defines whether or not to send an email to the activity owners to warn them that the activity will be marked complete if no modifications are made to it. This property accepts the following values: true or false. The default value is true. This setting requires that email notifications are enabled.

    3. To change the property values, use the following command:

      ActivitiesConfigService.updateConfig(property, value)

      For example:

      ActivitiesConfigService.updateConfig("jobs.AutoComplete.autoCompletionPeriod","100")
      ActivitiesConfigService.updateConfig("jobs.AutoComplete.prenotification","false")

    4. Optional: If you decide to notify activity owners, you can change the number of days warning they are given by changing the interval at which the job runs. If the job is scheduled to run once a month, the owners get a month's notice that their activity will be marked complete. If it runs weekly, they get a week's notice.

      To change the interval of the job, edit the value of the jobs.AutoComplete.interval property. The default value is 0 0 23 ? * SAT, which specifies that the job should run weekly at 11 PM on Saturday. For information about how to format this value, see Scheduling tasks.

      Use the following command to edit this property:

      ActivitiesConfigService.updateConfig("jobs.AutoComplete.interval", value)

      ...where value is a time interval. For example: "0 30 4 ? * SAT"

    5. Optional: If you want to prevent the auto completion job from running altogether, you can use the following command to disable the job:

      ActivitiesConfigService.updateConfig("jobs.AutoComplete.enabled", "false")

    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 details.


    Example

    When making configuration changes to the ActivityAutoCompleteJob scheduled job, you are modifying settings in the oa-config.xml file. The following XML sample of oa-config.xml file content defines a job that runs weekly (Saturdays at 11 PM) and marks complete any activities on the server that have not been modified in 100 days. Because prenotification is set to false, the activity owners will not get an email notification that the activities will be marked complete. The ActivityAutoCompleteJob task sets the last updated by field in the Activities interface to Activities Administrator.

    <scheduledTasks>
      <!-- cluster scoped jobs -->
      
      <!-- ActivityAutoCompleteJob - weekly on Sat at 11pm  -->
      <task 
       name="ActivityAutoCompleteJob" 
       description="Automatically mark unmodified activities as completed"
       interval="0 0 23 ? * SAT" 
       startby="" 
       enabled="false" 
       scope="cluster" 
       type="class"
       targetName="com.ibm.openactivities.jobs.AutoCompleteJobWS" 
       mbeanMethodName="" 
       serverName="unsupported" >
        <args>
          <property name="autoCompletionPeriod">100</property>
          <property name="prenotification">false</property>
        </args>
      </task>
      ...
    </scheduledTasks>


    Related

  • Schedule tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities
  • Manage the scheduler


    Delete activities

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

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

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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. If you have not yet created a variable that contains the activities you want to delete, create one. You can get a list of activities in hash table format by using one of the fetchActivities commands. See Activities administrative commands for a full list. For example, if a person leaves the organization and you want to delete all of the activities that he owns, you can perform the following steps to narrow down the activities to delete:

      1. Get a hash table of information related to a specific user:

        variable=ActivitiesMemberService.fetchMemberByName(java.lang.String member)
        For example:

        joe=ActivitiesMemberService.fetchMemberByName("Joe Jacobs")

      2. Retrieve the activities that a specific person owns:

        variable=ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)
        For example:

        joesactivities=ActivityService.fetchActivitiesByOwner(joe)

    3. Enter the following command to delete the activity or activities:

      ActivityService.deleteActivities(java.util.Vector activities)

      ...where you specify the activity or activities to delete as the activities parameter. For example:

      ActivityService.deleteActivities(joesactivities)


    Related tasks

  • Start the wsadmin client


    Restore deleted activities

    Use an administrative command to restore activities that were moved to the Trash view. After an activity is moved to the Trash view, and before the Trash is purged from the system, the activity can be preserved if it is restored.

    You do not need to check the configuration file in and out nor restart the server when using administrative commands.

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

    1. Open a command window and start the wsadmin command line tool. See Starting the wsadmin client for more details.

    2. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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. Get a list of the activities and entries currently in the Trash view by entering the following command:

      TrashCollectionService.fetchTrash()

    4. Identify the activity or entry to restore from the returned list. See Narrow down results for more information.

    5. Enter the following command to restore the activity or entry:

      TrashCollectionService.undeleteTrash( java.util.Vector trashVector)

      ...where you specify the activity or entry to restore as the trashVector parameter.


    Example

    Here is an example where all activities are deleted that start with a_activities, a_activities1, a_activities2, ....

    Trash=TrashCollectionService.fetchTrash()
       myactivities=ListService.filterActivitiesByName(Trash, "a_act.*")
      TrashCollectionService.undeleteTrash(myactivities)


    Related tasks

  • Start the wsadmin client
  • Narrow down results


    Empty the Activities trash on a schedule

    Edit configuration property settings to set up a schedule on which to permanently delete the activities and entries that have been moved to the Trash view.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    Activities that are deleted are moved to the Trash view and can be restored from the Trash view. You can schedule the permanent deletion of activities and entries after a time interval that you specify. When the scheduled job runs, the activities and entries in the Trash view are permanently deleted from the system. Items that are purged from the Trash view are not recoverable.

    To schedule the permanent removal of activities or entries from the Trash view, complete the following steps:

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. Display the current Activities configuration settings using the following command:

      ActivitiesConfigService.showConfig() 
      From the returned list, look for the settings that begin with jobs.TrashAutoPurge; these control trash deletion. Determine which property values you want to change:

      jobs.TrashAutoPurge.daysRetention

      Number of days after which you would like activities and their entries removed from the Trash view. Set the value in days. The default value is 90.

      Do not set this value to 0. When it is set to 0, activities and their entries are not removed from the Trash view.

      jobs.TrashAutoPurge.interval

      Frequency with which the job to check for expired content runs. See Scheduling tasks for information about the format to use to specify the interval. The default value is 0 0 2 ? * SUN, which specifies that the job should run weekly at 2 AM on Sunday.

    3. To change the property values, use the following command:

      ActivitiesConfigService.updateConfig(property, value)

      For example:

      ActivitiesConfigService.updateConfig("jobs.TrashAutoPurge.daysRetention", "100")
      ActivitiesConfigService.updateConfig("jobs.TrashAutoPurge.interval", "0 15 10 L * ?")

      The 0 15 10 L * ? value schedules the job to run at 10:15 AM on the last day of every month.

    4. Optional: If you want to prevent the trash purge job from running altogether, you can use the following commands to disable the jobs:

      ActivitiesConfigService.updateConfig("jobs.TrashAutoPurge.enabled", "false")

    5. After making changes, you must 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 details.


    Example

    When making configuration changes to the TrashAutoPurge scheduled job you are modifying settings in the oa-config.xml file. The following sample oa-config.xml file segment removes content from the Trash view after 100 days and runs the job to check for expired content at 10:15 AM on the last day of every month.

    <scheduledTasks>
            <!-- cluster scoped jobs -->
             
            <task 
    						name="TrashAutoPurgeJob" 
     						description="Permanently removes Activities Trash"
    						interval="0 15 10 L * ?" 
    						startby="" 
    						enabled="true" 
    						scope="cluster" 
    						type="class"
    						targetName="com.ibm.openactivities.jobs.TrashAutoPurgeJobWS" 
    						mbeanMethodName="" 
     						serverName="unsupported" >
                 <args>
                       <property name="trashRetentionInDays">100</property>
                 </args>
            </task> 
            ...
    <scheduledTasks>


    Related

  • Schedule tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities
  • Manage the scheduler


    Purging specific activities or entries from the trash

    Use an administrative command to permanently delete a specific activity or entry by removing it from the Trash view.

    You do not need to check the configuration file in and out nor restart the server when using administrative commands.

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

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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. Get a list of the activities and entries currently in the Trash view by entering the following command:

      TrashCollectionService.fetchTrash()

    3. Identify the activity or entry to delete from the returned list. See Narrow down results for more information.

    4. Enter the following command to delete the activity or entry:

      TrashCollectionService.purgeTrash( java.util.Vector trashVector)

      ...where you specify the activity or entry to delete as the trashVector parameter.


    Related tasks

  • Start the wsadmin client
  • Narrow down results

    Monitor statistics and metrics

    Use the Activities statistics gathering application to monitor operations, product usage, and to make configuration adjustments when necessary.

    Activities enables you to monitor statistics in the following ways:

    • Edit configuration settings to change the schedule on which statistics are collected and to define which statistics are collected.

    • Retrieve statistics from a spreadsheet or by using administrative commands.

    • Retrieve statistics from a web page.


    Related tasks

  • Start the wsadmin client

  • Activity statistics


    Activity statistics

    Activities provides a variety of statistics that you can use to monitor operations and make configuration adjustments when necessary.


    Use statistics

    Activities maintains sets of statistics that keep track of usage information. The values for these statistics, and the change in value between the last sample and the current one are maintained in text files. The statistics collected, the frequency with which they are collected, and the text file names all have default settings. You can change the configuration to collect fewer statistics or to change the collection frequency.

    Available statistics include:

    • Number of activities and activity members

    • Number of times that a service was accessed

    • Response times for services

    Activities runs scheduled tasks that save current statistics values. The jobs are defined in the oa-config.xml file. You can edit this file to change the time intervals of the jobs or to change the start times of the jobs.

    Activities runs the following scheduled jobs:

    DatabaseRuntimeStats

    Runs once per hour by default. Its function is to query the Activities database for database related statistics, such as the number of Activities, or number of members.

    30MinStats

    Runs once every half hour by default. Its function is to maintain the current values of the Activities statistics specified in the <stats> element of oa-config.xml to disk.

    DailyStats

    Runs once a day at 11:00 AM by default. Its function is to maintain the current values of the Activities statistics specified in the <stats> element of oa-config.xml to disk.

    By default, the statistics jobs capture some standard statistics defined in the oa-config.xml file. You can edit this file to collect the statistics that best suit your implementation. Activities saves the collected data into files whose names are composed by combining the job name with the following names:

    AddedData.txt

    Collects the number of bytes of data added to the system.

    Average.txt

    Collects the average time required to process a request to a particular Activities service in milliseconds.

    ContentStore.txt

    Collects the content store activity: uploads, downloads, and deletions.

    Counts.txt

    Collects the number of times that a particular service was accessed.

    Current.txt

    Collects information about aspects of the currently running system.

    Events.txt

    Collects the number of errors being reported by the system.

    Totals.txt

    Collects the number of objects in the system.

    For example, the 30MinStats scheduled job maintains files named 30MinStatsAddedData.txt, 30MinStatsAverage.txt, and so on. The DailyStats job maintains files named DailyStatsAddedData.txt, DailyStatsAverage.txt, an so on. Additionally, each file maintained by Activities has an associated delta file that tracks the difference between the previous value of the statistic and the current value. For example: Delta30MinStatsAddedData.txt and DeltaDailyStatsAddedData.txt. There are also average delta files, which track the average time required to process the requests within the collection interval. These are named as follows: Delta30MinStatsAverage.txt and DeltaDailyStatsAverage.txt.

    Statistics text files use a comma separated value (CSV) format. This format enables you to import the files into a spreadsheet, and then compute and chart the values.

    All of the files into which Activities stores data are in the directory referenced by the ACTIVITIES_STATS_DIR WebSphere Application Server variable. The files for the statistics for each server are located in the ACTIVITIES_STATS_DIR/{nodeName}/{serverName} directory. To edit the variable, access the websphere Application Server Integrated Solutions Console, navigate to Environment > WebSphere Variables, and search in the server scope. You can view the current value of the ACTIVITIES_STATS_DIR variable and modify it, if necessary.


    The statistics and what they measure

    The following tables list the statistics available and describe what each statistic represents.

    Table 60. Statistics in jobName Totals.txt file

    Statistic Description
    activities.data.totals.activities

    Number of activities in the database.

    activities.data.totals.entries

    Number of activity entries (for example standard entries, to-do items) in the database.

    activities.data.totals.members

    Number of activity members in the database.

    Table 61. Statistics in jobName Current.txt file

    Statistic Description
    activites.requests.concurrent.max

    Maximum number of simultaneous requests processed by the Activities application since the application was started.

    activities.service.eventqueue.entries.current

    Current number of events waiting to be processed.

    activities.users.active.current

    Number of users that have accessed the Activities application within the last five minutes.

    activities.users.active.max

    Maximum number of users that have accessed the Activities application within a five minute window since the application was started.

    Table 62. Statistics in jobName Events.txt file

    Statistic Description
    activities.fatals

    Number of fatal errors reported by the Activities application since the application was started.

    activities.errors

    Number of non-fatal errors reported by the Activities application since the application was started.

    activities.warnings

    Number of warnings reported by the Activities application since the application was started.

    activities.service.virus.scan.found.count

    Number of viruses removed from content by the virus scanning software configured for the Activities application since the application was started. If virus scanning is not enabled, then zeros (0) are collected for this statistic.

    activities.service.acf.badcontent.found

    Number of instances of active content removed by the Activities application since the application was started. If active content filtering is not enabled for Activities, then zeros (0) are collected for this statistic.

    Table 63. Statistics in jobName Average.txt file (Average time in milliseconds required to process a request to a particular Activities service

    Statistic Description
    activities.service.db.totals.Average

    Average time to complete a database request.

    activities.service.api.totals.Average

    Average time to complete a service request.

    activities.service.directoryprofile.totals.Average

    Average time to complete a directory lookup request.

    activities.service.smtp.totals.Average

    Average time to deposit mail to the SMTP server. If SMTP is not enabled, then zeros (0) are collected for this statistic.

    activities.service.trash.totals.Average

    Average time to purge an activity or activity entry from the trash.

    Table 64. Statistics in jobName Counts.txt file

    Statistic Description
    activities.service.db.totals.Count

    Number of database requests made since the application was started.

    activities.service.api.totals.Count

    Number of service requests made since the application was started.

    activities.service.directoryprofile.totals.Count

    Number of directory lookups made since the application was started.

    activities.service.smtp.totals.Count

    Number of SMTP requests made since the application was started. If SMTP is not enabled, then zeros (0) are collected for this statistic.

    activities.service.trash.totals.Count

    Number of activities or activity entries purged from the trash since the application was started.

    Table 65. Statistics in jobName AddedData.txt file

    Statistic Description
    activities.service.contentstore.filesystem.upload.bytes

    Number of bytes added to the content store by uploaded files.

    Table 66. Statistics in "jobName"ContentStore.txt file

    Statistic Description
    activities.service.contentstore.filesystem.upload.Count

    Number of files uploaded to Activities since the application was started.

    activities.service.contentstore.filesystem.download.Count

    Number of files downloaded from Activities since the application was started.

    activities.service.contentstore.filesystem.remove.Count

    Number of files removed from Activities since the application was started.


    Examples of Activities configuration files

    The following example demonstrates the data that Activities collects by default:

    <stats>
            <!--  Specify where statistics files should be kept. 
             --> 
            <statsDirectory/>${ACTIVITIES_STATS_DIR}</statsDirectory> 
            <stat>
              <fields>
                <field>dates</field> 
                <field>activities.data.totals.activities</field> 
                <field>activities.data.totals.entries</field> 
                <field>activities.data.totals.members</field> 
              </fields>
              <file>Totals.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
              <fields>
                <field>dates</field> 
                <field>activities.requests.concurrent.max</field> 
                <field>activities.service.eventqueue.entries.current</field> 
                <field>activities.users.active.current</field> 
                <field>activities.users.active.max</field> 
              </fields>
              <file>Current.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
              <fields>
                <field>dates</field> 
                <field>activities.fatals</field> 
                <field>activities.errors</field> 
                <field>activities.warnings</field> 
              </fields>
              <file>Events.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
              <fields>
                <field>dates</field> 
                <field>activities.service.db.totals.Average</field> 
                <field>activities.service.api.totals.Average</field> 
                <field>activities.service.directoryprofile.totals.Average</field> 
                <field>activities.service.smtp.totals.Average</field> 
                <field>activities.service.trash.totals.Average</field> 
              </fields>
              <file>Average.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
              <fields>
                <field>dates</field> 
                <field>activities.service.db.totals.Count</field> 
                <field>activities.service.api.totals.Count</field> 
                <field>activities.service.directoryprofile.totals.Count</field> 
                <field>activities.service.smtp.totals.Count</field> 
                <field>activities.service.trash.totals.Count</field> 
              </fields>
              <file>Counts.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
              <fields>
                <field>dates</field> 
                <field>
                  activities.service.contentstore.filesystem.upload.bytes
                </field> 
              </fields>
              <file>AddedData.txt</file> 
              <samples>144</samples> 
            </stat>
            <stat>
                <fields>
                    <field>dates</field>
                    <field>
                      activities.service.contentstore.filesystem.upload.Count
                    </field>
                    <field>
                      activities.service.contentstore.filesystem.download.Count
                    </field>
                    <field>
                      activities.service.contentstore.filesystem.remove.Count
                    </field>
                </fields>
                <file>ContentStore.txt</file>
                <samples>144</samples>
            </stat>
          </stats>
    


    Related tasks

  • Monitor statistics and metrics
  • Define which statistics to collect


    Define which statistics to collect

    Edit configuration property settings to define the statistics that are collected by the server.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    The Activities server collects a specific set of statistics by default. You can change what is collected to better suit the needs of your environment. For example, Activities collects statistics on SMTP server performance. If you are not using an SMTP server, you can prevent its performance from being monitored. For a complete list of the statistics that are collected by Activities by default, see Activities statistics. To define which statistics are collected by the server:

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. From the temporary directory to which you checked out the Activities configuration file, open the oa-config.xml file in a text editor, and look for the <stat> element block.

    3. Make any of the following edits:

      • To stop collecting data on a specific field, remove the <field> element that represents the value that you are not interested in collecting.

      • To change the name of the text file that is created to store the statistical data, edit the attribute of the <file> element.

      • To change the number of versions of results that are maintained from the default value of the 144, edit the <samples> element.

    4. After making your edits, save and close the oa-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 for details.


    Related tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities

  • Activity statistics


    Schedule Activities statistics collection

    Edit configuration property settings to change the frequency and duration of the jobs that collect server statistics.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Use the wsadmin client to access and check out the Activities configuration files.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities configuration files :

        ActivitiesConfigService.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 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:

          ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")

        • Microsoft

          Windows:

          ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")

    2. Display the current configuration settings :

      ActivitiesConfigService.showConfig() 
      From the returned list, look at the current values of the settings that begin with jobs.30MinStats, jobs.DailyStats, and jobs.DatabaseRuntimeStats to determine which property values, if any, you want to change:

    3. You can change the property values :

      ActivitiesConfigService.updateConfig(property, value)
      For example:

      • To change the frequency with which the 30MinStats job runs from every 30 minutes to every 10 minutes, edit the value of the interval attribute . The default value is 0 0/30 * * * ? which specifies that the job should run every 30 minutes.

        ActivitiesConfigService.updateConfig("jobs.30MinStats.interval", "0 0/10 * * * ?")
        If you change the frequency to something other than 30 minutes, keep in mind that the job name will still be 30MinStats and could lead to some confusion.

      • To change the start time of the DailyStats job from 11 AM to 1 AM, edit the value the interval attribute . The default value is 0 0 11 * * ? which specifies that the job should run daily at 11 AM.

        ActivitiesConfigService.updateConfig("jobs.DailyStats.interval", "0 0 1 * * ?")

      • To change the frequency with which the DatabaseRuntimeStats job runs from once every hour to once every 45 minutes, edit the value of the interval attribute . The default value is 0 0 * * * ?, which specifies that the job should run once every hour, on the hour.

        ActivitiesConfigService.updateConfig("jobs.DatabaseRuntimeStats.interval", "0 0/45 * * * ?")
      For information about how to format the value of the interval attribute, see Scheduling tasks.

    4. Optional: If you want to prevent the statistics collection job from running altogether, you can use the following commands to disable the jobs:

      ActivitiesConfigService.updateConfig("jobs.30MinStats.enabled", "false")
      ActivitiesConfigService.updateConfig("jobs.DailyStats.enabled", "false")
      ActivitiesConfigService.updateConfig("jobs.DatabaseRuntimeStats.enabled", "false")

    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 for details.


    Example

    <scheduledTasks>
            <!-- DatabaseRuntimeStats - every hour  -->
            <task 
             name="DatabaseRuntimeStats" 
             description="Actvities Database Statistics Collector Service"
             interval="0 0 * * * ?" 
             startby="" 
             enabled="true" 
             scope="cluster" 
             type="class"
             targetName="com.ibm.openactivities.jobs.DatabaseStatisticsCollectorJobWS" 
             mbeanMethodName="" 
             serverName="unsupported" >
            </task>
    
            <!-- local scoped jobs -->
             
            <!-- DailyStats - every day @ 11 am -->
            <task 
             name="DailyStats" 
             description="Activities Daily Statistic Collector Service"
             interval="0 0 11 * * ?" 
             startby="" 
             enabled="true" 
             scope="local" 
             type="class" 
             targetName="com.ibm.openactivities.jobs.StatsPersistJobWS" 
             mbeanMethodName="" 
             serverName="unsupported" >
            </task>
                       
            <!-- 30MinStats - every 30 min  -->
            <task 
             name="30MinStats" 
             description="Activities 30 Minute Statistic Collector Service"
             interval="0 0/30 * * * ?" 
             startby="" 
             enabled="true" 
             scope="local"  
             type="class"
             targetName="com.ibm.openactivities.jobs.StatsPersistJobWS" 
             mbeanMethodName="" 
             serverName="unsupported" >
            </task>
    </scheduledTasks>


    Related

  • Schedule tasks

  • Check out the Activities configuration files
  • Apply property changes in Activities
  • Manage the scheduler

    Manage the scheduler

    Use administrative commands to manage scheduled tasks in Activities.

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

    To manage a task:

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.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 Activities scheduler service.

      ActivitiesScheduler.getTaskDetails(java.lang.String taskName)

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

      • "30MinStats"

      • "ActivityAutoCompleteJob"

      • "DailyStats"

      • "DatabaseRuntimeStats"

      • "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:

      ActivitiesScheduler.getTaskDetails("TrashAutoPurgeJob")
      The resulting output looks 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=TrashAutoPurgeJob}

      ActivitiesScheduler.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 Activities or the IBM WebSphere Application Server. You must run the ActivitiesScheduler.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:

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

      [2/10/10 15:28:26:354 EST] 00000659 ActivitiesNot I   
      CLFWY0134I: Activities scheduled task 'TrashAutoPurgeJob' fired event 
      'TaskNotificationInfo.SUSPENDED'
      When the task is paused successfully, a 1 is returned to the wsadmin client. When the task is not paused successfully, a 0 is returned.

      ActivitiesScheduler.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:

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

      [2/10/10 15:49:12:198 EST] 00000633 ActivitiesNot I   
      CLFWY0134I: Activities scheduled task 'TrashAutoPurgeJob' fired event 
      'TaskNotificationInfo.RESUMED'
      When the task is resumed successfully, a 1 is returned to the wsadmin client. When the task is not resumed successfully, a 0 is returned.


    Related tasks

  • Start the wsadmin client
  • Complete activities that are not being used
  • Schedule Activities statistics collection
  • Empty the Activities trash on a schedule

    Export activities

    Use administrative commands to export activities.

    If you want to transfer standard activity content from one system to another, you can export the activities to an external directory and then import them to the new system. This does not apply to community activities. You can only import community activities to the same deployment from which they were exported. See Importing activities for information on importing.

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

    The data associated with the Activities application is stored in more than one place. For standard activities the activities and the member information associated with them are stored in the Activities database tables. For community activities, the activities themselves are stored in the Activities database tables and the member information is stored in the Communities database tables. For both activity types, any file attachments that are added to activities are stored in the content store on the file system. When you run the export process to export activities, it collects the data from all of these locations and stores it in one ZIP file per activity. To export activities:

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.py")
        The command in this procedure writes information to a file. If prompted to specify a service to connect to, specify the node where the file to write to is stored.

    2. Use one of the following commands to get a list of activities to export:

      • To get a list of all the activities from the Activities server and save them as a java.util.Vector variable that you can pass to the export command, use the following command:

        variable=ActivityService.fetchActivities()
        For example:

        allexports=ActivityService.fetchActivities()

      • To filter the activities to export to a subset of activities created within a specific time period, use the following command:

        variable=ActivityService.fetchActivitiesByDate(java.lang.String dateType, 
         java.lang.String beginTime, java.lang.String endTime, java.lang.String 
         lastUUID)
        For example, to get all of the activities created in September, use the following command:

        sept=ActivityService.fetchActivitiesByDate("created", "2008.09.01", "2008.09.30", "")

        This command does not return activity templates that were created during the specified date range, but does include in the activities that it returns any activities present in the Trash view that were created during the specified date range.

      • To filter the activities to export to a subset based on their members:

        1. Identify the member of interest and save the member information to a variable :

          variable=MemberService.fetchMemberByName(java.util.Hashtable member)
          For example:

          john=MemberService.fetchMemberByName("John Smith")

        2. To retrieve a subset of activities that were created by the member and save it to variable, use the following command:

          variable=ActivityService.fetchActivitiesCreatedByMember(java.util.Hashtable member)
          For example:

          johnsactivities=ActivityService.fetchActivitiesCreatedByMember(john)
          Alternatively, you can create the following subsets of activities. Note that these commands only return standard activities; they do not return community activities:

          • To get a list of all the standard activities to which the member has access:

            variable=ActivityService.fetchActivitiesByMember(java.util.Hashtable member)

          • To get a list of all the standard activities that the member owns:

            variable=ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)

      • To get a list of community activities to export, complete the following steps:

        1. Search by name for the community that owns the activities that you want to export :

          ActivitiesMemberService.fetchCommunitiesByName(java.lang.String name)
          For example:

          communities=ActivitiesMemberService.fetchCommunitiesByName("sales")

        2. From the list of communities returned, find the community of interest and make a note of its unique ID.

        3. Pass that unique ID into the following command to write the activities associated with the community to a java.util.Vector variable that you can later pass to the export command:

          ActivityService.fetchActivitiesByCommunityExId(java.lang.String communityUuid)
          For example:

          communityActivitiesToExport=ActivityService.fetchActivitiesBy communityExId(
          "f29b4e8e-6fad-44f4-9fca-58c46f29c38d")

    3. Use the following command to export the activities:

      ArchiveService.exportActivities(java.lang.String export_directory, java.util.Vector activities)

      ...where:

      • export_directory is the directory path in which you want the activities which are exported as ZIP files to be stored. This directory must exist on the server that you were prompted to provide after running the execfile command to access the activitiesAdmin.py file.

      • activities is the java.util.Vector variable you created to define the activities to export.
      For example:

      ArchiveService.exportActivities("c:/ActivitiesExports",allexports)
      or to export only John's activities:

      ArchiveService.exportActivities("c:/ActivitiesExports",johnsactivities)
      or to export only the activities created in September:

      ArchiveService.exportActivities("c:/ActivitiesExports",sept)
      or to export the community activities:

      ArchiveService.exportActivities("c:/ActivitiesExports",communityActivitiesTo export)


    Results

    If the export is successful, one ZIP file is created in the export repository for each activity being exported, and the wsadmin client returns an empty set of brackets. If one of the activities cannot be exported, information about it is returned to the wsadmin client's command line. Refer to the SystemOut.log file to find log messages that are written to it from the export process.


    Related tasks

  • Start the wsadmin client
  • Get a list of activities

  • Activities administrative commands

    Import activities

    Use administrative commands to import activities that you exported.

    You can import only activities that you exported from the Activities application. See Exporting activities.

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

    1. Start the Activities Jython script interpreter.

      1. Use the following command to access the Activities configuration file:

        execfile("activitiesAdmin.py")
        The command in this procedure reads information from a file. If prompted to specify a service to connect to, specify the node where the file to read from is stored.

    2. Do one of the following actions:

      • If you want to import all of the activities that you exported, use the following command to retrieve the activities that you exported and save them as a java.util.Vector variable:

        variable=ArchiveService.fetchActivities(java.lang.String export_directory)

        ...where export_directory is the file path, including the drive and subdirectory, on the local server where the previously exported ZIP files are located. When specifying a path separator, use the forward slash rather than backslash even on Microsoft Windows systems. For example:

        allexports=ArchiveService.fetchActivities("C:/AllExports")

      • If you want to filter the activities that you exported into a subset based on a member:

      1. To identify a subset of activities that were created by a specific member, use the following command:

        variable=MemberService.fetchMemberByName(java.util.Hashtable member)
        For example:

        jane=MemberService.fetchMemberByName("Jane Doe")

      2. To retrieve a subset of activities that were created by the member from the repository of exported activities and save it to variable, use the following command:

        Do not use these member-based commands to fetch activities that were exported from a different deployment of IBM Connections. These commands use the member ID to find the activities, and member IDs are not persisted across different deployments. Use these commands only to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.

        variable=ArchiveService.fetchActivitiesCreatedByMember(java.lang.string export_directory,java.util.Hashtable member)
        For example:

        janesactivities=ArchiveService.fetchActivitiesCreatedByMember("C:/AllExports",jane)
        Alternatively, you can create the following subsets of activities. Note that these commands only return standard activities; they do not return community activities.

        • To retrieve a subset of standard activities to which a specific member has access from the repository of exported activities and save it to a variable, use the following command:

          variable=ArchiveService.fetchActivitiesByMember(java.lang.string export_directory,java.util.Hashtable member)

        • To retrieve a subset of standard activities that a specific member owns from the repository of exported activities and save them to a variable, use the following command:

          variable=ArchiveService.fetchActivitiesByOwner(java.lang.string export_directory,java.util.Hashtable member)

    3. Optional: Only perform this step if you want to delete a subset of the activities. You might want to perform this step if an employee has exited the company and you want to remove the activities that she owns from the collection before you import them.

      To delete a set of activities from the collection of exported activities, use the following command:

      ArchiveService.deleteActivities(java.lang.String export_directory, java.util.Vector subset_of_activities)

      ...where subset_of_activities is the java.util.Vector variable you created to define a subset of activities that you retrieved from the export directory and to permanently delete. For example, to remove Jane's activities from the collection of exported activities, you could use the following command:

      ArchiveService.deleteActivities("C:/AllExports",janesactivities)

    4. Use one of the following commands to import the activities:

      For community activities, the community from which the activity was created must exist on the server to which you are importing the activities. If it does not, an error is returned when you attempt to import the activities. The associated community is identified by its communityUUID which is not persisted across different deployments, so you can only include community activities in the activities to be imported when you are importing them to the same server from which they were exported.

      • If you do not want to overwrite any of the activities currently on the server and would rather create an additional copy of an activity if you are importing one that already exists, use this command:

        ArchiveService.createActivities(java.lang.String export_directory, java.util.Vector activities)

        ...where activities is the java.util.Vector variable you created to define the activities that you retrieved from the export directory and to import into the Activities application. For example:

        ArchiveService.createActivities("C:/AllExports",allexports)
        or to import only Jane's activities:

        ArchiveService.createActivities("C:/AllExports",janesactivities)

      • Use the following command to import the activities from the export repository. If the activities being imported already exist on the Activities server, the ones on the server will be overwritten during the import.

        ArchiveService.importActivities(java.lang.String export_directory, java.util.Vector activities)

        ...where activities is the java.util.Vector variable you created to define the activities that you retrieved from the export directory and to import into the Activities application. For example:

        ArchiveService.importActivities("C:/AllExports",allexports)
        or to import only Jane's activities:

        ArchiveService.importActivities("C:/AllExports",janesactivities)


    Results

    If the import is successful, one activity is created from each ZIP file in the export repository and the wsadmin client returns an empty set of brackets. If one of the activities cannot be imported, information about it is returned to the wsadmin client's command line. Refer to the SystemOut.log file to find log messages that are written to it from the import process.


    Related tasks

  • Start the wsadmin client

    Administer Blogs

    Administer site-wide settings for Blogs from either the Blogs user interface or via the wsadmin client.

    You can make site-wide changes to Blogs from the Administration link in the Blogs user interface, or via commands using the wsadmin client. Unlike other IBM Connections applications, Blogs does not use an XML file to store configuration settings. Blogs configuration information is stored in, and accessed from, the Blogs application database. As a result, a configuration change is reflected in real-time, and does not require a restart of the Blogs server.

    The following topics describe administering blogs from the UI or from the wsadmin client.

    Administer Blogs from the User Interface

    Make site-wide changes on your Blogs server from the Blogs UI.

    As the Blogs administrator, you can make site-wide changes to the blogs for your organization directly from the Blogs user interface. To do so you must browse to the Blog site using a URL similar to: http://BlogServerName/blogs. Once the site opens, login as an Administrative user. After login, click the Administration tab. This page allows you to make site-wide configuration changes.

    From this location you can:

    • Specify settings for the Blogs home page

    • Specify settings for what blog creators can do . for example, whether they can apply custom themes or specify trackback links

    • Administer users.

    • Manage the cache


    Configure an administrator for Blogs

    By default, a wsadmin account is set to administer Blogs. Use this procedure to designate a Blogs administrator that you specify.

    IBM Connections administrators must be dedicated users. Their only purpose should be application administration.

    Only a Blogs administrator can configure a Blogs Homepage blog, which is required for Blogs. See Managing the Homepage blog.

    You can also create administrators to managing application content. See the topic Administering application content.

    Create administrators in the WebSphere Application Server Integrated Solutions Console.

    To configure administrative access to an application, complete the following steps:

    1. From the WebSphere Application Server Integrated Solutions Console, select Applications > Application Types > WebSphere enterprise applications.

    2. Find and click the link to the application that you want to configure. For example, click Blogs.

    3. Click the Security role to user/group mapping link.

    4. To map a user to the administrative role, select the check box beside the admin role and then click Map Users.

    5. In the Search String box, type the name of the person whom you would like to set as an administrator, and then click Search. If the user exists in the LDAP directory, it is found and displayed in the Available list.

    6. Select the name from the Available box, and then move it into the Selected column by clicking the right arrow button.

    7. Repeat Steps 4 and 5 to add more users to the administrative role.

    8. Click OK.

    9. From the Enterprise Applications > Blogs > Security role to user/group mapping page, click OK, and then click Save to save the changes.

    10. Synchronize and restart all your WebSphere Application Server instances.


    Manage the Blogs Homepage blog

    The Blogs Homepage blog serves as the main page for your Blogs deployment and has some special considerations.

    When you deploy Blogs, a Blogs Homepage blog with the theme Blogs Homepage theme is created to serve as the entry point for the blogs site. This type of blog is only available to an administrator. You can edit settings for this blog, such as the name or how many entries to display, on the Configuration tab of the Administration page. You can also customize the theme of the Homepage blog to change the look for the blog. For example, you can change colors or add a logo to make it more consistent with your organization.s branding elements.


    Specify site-wide setting for Blogs

    Specify site-wide setting for all blogs in your organization. Sets you specify for the site control what users are allowed to do when they create or use blogs. You must be logged in as an administrator to change site-wide settings.

    1. From the Blogs home page, click the Administration tab.

      You must be logged in as an administrator to see the Administration tab.

    2. Click the Configuration link.

    3. Modify any of the following settings for the site:

      Table 67. Site-wide settings for Blogs

      Set Description Default values
      Site name (for Blogs Homepage and feed) Set the full name for the main page of the site. This name will also be used in feeds. Blogs
      Blog title (shown in site banner) The blog title is displayed in the site banner. Blogs
      Site description (for Blogs Homepage and feed) Enter a description that describes the purpose of the Blogs site. <blank>
      Handle of blog to serve as Blogs Homepage The handle is a short name used in the URL for the Blogs site. The Homepage Blog is created automatically when Blogs is installed. The theme for this blog is Blogs Homepage Theme. You can customize the look of this theme from the Blogs Homepage Theme page. homepage
      Enable active content filtering When enabled, unsafe HTML is removed from Blog posts. Active content filtering does not scan attached files. Be sure to scan files before uploading. Disabling introduces vulnerability to malicious cross-site scripting (XSS) attacks. Enabled
      Automatic save when editing (minutes) This option is to allow automatically save unsaved entries to prevent data loss. For new entries and draft entries, Blogs will save the current content in the editor every # minutes according to this setting.

      Make sure the autosave interval is less than the interval set for user session timeout or you will get an error notification that autosave failed.

      15
      Number of entries to display in Blogs Homepage This setting controls the maximum number of public blog entries that will be listed on the Blogs Homepage. 25
      Max number of entries to allow per page The maximum number of blog entries that will be listed on the blog site. If there are more than the specified number of entries to display, Previous / Next links are provided on the list for navigation. 50
      Number of entries to provide in newsfeeds The maximum number of feeds that will be available to a feed reader at any given time. 50
      Allow blog comments Allows any authenticated user to post a comment in response to a blog entry. Enabled
      Allow blog trackbacks (Inbound) Allows entries from other blogs to be posted to a blog on this site. Enabled
      Allow blog trackbacks (Outbound) Allows blog entries to be posted as comments in other blogs. Enabled
      Email notification of comments Allows blog entry creators to receive notifications when a new comment has been posted to their entries. Rather than periodically checking their blog for new comments, the entry creator automatically receives an email. If comments for the blog are moderated, an email is sent to the blog entry creator when a new comment is posted. In addition to enabling this setting, mail must also be configured during installation. See the Configuring Blogs topic in the Installation section for details on configuring mail service.

      If you enable this application, blog owners can still turn it off for their blogs, but if it is disabled, blog owners do not see an option for email notification of comments.

      Disabled
      Enable file uploads Allow a blog owner to upload files to be used on their blog. By default, Active Content Filtering scans file attachments that have a HTML, HTM or JS file extension. Be sure to scan files with other file extensions before uploading them. Enabled
      Allowed extensions A comma-separated list of the file types that are allowed to be uploaded. If this field is blank, all file extensions are allowed. Separate extensions with commas. jpg,jpeg,gif,png
      Forbidden extensions A comma separated list of file types that are not allowed to be uploaded. <blank>
      Max file size (MB) Maximum size of an uploaded file. 1.00 MB
      Max directory size (MB) Maximum storage space allocated per blog for uploading files. 4.00 MB
      Allow custom themes There are several templates provided that can be used to set the look of a blog. Allowing blog owners to customize themes lets them modify the templates of an existing theme to create a unique customized theme. We recommend you leave this option disabled. Disabled

    4. After making your changes, click Save to save your settings. You do not need to restart Blogs to see the configuration changes.

    5. If you want to customize the look and layout of your Blogs site, click Blogs Homepage Theme and edit the template files that make up the theme for the Blogs Homepage. You should be comfortable editing HTML files and cascading style sheets (CSS files) to modify a blog theme. For details about how to customize a theme, including a description of the standard theme files, see the topic Customize a blog theme.


    Manage a community blog

    After you add a blog to a community, you can manage the blog from either the community or from the My Blogs page of the Blogs application. However, you can only manage membership from the community. If you are editing the settings for a community blog, you can manage all settings except for membership and theme. If you choose Sets for a community blog, and click the Authors tab, you will be directed back to the community to manage the membership with one of these options:

    • You can change membership for this blog, go to Members page for the community.

    • You can change a member's role, go to the Edit Community form.
    Community blog membership is tied to the community membership, so you must manage it from the community. When you first create a community blog, all members of the community are granted author access by default. Depending on your community, you might want to change the access level for your members. Note that access is always community-wide. Community owners are always blog owners and have full access to post entries as well as to manage the blog and its users. All other community members can have one of the following roles:

    Table 68. Community blog roles

    Role Description
    Author Allows user to post entries, but not to manage the blog. Users with this role can also edit and delete other users' entries.
    Draft Allows user to save draft entries only.
    Viewer Allows users to read blog posts but not to contribute to the blog.
    In addition to managing access to the community blog, you can also hide blog activity or delete the blog from the community.

    1. To edit basic information about the blog, click Edit from the action menu for the Blogs widget.

      1. Edit any of the basic information about the blog, such as its title or description.

      2. Change whether all community members will have author, draft, or viewer membership.

      3. Choose whether comments will be moderated. Moderated comments are saved into a draft state until you approve them for posting to the blog.

    2. To add or remove a blog member, you need to add or remove that person from the community membership. You can do this on the community's Members page.

    3. To expand the widget content, select Maximize from the action menu. To collapse the widget content, select Minimize from the action menu.

    4. To hide the blog, choose Hide from the action menu and confirm to temporarily remove the blog from the community. When you are ready to resume blog activity, click Customize and add the blog back from the Hidden section of the content palette. All content is restored.

    5. To delete the blog and all of its content, choose Delete from the action menu and confirm to permanently remove the blog.

    6. To refresh the community blog and see all of the latest activity, choose Refresh from the action menu.


    Administer Blogs users

    As the site administrator, you can directly manage a user's blog. You can select a user and view or edit their blogs. You have the control to remove objectionable material from your site or make changes to any blog on your site.

    1. From the Blogs home page, click the Administration tab.

    2. Click the Administer Users link.

    3. Type or select a user name and click the Edit button.

    4. Do any of the following:

      • Click a blog name to open the blog.

      • Click New Entry to add an entry to a blog.

      • Click Edit Entries to view and manage entries for the blog.

      • Click Manage to view and edit the settings for the blog or delete blogs.

    5. Click Return to Administer Users when you are done on this page.


    Monitor the Blogs Cache Information

    The Blogs cache page is a central place where you can monitor the caches for your site. You can view information about the caches or clear the caches for your site.

    1. From the Blogs home page, click the Administration tab.

    2. Click the Cache info link. Information is displayed about each cache.

    3. Click Clear if you want to clear a cache.

    Administer Blogs using the wsadmin Client

    As an alternative to modifying the Blogs site settings from the Blogs user interface via the Administration tab, you can also modify settings using the wsadmin client.

    Blogs site-wide configuration information is stored in the Blogs database, rather than in an XML file. Therefore, you do not need to check out (or check in) the Blogs site-wide configuration file because any configuration changes you make are written directly into the database.

    You use the BlogConfigService.showConfig and BlogsConfigService.updateConfig commands to view and make site-wide configuration changes to Blogs configuration settings. Changing a Blogs site-wide configuration setting from the wsadmin command session requires the following procedures:

    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. 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. See the topic Starting the wsadmin client.

    2. Start the Blogs Jython script interpreter by entering the following command:

      execfile("blogsAdmin.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 view the current values of the editable configuration property keys for Blogs, use the following command and note its output. The following output is a sample; your output may differ.

      BlogsConfigService.showConfig()
      
      Blogs configuration properties:
      	ACFEnabled = true
      	CustomThemeAllowed = false
      	EditingPollInterval = 15
      	InboundTrackBacksEnabled = True
      	OutboundTrackBacksEnabled = True
      	SiteDescription =
      	SiteFrontPageweblogHandle = home
      	SiteName = Blogs Home
      	SiteNewsFeedsDefaultEntries = 30
      	SitePagesMaxEntries = 30
      	SiteShortName = Blogs Home
      	UploadsDirMaxSize = 4.0
      	UploadsEnabled = true
      	UploadsFileMaxSize = 1.0
      	UploadsTypesAllowed = jpg,jpeg,gif,png,
      	UploadsTypesForbid =
      	UsersCommentsEmailNotify = true
      	UsersCommentsEnabled = true
      	UsersModerationRequired = false

    The following tables list the commands available for changing Blogs configuration settings. To change a setting, enter the appropriate property and a new value into the following command:

    BlogsConfigService.updateConfig("[property]", "[value]")

    ...where:

    • [property] is a valid blogs configuration setting

    • [value] is the new value for the setting.
    Example: wsadmin>BlogsConfigService.updateConfig("EditingPollInterval", "20")

    Configuration updates take effect immediately and do not require a server restart.

    Table 69. General site properties

    Option Type Description UI Field Equivalent
    SiteName String Updates the name of the site (displayed on the front page) Site Name
    SiteShortName String Updates the name used for the page tab in browsers Short name
    SiteDescription String Updates the site description (used on the front page) Site Description
    SiteFrontPageweblogHandle String Updates the handle of the blog home page Handle of blog to serve as frontpage blog
    ACFEnabled String Turns on / off the Active Content Filter (The Active Content Filter removes unsafe HTML from Blog posts that could be used for a XSS attack.) Valid values are: true or false. Enable active content filtering
    EditPollInterval Integer Automatically saves content in the editor when a user is creating an entry or a comment. Set this to the number of minutes between saves. Automatic save when editing (minutes)

    Table 70. Blog rendering properties

    Option Type Description UI Field
    SitePagesMaxEntries Integer Maximum number of posts that a blog can have on its home page Max number of entries to allow per page
    SiteNewsFeedsDefaultEntries Integer Maximum number of posts that can be in a blogs feed Number of entries to provide in newsfeeds

    Table 71. Comment and trackback properties

    Option Type Description UI Field
    UsersCommentsEnabled String Turns on and off the ability to add any comments in the site. Valid values are: true or false. Allow blog comments
    TrackBacksEnabled String Turns on and off the ability to add any trackbacks across the site. Valid values are: true or false. Allow blog trackbacks
    UsersCommentsEmailNotify String Whether users can get email notifications when comments are added to their blog. Valid values are: true or false. Email notification of comments
    UsersModerationRequired String Indicates whether comments always require moderation before being added to a blog. Valid values are: true or false. Require comment moderation for all blogs

    Table 72. Upload capability properties

    Option Type Description UI Field
    UploadsEnabled String If enabled, file uploads are allowed for this site. Valid values are: true or false. Enable File Uploads
    UploadsTypesAllowed String Comma delimited list of allowed file type extensions. Only files with these extensions are allowed to be uploaded Allowed Extensions
    UploadsTypesForbid String Comma delimited list of file type extensions that are not permitted. Files with these extensions are not allowed to be uploaded. Forbidden Extensions
    UploadsFileMaxSize Double Maximum file size that can be uploaded by any user Max File Size (MB)
    UploadsDirMaxSize Double Maximum size of total uploaded file directory for a given blog Max Directory Size (MB)

    Table 73. Theme property

    Option Type Description UI Field
    CustomThemeAllowed String Determines if custom themes are allowed. Valid values are: true or false. Allow Custom Themes


    Related

  • Administer the Home page using the wsadmin client

  • Start the wsadmin client
  • IBM Connections configuration property values


    Specify an administrator email address for Blogs notifications

    Edit configuration property settings to change the administrator email address for notifications. This is the address used to send system notifications, such as notifications sent to users who have posted inappropriate content.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    By default, automatic notifications are sent from a generic email address, such as blogs-admin@example.com. If Connections is configured so that email addresses are not displayed, you can set a global sender email address for all notification templates, as described in the topic Defining a valid global sender email address. If email addresses are displayed, the global sender is ignored. In either case, you should add a specific administrator email address that has access rights to send mail for several notification templates that are used in the workflows for managing content that is flagged as inappropriate. Some of the messages sent automatically instruct the recipient that they can respond to the administrative user email address from which the notification was sent. If you do not edit the default email address, the recipient gets a delivery failure notification when they try to respond to the automatic email.

    To specify an administrator email address for managing flagged content, complete the following steps:

    1. Check out the notification-config.xml file :

      LCConfigService.checkOutNotificationConfig("<temp_dir>","<cell_name>")

      ...where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell where you installed Blogs.

    2. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.

    3. Search for the <source name="Blogs" string to find the section that defines the notification settings for the Blogs application.

    4. To configure an administrative email address for handling flagged content in a blog, add or change the value of the sender attribute to a legitimate email address in the <type> elements that have the following name attribute values:

      • confirmflagged

      • notifyflagged

      • notifyquarantined

      • notifyedit
      For example:

      <type name="notifyFlagged" notificationType="MODERATION">
      	 <channel name="email" enabled="true">
      	  <property name="sender">moderation-admin@example.com</property>
      		<property name="ftl">notifyflagged.ftl</property>
      	 </channel>
      	<channel name="event" enabled="true">
      	 <property name="eventName">moderation.notification.notifyflagged</property>
      	 <property name="transformerClass">com.ibm.lotus.connections.core.notify.channels.event.ModerationNotificationEventTransformer</property>
      	</channel>
      		</type>

    5. Save and close the notification-config.xml file.

    6. Check in the configuration files :

      LCConfigService.checkInNotificationConfig("<temp_dir>", "<cell-name>")

    7. Restart the Blogs server for the changes to take effect.


    Related tasks

  • Manage content moderation and flagged content
  • Define valid administrator email addresses
  • Moderate Blog comments


    Change the blog handle

    Run a command to change your blog handle. The blog handle displays in the URL for your blog.

    .

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Start the wsadmin client following the steps in Administering Blogs using the wsadmin Client.

    2. Start the Blogs Jython script interpreter by entering the following command:

      execfile("blogsAdmin.py")

    3. Run the following command to replace the blog handle:

      BlogsAdminService.renameWeblogHandle("<old_handle>", "<new_handle>")

      ...where old_handle is the blog handle that need to be replaced, and wherenew_handle is the new handle for the blog.


    Replace URLs in Blogs

    Run a command to replace URLs in your Blogs deployment to correct broken links.

    .

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. There are cases where a collection of URLs in a Blogs deployment will break. For example, if a user changes from one deployment to another and the host name changes from lc95.cn.ibm.com to lc96.cn.ibm.com, all the URLs that use the form http://lc95.cn.ibm.com/xxx will break. Use this command to update URLs in the following places:

    • Entry and comment content, including the URL for an image source, links to web pages, and video sources.

    • Trackback URLs in comments.

    • Links in the content of an autosaved entry or comment.

    1. Start the wsadmin client following the steps in Administering Blogs using the wsadmin Client.

    2. Start the Blogs Jython script interpreter by entering the following command:

      execfile("blogsAdmin.py")

    3. Run the following command to fix broken URLs in entries and comments:

      BlogsAdminService.fixBrokenUrls(<replacePattern>, <replaceValue>)

      ...where <replacePattern is the pattern of the part of the URLs that need to be replaced, and

      ...wherereplaceValue is the string to correct the URLs.

      For example:

       BlogsAdminService.fixBrokenUrls("http://example.com:9082/blogs", "http://example.com:9080/blogs")
      changes URLs with the form http://example.com:9082/blogs/xxx to http://example.com:9080/blogs/xxx.


    Related tasks

  • Change application URLs


    Restore a Community Blog after a Communities database failure

    If the Communities database fails and is restored from a backup, you can restore the Blogs widget and delete any orphaned data.

    When the Communities application experiences a database failure that involves restoring to a backup without replaying the transaction log to the point of failure, the remote data, such as the data associated with a community blog, needs to be restored as well. You can follow a number of steps to ensure a consistent data state for communities and their associated remote applications. You may need to run an admin command to restore community blogs. Restoring a blog will restore the content. If there is any orphaned data, you use another command to delete the orphaned data. The process for recovering remote application data such as a blog after a Communities database failure, is described in the topic Recovering from a database failure.


    Related

  • Recover from a database failure

  • Maintain application DBs

    Moderate blog content

    Monitor and control the content of blogs using the moderation tools.

    Moderation allows you to review and manage content so that you can approve content before it gets published or you can review published content and remove content you find inappropriate.

    If the Moderation service is installed and enabled, then Blogs are moderated from a central interface, along with content from forums and community files. In that case, the Blogs moderation page is unavailable and notification is disabled. If the Moderation service is not enabled, you can moderate Blogs content from a page in the Blogs interface.


    Who manages moderation?

    As a Connections administrator, you control how moderation is managed. These are the types of users involved in moderation:

    • All users can:

      • Flag published content that is inappropriate

      • Submit content for review.

      • View their own submitted, rejected, or published content.

      • Edit their own published content.

    • Moderators can:

      • Approve or reject submitted content or comments

      • Provide an explanation to the author when rejecting content

      • View and directly edit submitted content or comments

      • Remove published content from the site.

      • Send a message to the author about submitted content or comment

    • Moderators and Content Reviewers can:

      • Dismiss content or comments flagged by end users

      • Provide an explanation to the author when quarantining content

      • View and directly edit published content or comments

      • Quarantine published content so it is no longer available to site users

      • View how many users have flagged a piece of content

      • View the names of users who have flagged a piece of content

      • Sort by update date

    • Administrators can:

      • Enable or disable moderation for content before it is published and after it is published.

      • Assign the moderator role to users so they can moderate content.

      • Set up categories and route which moderators see what flagged content.


    Related tasks

  • Manage content moderation and flagged content

  • Roles


    Moderate Blog comments

    Configure content moderation to enforce it at the site level, or leave it as an option for blog owners.

    There are three ways to enable comment moderation.

    • Comment moderation can be forced at the site level so that all comments posted require the blog owner's review and approval before they are posted. When enforced at the site level, the option to enable it is not available to the blog owner.

    • Comment moderation can also be optional by choosing not to force at the site level, and instead allowing each blog owner to select the option to moderate comments posted to their blog. Blog owners can specify comment moderation for the their blog from the My Blogs page by clicking Sets and checking Moderate comments on the page for general settings.

    • You can configure content moderation in the contentreview-config.xml file. If you enable pre-moderation, that is, moderation for content that has not yet been published in the blog, the setting will override both the site-wide and the individual blog settings. To disable comment moderation in this case, you would have to disable the pre-moderation (contentApproval) setting in the contentreview-config.xml file and disable the site-wide setting for comment moderation. For details, see the topic Managing content moderation and flagged content.

    If you are enforcing comment moderation, follow the steps in the topic Specifying an administrator email address for Blogs notification to edit configuration property settings to change the administrator email address. Moderated comment notifications will be addressed from this email address. By default, notifications are sent from a generic email address, such as blogs-admin@example.com. Edit the property to change this to a legitimate administrator email address that has access rights to send mail. Follow these steps to enforce comment moderation at the site level.

    1. Login as Site Administrator and go to the Administration tab.

    2. In the Comment and Trackback Sets section of the Configuration page, check Require comment moderation for all blogs.

    3. Click Save. No restart is required.


    Related tasks

  • Manage content moderation and flagged content
  • Specify an administrator email address for Blogs notifications


    Moderated content states for blogs

    When blog content is moderated, it can be in a variety of states before and after being published.

    The state that content is in dictates

    ...where it is in the pre-moderation or post-moderation workflow and controls whether the content is available to users or unavailable because it has not been approved or is in quarantine.


    Content states before publication

    Blog content that requires review and approval before it is published can be in one of the following states:

    • Pending (Require approval): The moderator can approve or reject the content.

    • Active (Published)

    • Rejected


    Content states after publication

    Content that has already been published but requires review, for example, if it was flagged as inappropriate, can be in one of the following states:

    • Awaiting decision: The content is in an active state but it may be flagged for review. The moderator can dismiss flags or quarantine the content.

    • Quarantined: The content is unavailable to end users. The moderator can restore the content or return the content to the author.

    • Returned to Author: (Blog only) Authors can edit and resubmit the content for review.

    • Approved: The content is published.


    Example

    This is an example of how moderation might work for a site where moderation is required and you have assigned a user (ModeratorA) the moderator role.

    • ModeratorA logs into Blogs and navigates to the Moderation page.

    • She navigates to the .Require Approval. page where she sees a list of content submitted by users that need to be reviewed. She sees some spam comments which she selects and deletes.

    • ModeratorA sees a blog entry submission that is unrelated to the purpose of the blog. She suspects that the author may have accidentally posted to the wrong blog. She rejects the content and notifies the author that the submitted post is unrelated to the topic of the blog.

    • There are some new blog posts from regular members that she quickly scans and approves. The approved posts are now published and visible to other users.

    • She finds a blog entry that refers to several internal project code names used within her company. She returns the entry back to the author and asks for the code names to be replaced with the actual product names.

    • Finally, ModeratorA reviews the moderated comments. She finds several comments made by public users that contain inappropriate language, so she deletes them.


    Related tasks

  • Manage content moderation and flagged content


    Manage moderated blog entries and comments

    Centrally manage blog entries and comments for a moderated blog before the content is published to a blog, or when the published content is updated. If moderation is enabled for Blogs, moderators can review and approve comments and entries from a central location. You can configure who can review and approve content through the J2EE moderator role in the WAS admin console. All users assigned the J2EE moderator role can manage entries and comments for all blogs on the site. You can also configure who can review and approve content with a setting in the contentreview-config.xml file as follows:

    • If ownerModerate=true in contentreview-config.xml, all owners can moderate the blogs they own.

    • If ownerModerate=false in contentreview-config.xml, only users assigned the J2EE moderator role can manage entries and comments for all blogs on the site.

    1. From the Blogs home page, click the Moderation tab.

    2. Click the Entry Approval or the Comment Approval link in the navigation pane to review entries or comments. The following tabbed views let you review and manage content:

      • All displays all entries or comments for the site.

      • Require Approval display entries or comments awaiting your action.

      • Published displays all entries or comments published to a blog.

      • Rejected displays all entries or comments not approved for publishing to a blog.

    3. To filter the list of entries or comments in any of the views, do one of the following and then press Filter.

      • Enter a tag and click the search icon to search for contents associated with that tag.

      • Enter a start and end date to display content entered in that range.

    4. From the Require Approval tab, select one or more item and choose an action:

      • Publish makes the content available in the blog.

      • Reject moves the content to the Rejected state. The blog owner or the author of the entry or comment can edit the content and resubmit for approval.

      • Delete permanently removes the content from the blog.


    Manage flagged content for a blog

    Review published blog content that has been flagged as inappropriate and take action on flagged entries and comments.

    When a blog entry or comment is flagged by a user, it is marked for review and it displays on the Flagged Entries or Flagged Comments page of the Moderation tab. The Flagged Entries and Flagged Comments pages let an authorized moderator view the history and state of flagged entries or comments, and take action on them.

    The workflow described in this topic requires that valid email addresses are configured for the reviewers and that email notifications are enabled for your Blogs deployment.

    When a user flags a blog entry or comment as inappropriate, it sets in motion a workflow for reviewing and resolving the issue. The workflow goes as follows:

    1. Notification is sent to the moderator that an entry or comment has been flagged. The notification includes information about the person flagging the content, a justification for the action, and a link to the entry. The entry or comment is posted to the Flagged Entries or Flagged Comments page in the Moderation interface for viewing and managing flagged content. For Blogs, notification is also sent to the person who flagged the entry that the content is being reviewed.

      There is a setting in the contentreview-config.xml file which determines whether notification is sent to a moderator or content reviewer as following:

      • If issueCategorization is disabled, then notification is sent to all the moderators.

      • If issueCategorization is enabled, then the notification will only be sent to the reviewers defined under each issue category, but if reviewer information is not provided, the notification will still be sent to all the moderators.

    2. The moderator reviews the content and acts on it.

    3. If the reviewer does not think the content is inappropriate, the flag is dismissed and the content remains in the blog. The entry is moved from the Awaiting Decision panel to the Dismissed panel.

    4. If the content is considered inappropriate, the reviewer quarantines the posting, which means it is removed from the blog and placed in a quarantined state. In this case, the author is notified. The posting appears on the Quarantined panel.

    5. A moderator can send entries back to the author to update the content. Entries that have been returned display in the Returned to Author panel.

    6. If the author resubmits the content, it is listed in the Reposted area so the moderator can review the updated content. If the content is acceptable, the reviewer can dismiss the flag so that the content can be published to the blog.

    If Blogs is configured so that email notification is disabled, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:

    • When an entry is flagged as inappropriate, the reviewers will not receive email indicating there is a potentially offensive posting. Also, the person who flagged the message as inappropriate will not receive a confirmation email that the post they found offensive is being reviewed. Reviewers will have to periodically visit the Flagged Entries or Flagged Comments pages of the Moderation interface to see what entries need action and then manually send confirmation notification messages to the user who flagged the entry.

    • If the reviewer quarantines a blog entry, or returns the entry to the author to be edited, the blog owner will not receive email notifications. The reviewer will have to manually send a notification message to the blog owner.

    If your organization includes people with no email, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:

    • If a reviewer has no email, when an entry or comment is flagged as inappropriate, the reviewer will not receive email indicating there is a potentially offensive posting. Reviewers will have to periodically visit the Flagged Entries or Flagged Comments pages of the Moderation interface to see what entries need action and then manually send confirmation notification messages to the user who flagged the entry.

    • If the blog owner has no email, and the reviewer quarantines a blog entry, or returns the entry to the author to be edited, the blog owner will not receive email notifications. The reviewer will have to manually send a notification message to the blog owner.

    • If the person who flagged the message as inappropriate has no email, the person will not receive a confirmation email that the post they found offensive is being reviewed.
    Follow these steps to review flagged content and take action.

    1. Click the Moderation tab from Blogs.

    2. Click Flagged Entries or Flagged Comments in the navigation pane. Content awaiting decisions are displayed along with information on who flagged the content and why.

    3. Review a flagged entry and choose one of these actions:

      Option Description
      Quarantine This option turns the post in question to a draft and removes it to a quarantine area so it is not available to blog readers. This option prompts you to send notification to the posting author explaining your reason for removing the post and providing a link so the author can revise the content. If the author revises the content and resubmits it to the blog, that entry appears in the Reposted panel so the reviewer can see it and make sure it is appropriate as revised.

      Dismiss Flag Dismiss the flag. The post remains in the blog.

      Delete Permanently remove the entry or comment.

    4. View content that you have acted on by choosing one of the following tabs:

      • Quarantined

      • Returned to Author (Entries only)

      • Reposted (Entries only)

      • Dismissed
      You can review those posts or move them back into the Awaiting Decision category to take a different action.


    Related tasks

  • Manage content moderation and flagged content
  • Flagging an entry as inappropriate

    Change the location of the Blogs File Upload directory

    Change default directories for the File Upload directory from the IBM websphere Application Server (WAS) administrator console.

    By default, the File Upload directory is stored in the IBM Connections data directory under Blogs. This variable is stored in the WebSphere Application Server variables. You can change the location of the file upload directory by updating the WebSphere Application Server variable. To change the location:

    1. Launch the WebSphere Application Server Integrated Solutions Console.

    2. Select Environment > WebSphere variables.

    3. Select BLOGS_CONTENT_DIR from the list of WebSphere variables.

    4. Set the directory on the server used for file uploads in the Value field and click Apply. This should be a shared drive when deployed in a cluster. For example, BLOGS_CONTENT_DIR = C:/IBM/Connections/Data/blogs/upload.

    5. Click OK.

    6. Restart the Blogs server for your changes to take effect.


    What to do next

    If you change the location of the File Upload directory, make sure you copy any content from the default directory to the new location.

    Blogs field limits

    This topic lists character input limits for key Blogs fields.


    Limits

    The field limits are listed for single-byte languages. They will vary for multi-byte languages. For example, a field that holds a text string up to 255 characters in a single-byte language might hold a text string up to only 128 characters in a double-byte language. The length may also vary based on the database type. For example, the length limit for a blog name is 255 bytes in DB2 and Oracle, and 255 characters in SQL server. The following limits are based on DB2.

    Field Character input limit
    Blog name 255 characters
    Blog handle 30 characters
    Blog description 255 characters
    Entry title 255 characters
    Link name You can enter and store up to 255 characters, but only the first 30 will display in the user interface.
    Link description The first 255 characters entered into the field will be saved.

    Extend the list of allowable file types for blogs

    Extend the list of possible file types that users could upload to a blog.

    When a file is uploaded to a blog, the mime type specified in the content type in the http request header must match a mime type available for the Java Virtual Machine (JVM) so that the correct file extension is applied. By default, the Java Virtual Machine (JVM) supports a default set of mime types that map the most common types of content to the correct file extensions. You can extend the list so that users can upload files of types that are not specified in the default list. After you extend the list you must specify that the file type is allowable as an upload. Follow these steps to extend the list and make a new file type allowable for uploads:

    1. Use a text editor, open the file mime.types in the directory C:\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\t2homdevNode01Cell\Blogs.ear\blogs.war\META-INF. The file only includes comments:

      # Copyright IBM Corp.  2009  All Rights Reserved.    #
      
      # comments begin with a '#'
      # the format is <mime type> <space separated file extensions>
      # for example: (without the # comment mark)
      # text/plain txt text TXT
      # this would map file.txt, file.text, and file.TXT to
      # the mime type "text/plain"

    2. Add the mime types you want users to be able to upload. For example, to support the upload of Microsoft Excel files, add the mime type application/vnd.ms-excel xls XLS. Blogs would then be able to recognize that file type and assign the XLS file extension.

    3. Save the file and restart the Blogs server.

    4. From the Blogs interface, choose the Administration tab.

    5. On the Configuration page, make sure that Enable File Uploads is enabled.

    6. Add the new file extension to the Allowed Extensions field.


    What to do next

    Your users will now be able to upload files of the type you specified.

    Configure blog hits and visits

    Understand how blog hits and visits are calculated and how you can modify the way each count is done.

    If you are trying to gather data on how many times a blog entry is accessed, you can consider two metrics:

    • Visits count the total number of times a blog entry is accessed, including clicks from another page in the same blog. The visit count displays.

    • Referrer hits also count how many times a blog entry is accessed, but provides more information about where the hits come from. To view referrer hits, choose Sets for a blog, then click Referrers.

    Starting with IBM Connections 3.0, hits and visits are counted the same way. This is a change from the way hits were counted in previous releases. If you want to revert to the old behavior, where referrer hits are not counted if they come from another page in the same blog, modify the roller.properties file as follows:

    1. Edit the roller.properties file from this location: IBM\WebSphere\AppServer\profiles\<profile_name>\installedApps\<cell_name>\Blogs.ear\blogs.war\WEB-INF\classes

    2. Set referrer.ignoreSelfReferer to true.

    3. Save your changes and restart the Blogs server for changes to take effect.

    if you modify roller.properties, the counts for visits and hits will differ.


    Referrer hits

    Referrer hits are divided into:

    • Direct hits with no referrer information available

    • URL hits with referrer information available

    Direct hits increment the hit tally under these circumstances:

    • A blog entry is created

    • A blog or blog entry is accessed via a link from an e-mail message

    • The user enters the blog or blog entry URL directly into a browser

    • The blog or blog entry link is selected from a Web page, but the referring server does not send the referrer information

    • The blog or blog entry is accessed via a link in a feed reader

    • The blog or blog entry is accessed via a link embedded in a bookmark

    URL hits increment the hit tally under these circumstances:

    • A blog or blog entry is selected from within Connections

    • A blog or blog entry is accessed via a link from a Web page that sends referrer information


    Visits

    The count for visits counts the number of times a blog entry is accessed. The count is displayed in the blogs Web UI and is used to measure popularity and other metrics.

    Starting with IBM Connections 3.0, anyone clicking a blog or entry will increase its visit count, even it is the blog author accessing the content. In prior releases, the count was not increased if the click came from the blog or entry author. If you want to revert to the previous behavior, where visits are not counted if they come from the author, modify the roller.properties file as follows:

    1. Edit the roller.properties file from this location: IBM\WebSphere\AppServer\profiles\<profile_name>\installedApps\<cell_name>\Blogs.ear\blogs.war\WEB-INF\classes

    2. Set hitcount.ignoreSelfClick to true.

    3. Save your changes and restart the Blogs server for changes to take effect.


    Caching

    The way the blog pages are cached in the browser may contribute to a temporary inaccuracy in the visit count visible in the UI. The visit count is not refreshed until the web page cache expires and the page is reloaded from the application server. Under some circumstance this may require an update to some of the blog content that will cause page to reload.


    Behavior when cache proxy is enabled

    If the user is using a cache proxy and has specified CacheMaxExpire with a specific time period, a page will be served via the cache proxy within this time period without checking the host server. Since the request is not processed by the application server there is no way to count it, so neither the referrer or visit count is incremented.

    Prior to IBM Connections 3.0, the behavior when a cache proxy was in use was as follows: when a request was processed by the application server and the request header contained "If-Modified-Since", the server checked for updates. If there were no updates, a return code of 304/SC_NOT_MODIFIED was issued and the visit count remained the same. This is one case where the referrer count increased, but the visit count did not. This rule can be useful so that when a user keeps refreshing the page without clearing the cache, the visit count is not increased. The exception is the author's own hit where the server returns a 200 code even when there are no new entries. This is actually a flaw that authors can exploit by logging in and refreshing the page to increase the visit count to their own blog entry. In current implement, referrer count and visit count will be increased even in the 304 response case.

    If you want to revert to the previous behavior, modify the roller.properties file as follows:

    1. Edit the roller.properties file from this location: IBM\WebSphere\AppServer\profiles\<profile_name>\installedApps\<cell_name>\Blogs.ear\blogs.war\WEB-INF\classes

    2. If the user does not want the visit count to be increased if page is served from browser side cache (304 not modified), set hitcount.ignore304 to true. The default value of this configuration is false.

    3. If the user does not want referrer counts to be increased if page is served from browser side cache (304 not modified), set referrer.ignore304 to true. The default value of this configuration is false.

    4. Save your changes and restart the Blogs server for changes to take effect.


    Behavior when cache proxy is not enabled

    When cache proxy is not enabled and Ctrl-refresh is used, the request to the server will not include "If-Modified-Since" in the request header. As a result the user will see the visit count increase. This happens because the server will interpret the request as if there is no cache and will issue return code 200 with the latest data.

    Understand blog likes, comments, and visits

    This topic describes how the Most Liked, Most Commented, and Most Visited statistics are calculated and why the counts may differ between those found in the widgets and those found in the main page.

    If you are viewing either the list of blogs or the list of blog entries from the Public Blogs page, you can view the lists of most liked, most commented, and most visited blogs or entries in sidebar widgets. You can also view these statistics for each blog or entry in the main page. There may be times when the information in the main page does not match the information in the sidebar widgets because of the way each count is calculated.


    Calculating liked, commented, and visited statistics for blog entries

    The statistics for the Most Liked, Most Commented, and Most Visited widgets and the Likes/Votes, Comments, and Visits statistics that display in the main page are calculated in slightly different ways. For example, the Most Liked widget displays the most likes in the last 30 days, regardless of when the entry was published. The list of latest entries in the main page only displays entries published in the last 30 days, so the most liked entry in that list may not match the most liked entry in the widget.

    • The Likes/Votes, Comments, and Visits count for an individual entry is calculated as follows:

      • Only those entries that were published within the past 30 days are displayed. You can configure the period for what entries to display by changing the value of the homepage.since property in the roller.properties file.

      • The count displayed under each entry is for overall likes, comments, or visits.

      • You can sort the list of entries by overall likes, comments, or visits.

    • The count for an entry in the Most Liked or Most Commented widget is calculated as follows:

      • Entries display according to how many likes or comments they received in the last 30 days, regardless of when the entries were published. Likes or comments older than 30 days are disregarded.

      • You can configure the period for calculating likes by changing the value of the homepage.mostRecommendedSince property in the roller.properties file.

      • You can configure the period for calculating comments by changing the value of the homepage.mostCommentedSince property in the roller.properties file.

    • The count for an entry in the Most Visited widget is calculated as follows:

      • The visit count is only listed for entries that have been published or updated in the last 30 days.

      • The visit count is a cumulative count, not just visits in the last 30 days.

      • You can configure the period for what entries display by changing the value of the homepage.mostVisitedSince property in the roller.properties file.


    Calculating liked, commented, and visited statistics for blogs

    Just as with blog entries, the blog statistics for the Most Liked, Most Commented, and Most Visited widgets and the corresponding statistics that display in the main page are calculated in slightly different ways. For example, the Most Liked widget displays the most likes in the last 30 days, regardless of when the blog was created. The list of blogs in the main page only displays blogs published in the last 30 days, so the most liked blog in that list may not match the most liked blog in the widget.

    • The Liked, Commented, and Visited counts for an individual blog are calculated as follows:

      • All blogs display in the main page, regardless of when they were published.

      • The count displayed for each blog is for overall likes, comments, or visits.

    • The count for blogs in the Most Liked or Most Commented widget is calculated as follows:

      • Blogs display according to how many likes or comments they received in the last 30 days, regardless of when the blogs were published. Likes or comments older than 30 days are disregarded.

      • You can configure the period for calculating likes by changing the value of the homepage.mostRecommendedSince property in the roller.properties file.

      • You can configure the period for calculating comments by changing the value of the homepage.mostCommentedSince property in the roller.properties file.

    • The count for a blog in the Most Visited widget is calculated as follows:

      • The visit count is only listed for blogs that have been published or updated in the last 30 days.

      • The visit count is a cumulative count, not just visits in the last 30 days.

      • You can configure the period for what entries display by changing the value of the homepage.mostVisitedSince property in the roller.properties file.


    The effects of caching on statistics

    The cache and refresh processes can also contribute to a difference in what displays in the Most Liked widget and the likes listed in the main page of blogs or entries. The widget cache is updated every 10 minutes. This interval is not configurable. If there are no new blog entries or new blogs, the Public Blogs page is cached and will not be updated, and the user will see that the counts do not match. This is due to a "if-not-modified" cache control on the Public Blogs page.


    Update a property in the roller.properties file

    Follow these steps to update a property in the roller.properties file:

    1. Edit the roller.properties file from this location: IBM\WebSphere\AppServer\profiles\<profile_name>\installedApps\<cell_name>\Blogs.ear\blogs.war\WEB-INF\classes

    2. Edit the values for the configuration properties you want to change.

    3. Save your changes and restart the Blogs server for changes to take effect.

    Administer Bookmarks

    You configure and administer Bookmarks using scripts accessed using the wsadmin client. Changes to Bookmarks configuration settings require a restart of the Bookmarks server before they take effect. Changes made using administrative commands take effect immediately.

    There are two ways you can update your Bookmarks environment:

    • Configuration settings: These settings control various configurable applications within Bookmarks. They require a server restart to take effect, and they all have the following form: DogearCellConfig.<command_name>(<arguments>) .

    • Administrative commands: These commands control various aspects of the Bookmarks environment and community users. They do not require a server restart to take effect, and they take the following form: <service_name>Service.<command_name, arguments>.

    When you make configuration changes, you use scripts to check out the Bookmarks configuration file, make changes, and then check the file back in.

    When you use administrative commands to control the operation of a Bookmarks server, no file checkout is necessary and your changes take effect immediately.

    Access the Bookmarks configuration file

    To make configuration changes to a Bookmarks deployment you must first access the Bookmarks configuration file.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. Configuration files are XML-formatted files that store configuration information. The file dogear-config-cell.xml stores properties that affect Bookmarks, such as determining thresholds for displaying active tag, person, and link data. Follow these steps to access one of the Bookmarks configuration files:

    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. 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. See the topic Starting the wsadmin client.

    2. Start the Bookmarks Jython script interpreter by entering the following command:

      execfile("dogearAdmin.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 change properties, check out the configuration file, dogear-config-cell.xml, with the following command:

      DogearCellConfig.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 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:

        DogearCellConfig.checkOutConfig("/opt/dogear/temp","DogearServerNode01Cell")

      • Microsoft

        Windows:

        DogearCellConfig.checkOutConfig("c:/dogear/temp","DogearServerNode01Cell")
      This command should print out this message: Bookmarks Cell Level configuration file successfully checked out.

    4. Optional: To view a list of the valid Bookmarks configuration settings and their current values, use the following command: DogearCellConfig.showConfig()

    5. To change a Dogear configuration setting, use the following command: DogearCellService .updateConfig("[property]", "[value]") where [property] is one of the editable Dogear properties and [value] is the new value to apply to the property. For example:

      DogearCellService.updateConfig("favIconService.favicon.queuesize", "50")


    What to do next

    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 details.


    Related tasks

  • Start the wsadmin client


    Bookmarks configuration properties

    Configuration settings control various configurable applications within Bookmarks. They require a Bookmarks application or server restart to take effect.


    Configuration properties

    The following table lists the configuration settings that you can check out and modify for the dogear-config-cell.xml file.

    Configuration property Description
    activeContentFilter.enabled Enables/disables the active content filter for the Rich Text descriptions on bookmarks. The default value is "true" and can be set to "false" if you wish not to filter active content.
    bookmark.openInNewWindow Controls the window behavior when users click on a bookmark. When the value is True, clicking a bookmark will open the URL in a new window. When False, the bookmark opens in the same window.
    brokenURL.notifyAllOwners Turns on or off the display of an option on the broken URL form that allows users to notify all other users who bookmarked a broken link. If the option is enabled, the user is also notified about how many other users will be notified about the broken URL before the notification mail is sent. The default is "False" which means the option is not displayed on the Broken URL form.
    brokenURL.notifyAdmin If set to True, the Bookmarks administrator (defined as the dogear-admin in the notification-config.xml file) receives a copy of each notification email for a broken link. Set this property to false to suppress the notification.
    favicon.ajaxproxy.intranet.enabled If set to True, Bookmarks will load the intranet bookmark favicons via the AJAX proxy; if set to False it will load bookmark favicons via direct network access.
    favIconService.favicon.directory Determines where the favicon image caches will be stored on the file system. This will be located on the local file system of each node machine.

    Although you can change this setting in the configuration file, the recommended approach is to set this location from the websphere Application Server administrator console. For more information, see the topic "Changing the location of the favicon cache or full-text index."

    favIconService.favicon.maxAge Small (fav) icons are displayed to end users next to each bookmark. Bookmarks downloads and caches these icons from the hosts servers for each URL. This setting determines length of time (in days) an icon remains cached locally before an updated copy is retrieved.
    favIconService.favicon.maxSize Small (fav) icons are displayed to end users next to each bookmark. Bookmarks downloads and caches these icons from the hosts servers for each URL. This setting provides a cap (in KB) on the size of the cached icon to control image file size. The default is 6 KB.
    favIconService.favicon.queuesize Starting from Connections 2.5, the request to update the favicon of a specific webpage will be handled by a scheduled task running at the server. Such requests will be put in the task queue and be consumed when the favicon is updated. This setting defines the maximum size of the requests the task queue can contain. When the queue is full, new requests will be discarded until the requests in queue are consumed. The default is 100.
    favIconService.favicon.start Provides the time (in minutes) the favicon task will start after Bookmarks service starts. The default is 5 minutes.
    linkPurgingTask.lpTask.interval Provides the interval (in minutes) of 2 purging task rounds. The default is 60 minutes.
    linkPurgingTask.lpTask.purgeDeleted When a user deletes a bookmark (a link), it will be marked as deleted bookmark. The bookmark record will be kept for a specific period in order to let search indexer to update the index. This setting provides the number of days a deleted bookmark will be kept in Bookmarks database before being purged out. The default is 30 days.
    linkPurgingTask.lpTask.start Provides the time (in minutes) the bookmark purging task will start after Bookmarks service starts. The default is 15 minutes.
    linkThresholds.countInterval.useCountCache When the cache is enabled, it will be updated after being used for specific times. The default is 10.
    linkThresholds.maxInclude.popularLinks Provides a maximum number of links that will get included in the popular link algorithm. If there are more links that are eligible to be included based on the other settings, the algorithm will take the most recent links that fall within this cap. This is to ensure consistent performance over peak times. The default value is 2000 links.
    linkThresholds.minLinkCount.useCountCache The total number of bookmarks showed on the UI will be cached after the total number of bookmarks exceeds a specific number. The default is 100,000.
    linkThresholds.minURLCount.useCountCache The total number of URLs showed on the UI will be cached after the total number of URLs exceeds a specific number. The default is 10,000.
    linkThresholds.sinceWhen.inboxLinks Determines age (in days) a link may be to get included in a user's watchlist. Smaller values will result in better performance. The default is 20 days.
    linkThresholds.sinceWhen.mostvisitedLinks Determines age (in days) a link may be to get included in the Most Visited section. The default is 30 days.
    linkThresholds.sinceWhen.popularLinks Determines the age (in days) a link may be to get included in the popular link algorithm. This value is used in conjunction with the other popular link settings to determine what bookmarks are included on the "Popular" bookmarks tab. Smaller values result in better performance. The default is 30 days.
    personThresholds.maxInclude.activePerson Provides a maximum number of bookmarks (and the associated people) that are included in the active person list algorithm. If more entries are eligible to be included in this calculation based on the other settings, the algorithm will take the people associated with the most recent links that fall within this cap. This is to ensure consistent performance over peak times. The default value is 1500 bookmarks.
    personThresholds.minCount.activePerson Provides a minimum number of bookmarks a user must have within the active time window to be considered for the active person list. People that have less bookmarks than this threshold will not be included in the list on the All and Popular bookmark views. This value is used in conjunction with the other active person threshold settings to determine who is included in the active person list. The default is 5 bookmarks.
    personThresholds.sinceWhen.activePerson Determines age (in days) a bookmark may be to have the associated person included in the active person list on the All and Popular bookmark views. This value is used in conjunction with the other active person threshold settings to determine who is included in the active person list. Smaller values will result in better performance. The default is 30 days.
    tagThresholds.maxInclude.activeTags Provides a maximum number of tags that will get included in the active tag algorithm. If there are more tags that are eligible to be included in this calculation based on the other settings, the algorithm will take the most recent tags that fall within this cap. This is to ensure consistent performance over peak times. The default value is 4000 tags.
    tagThresholds.minCount.activeTags Provides a minimum number of occurrences for a tag within the active time window for it to show in the Active Tag cloud. Tags that occur less than this threshold within the active time window will not show in the Active Tag cloud on the All and Popular bookmark views. This value is used in conjunction with the other active tag threshold settings to determine what is included in the tag cloud. The default is 1 tag.
    tagThresholds.sinceWhen.activeTags Determines age (in days) a link may be to have its tags included in the Active Tag cloud shown on the All and Popular bookmark views. This value is used in conjunction with the other active tag threshold settings to determine what is included in the tag cloud. Smaller values will result in better performance. The default is 30 days.
    useRichTextEditorInBookmarklet Configure the 4-in-1 bookmark form to use a rich text editor for the Description field rather than the plain text editor that is enabled by default.


    Related tasks

  • IBM Connections configuration property values


    Apply property changes

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

    You must perform the check in during the same wsadmin session in which you checked out the files for the changes that you made to take effect.

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

      DogearCellConfig.checkInConfig( "<working_directory>", "<cell_name>")

    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 Bookmarks application.


    Related tasks

  • Apply common configuration property changes

    Run Bookmarks administrative commands

    Run administrative commands from the wsadmin command line to directly interact with Bookmarks. You do not have to check out files or restart the server for changes to take effect.

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

    Administrative commands require you to start the wsadmin command line processor. From there, you run Jython scripts to administer the Bookmarks application. These config-admin scripts get and set properties using the AdminConfig object (wsadmin) available in WebSphere Application Server to interact with the Bookmarks server. 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.

    When executing the MBean commands, if the command encounters an input that is not valid, such as a missing quote or incorrect file path, the following exception can be returned in the wsadmin console:

    com.ibm.ws.scripting.ScriptingException com.ibm.ws.scripting.ScriptingException: 
    javax.management.RuntimeMBeanException:
    resetTasks 
    To determine what went wrong, you can examine the SystemOut.log file. It should show an exception entered as a result of the Mbean command responsible for the exception.

    To change Bookmarks administrative settings:

    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. 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. See the topic Starting the wsadmin client.

    2. Start the Bookmarks Jython script interpreter by entering the following command:

      execfile("dogearAdmin.py")


    Related tasks

  • Start the wsadmin client


    Use administrative commands

    The commands described here manipulate managed Java beans (MBeans) to make changes to various operational data on a Bookmarks server.

    To run administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. These commands are tools you can use to control various aspects of the Bookmarks environment and its users. These commands do not require a file check out or a server restart to take effect.

    These commands are case-sensitive and take the following form:

    DogearMemberService.<command_name>(<arguments>)
    LinkService.<command_name>(<arguments>)
    URLService.<command_name>(<arguments>)

    1. To update the Bookmarks database - If there is an LDAP change that requires member IDs in the Bookmarks database to be updated, you must use the DogearMemberService command. For example, if users are migrated to a new LDAP or a user is removed and re-entered in the LDAP and their unique identifier changes, these users will not be able to login to Bookmarks until the user record is updated with the DogearMemberService MBean. The following methods are available to make these database changes:

      DogearMemberService.syncAllMembersByExtId(boolean)

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncMemberByExtId(newExternalID, oldExternalID)

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncAllMemberExtIds()

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncMemberExtIdByEmail(emailAddr)

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncMemberExtIdByLogin(loginName)

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncBatchMemberExtIdsByEmail(emailFile)

      See Synchronizing user data using administrative commands for details.

      DogearMemberService.syncBatchMemberExtIdsByLogin(loginFile)

      See Synchronizing user data using administrative commands for details.

    2. To remove offensive content - When you need to delete offensive or unwanted links from the database, you use the LinkService command. You can delete links in two ways - using the UID (which can be obtained by right-clicking on the bookmark, click on "Copy link location" and pasting into a text editor, and then copying the 36 alphanumeric characters (the UID) that occur after "link=") or, alternately, by using the email address of the person that created the link and URL of the link.

      LinkService.deleteLinkByUID('[UID]')

      Deletes a single bookmark matching the UID specified.

      [UID] is the UID of the bookmark.

      When creating the text file, enter one UID per line.

      There should be no output in wsadmin console if successful.

      Example:

      LinkService.deleteLinkByUID("0A5G09219578A357F378C607680F7600000B")

      LinkService.deleteLinkByUIDBatch('[fileName]')

      Deletes a list of bookmarks matching the UIDs specified.

      [fileName] is the name of a text file containing the uids to be deleted. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      There should be no output in wsadmin console. Be sure to check logs as UIDs that were not successfully deleted will be logged.

      Example:

      LinkService.deleteLinkByUIDBatch("/opt/Bookmarks/badlinks.txt")

      LinkService.deleteLinkByPersonURL('[email]', '[href]')

      Deletes a single bookmark matching the email and URL specified.

      [email] is the address of the person who created the bookmark.

      [href] is the URL of the bookmark you want to delete. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console if successful.

      Example:

      LinkService.deleteLinkByPersonURL("jane_doe@acme.com","http://bad.url.com)

      LinkService.deleteLinkByPersonURLBatch('[fileName]')

      Deletes multiple bookmarks matching specified email addresses and URLs.

      [fileName] is the filename containing the addresses and URL to be deleted. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      This file must be formatted with [email] <space> [href] on each line. For example, a single line would look as follows:

      email@ibm.com http://www.theurl.com

      Note the single whitespace character between the address and the URL.

      [email] is the email address of the person with the bookmark.

      [href] is the URL of the bookmark. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console. Be sure to check logs as addresses and URLs matching the bookmark that was not successfully deleted will be logged.

      Example:

      LinkService.deleteLinkByPersonURLBatch("c:/Bookmarks/delete.txt")

      LinkService.deleteLinksByURL('[href]')

      Deletes all bookmarks (public and private) matching the URL specified. Those bookmarks will be marked as deleted in the database waiting for the search indexer to detect them and update the index.

      [href] is the URL of the bookmark you want to delete. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console if successful.

      Example:

      LinkService.deleteLinksByURL("http://bad.url.com")

      LinkService.deleteLinksbyURLBatch('[fileName]')

      Deletes multiple bookmarks matching specified URLs.

      [fileName] is the filename containing the URLs to be deleted. Separate URLS with line breaks. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      There should be no output in the wsadmin console. Be sure to check logs as bookmarks matching specified URLs that are not successfully deleted will be logged.

      Example:

      LinkService.deleteLinksbyURLBatch("c:/Bookmarks/delete_links.txt")

    3. To manage IP ranges - UrlService commands are used when the internal IP ranges of a company change. These commands operate on the Bookmarks database and can recalculate whether an existing link is internal or not, based on the IP ranges that are updated using the DogearCellConfig.addIpRange or DogearCellConfig.removeIpRange commands.

      Also, it is a good idea to delete the contents of the Favicons subdirectory. The "favicons" that appear next to each Bookmarks link are cached in the favicon directory, and if you delete the contents of this directory, the icons that appear next to each link will be updated.

      After making IP range configuration updates you need to restart Bookmarks for changes to take effect. Then you must run these commands to process URL changes. UrlService commands include:

      UrlService.reprocessIntranetAddress('[href]')

      [href] is exact URL whose intranet range is to be reprocessed .

      Example Usage: UrlService.reprocessIntranetAddress ('http://www.ibm.com')

      There should be no output in wsadmin console if successful.

      UrlService.reprocessIntranetAddressBatch('[fileName]')

      [fileName] is the name of the file containing URLs to be recalculated.

      You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      This command expects a file with URLs to be recalculated on each line. Enter a single URL on each line of the file.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.reprocessIntranetAddressBatch(/opt/test.txt")

      UrlService.reprocessIntranetAddresses()

      This command should be used if there have been no major changes to the network topology and the only goal is to process an update to the configured intranet IP ranges.

      This command reprocesses the intranet status of all Bookmarks URLs by comparing a locally cached version of its IP address to the intranet IP ranges provided in the Bookmarks cell-level configuration document.

      This command is much quicker than UrlService.recalculateIPAddresses , which not only checks the current intranet settings but also regathers the IP address for every URL in the database.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.reprocessIntranetAddresses()

      UrlService.recalculateIPAddress('[href]')

      [href] is exact URL whose intranet range is to be recalculated.

      Example Usage:

      UrlService.recalculateIPAddress('http://www.ibm.com') 

      If you are only re-validating the intranet status of URLs because of a change to intranet IP tables, then UrlService.reprocessIntranetAddress('[href]') should be invoked.

      There should be no output in wsadmin console if successful.

      Example:

      UrlService.recalculateIPAddress("http://www.ibm.com")

      UrlService.recalculateIPAddressesBatch('[fileName]')

      [fileName] is the name of the file containing URLs to be recalculated.

      This command expects a file with the URLs to be recalculated on each line. Enter a single URL on each line of the file.

      If you are only re-validating the intranet status of URLs because of a change to intranet IP tables, then UrlService.reprocessIntranetAddressesBatch('[fileName]') should be invoked.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.recalculateIPAddressBatch("c:/Bookmarks/recalc.txt")

      UrlService.recalculateIPAddresses()

      This command recalculates the IP addresses of all the URLs in the database. It works by updating the locally cached copy of the IP address for each URL.

      Run this command can be time consuming for large sized DBs. For each URL in the database, this command will connect to and validate the IP address from the DNS. It takes an average of 8 minutes per 500 URLs, depending on the speed of the network connection.

      If you are simply re-validating the intranet status of URLs because of a change to intranet IP tables, use the UrlService.reprocessIntranetAddresses() command to speed the process.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.recalculateIPAddresses()

      UrlService.notifyBrokenURLOwners('<broken_URL>', '<replace_URL>')

      This command will find all owners of a single URL and send them an email notification. Optionally, you can supply a <replace_URL> as the suggested substitute URL for the broken URL.

      [broken_URL] is a plain text string that represents the broken URL.

      [replace_URL] is a plain text string that is the suggested substitute URL for the broken URL.

      Example:

      wsadmin>UrlService.notifyBrokenURLOwners('http://www.example.com','http://w3.example2.com') 
      This command will find all users who bookmarked http://www.example.com (either public or private bookmarks) and send them email notifications. In the notification, it will suggest that bookmark owners replace the old URL with the new one http://www.example2.com.

      UrlService.batchNotifyBrokenURLOwners('<repository_file>')

      This command will iterate all the broken URL and substitute URL pairs in the given <repository_file> and send email notifications to all the bookmark owners of the broken URLs in the file. In the notification, you can provide the corresponding <replace_URL> as the suggested substitute URL for the broken URL.

      [repository_file] is a local file path that contains the broken URLs and their suggested substitute URLs. Each pair of original URL and substitute URL should be placed in one line and separated by either white spaces or tabs.

      Example:

      UrlService.batchNotifyBrokenURLOwners('c:/brokenurls.txt') 

      This command will load the URL pairs in c:\brokenurls.txt and send email notifications to users who bookmarked those URLs. For each broken URL, Bookmarks will send an email notification.

      UrlService.replaceURLWithURL('original_URL_str', 'replace_URL_str', 'log_file')

      Specify a single URL and a replacement URL and make an immediate update. Set the URL to be replaced and a string that specifies the replacement URL.

      Enter a local file path for the log file that is used to log any messages that result from running the command. The file will be created if it does not exist; otherwise, new log data is appended to the data in the existing file.

      The exact match command finds the bookmarks with the specified URL and updates them to the specified replacement URL. The command runs immediately. Example:

      UrlService.replaceURLs('c:/output.txt', 'c:/log.txt') 

      UrlService.findURLsToReplace('<base>', '<URL_pattern>', '<replace_str>', '<output_file>', '<log_file>')

      Use a pattern with wildcards to find and replace multiple URLs. The URLs that match the pattern are written to a file, along with the specified replacement URL. Log messages are printed to c:\log.txt. Once you verify the pairs, you run a second command to upload the file and perform the updates.

      This command scans the Bookmarks database to URLs with associated bookmarks that match the given <URL_pattern> and then calculates the replacement URLs based on the <replace_str>. The command does not update the matched URLs in the Bookmarks. Scan results are saved in <output_file> so you can check the matched URLs and their replacement URLs to verify that the pairs are what you want. If not, you can manually edit the file to add, remove, or update the URL pairs. The command runs as a backend task in the system

      Example:

      UrlService.findURLsToReplace('mycompany', 'w3/.mycompany/.com', 'www.mycompany.com', 'c:/output.txt', 'c:/log.txt') 
      This command scans all URLs containing the string 'mycompany' and matches them against the regular expression pattern "w3/.mycompany/.com". The "w3.mycompany.com" in the matching URLs will be replaced by "www.mycompany.com". The matched URLs and the replacement URLs are printed into c:\output.txt file. Log messages are printed to c:\log.txt.

      UrlService.replaceURLs('<input_file>', '<log_file>')

      Upload a file containing URLs to find and the replacement URLs. Parameters: original_URL_str A plain text string that specifies the URL to be replaced. You can use the output file of the findURLsToReplace command as the input here. URLs are updated unless a bookmark for the replacement URL already exists. Those are skipped to avoid creating duplicate bookmarks. Log messages are printed to c:\log.txt.

      For example:

      UrlService.replaceURLs('c:/output.txt','c:/log.txt')

      This command loads the URL pairs in the file c:\output.txt and updates all the bookmarks on the specified original URLs to the replacement URLs. Log messages are printed to c:\log.txt.


    Related

  • Synchronize user data using administrative commands

    Filter active content

    The active content filter prevents a user from embedding malicious content in Bookmarks input fields. You configure Bookmarks settings using scripts accessed using the wsadmin client. These scripts use the AdminConfig object available in WebSphere Application Server Admin (wsadmin) to interact with the Bookmarks configuration file. Changes to Bookmarks configuration settings require node synchronization and a restart of the Bookmarks server before they take effect.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. Bookmarks provides a filter that prevents users from using rich text descriptions with malicious scripts that are executed when other users visit bookmarks. You can disable this filter to provide richer options for content in any Bookmarks text input field.

    Disabling this filter introduces vulnerability to XSS and other types of malicious attack. See Securing applications from malicious attack for additional information.

    1. Open a command window and start the wsadmin command line tool as described in the topic, Starting the wsadmin client.

    2. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    3. To configure the active filter for Bookmarks, set the following property:

      Option Description
      activeContentFilter.enabled

      Boolean. true/false.

      Enables/disables the active content filter for the Rich Text descriptions on bookmarks. The default value is "true" and can be set to "false" if you wish not to filter active content.

      Disabling the active content filter is not recommended as it will allow end users to create Rich Text Descriptions with malicious scripts that might be executed when other users visit bookmarks.

    4. See Applying property changes for information about how to save and apply your changes.

    Change view and link thresholds

    Use these configuration settings to change view and link thresholds for a Bookmarks deployment.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. You can manage a variety of configuration settings for thresholds for links and tags in a Bookmarks deployment. Most of the settings can be configured by checking out the configuration file, modifying it, and checking it back in.

    1. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    2. Update the following configuration properties. The keys for changing view thresholds and the values the key can accept are as follows:

      Option Description
      linkPurgingTask.lpTask.interval

      Integer.

      Provides the interval (in minutes) of 2 purging task rounds. The default is 60 minutes.

      linkPurgingTask.lpTask.purgeDeleted

      Integer.

      When a user deletes a bookmark (a link), it will be marked as deleted bookmark. The bookmark record will be kept for a specific period in order to let search indexer to update the index. This setting provides the number of days a deleted bookmark will be kept in Bookmarks database before being purged out. The default is 30 days.

      linkPurgingTask.lpTask.start

      Integer.

      Provides the time (in minutes) the bookmark purging task will start after Bookmarks service starts. The default is 15 minutes.

      linkThresholds.sinceWhen.popularLinks

      Integer.

      Determines the age (in days) a link may be to get included in the popular link algorithm. This value is used in conjunction with the other popular link settings to determine what bookmarks are included on the "Popular" bookmarks tab. Smaller values result in better performance. The default is 30 days.

      linkThresholds.maxInclude.popularLinks

      Integer.

      Provides a maximum number of links that will get included in the popular link algorithm. If there are more links that are eligible to be included based on the other settings, the algorithm will take the most recent links that fall within this cap. This is to ensure consistent performance over peak times. The default value is 2000 links.

      linkThresholds.sinceWhen.inboxLinks

      Integer.

      Determines age (in days) a link may be to get included in a user's watchlist. Smaller values will result in better performance. The default is 20 days.

      linkThresholds.sinceWhen.mostvisitedLinks

      Integer.

      Determines age (in days) a link may be to get included in the Most Visited section. The default is 30 days.

      linkThresholds.minLinkCount.useCountCache

      Integer.

      The total number of bookmarks showed on the UI will be cached after the total number of bookmarks exceeds a specific number. The default is 100,000.

      linkThresholds.minURLCount.useCountCache

      Integer.

      The total number of URLs showed on the UI will be cached after the total number of URLs exceeds a specific number. The default is 10,000.

      linkThresholds.countInterval.useCountCache

      Integer.

      When the cache is enabled, it will be updated after being used for specific times. The default is 10.

      tagThresholds.sinceWhen.activeTags

      Integer.

      Determines age (in days) a link may be to have its tags included in the Active Tag cloud shown on the All and Popular bookmark views. This value is used in conjunction with the other active tag threshold settings to determine what is included in the tag cloud. Smaller values will result in better performance. The default is 30 days.

      tagThresholds.minCount.activeTags

      Integer.

      Provides a minimum number of occurrences for a tag within the active time window for it to show in the Active Tag cloud. Tags that occur less than this threshold within the active time window will not show in the Active Tag cloud on the All and Popular bookmark views. This value is used in conjunction with the other active tag threshold settings to determine what is included in the tag cloud. The default is 1 tag.

      tagThresholds.maxInclude.activeTags

      Integer.

      Provides a maximum number of tags that will get included in the active tag algorithm. If there are more tags that are eligible to be included in this calculation based on the other settings, the algorithm will take the most recent tags that fall within this cap. This is to ensure consistent performance over peak times. The default value is 4000 tags.

      personThresholds.sinceWhen.activePerson

      Integer.

      Determines age (in days) a bookmark may be to have the associated person included in the active person list on the All and Popular bookmark views. This value is used in conjunction with the other active person threshold settings to determine who is included in the active person list. Smaller values will result in better performance. The default is 30 days.

      personThresholds.minCount.activePerson

      Integer.

      Provides a minimum number of bookmarks a user must have within the active time window to be considered for the active person list. People that have less bookmarks than this threshold will not be included in the list on the All and Popular bookmark views. This value is used in conjunction with the other active person threshold settings to determine who is included in the active person list. The default is 5 bookmarks.

      personThresholds.maxInclude.activePerson

      Integer.

      Provides a maximum number of bookmarks (and the associated people) that are included in the active person list algorithm. If more entries are eligible to be included in this calculation based on the other settings, the algorithm will take the people associated with the most recent links that fall within this cap. This is to ensure consistent performance over peak times. The default value is 1500 bookmarks.

    3. See Applying property changes for information about how to save and apply your changes.

    Configure favicons and changing the default favicon

    Use these settings to configure favicons or replacing the default favicon for a Bookmarks deployment.

    Icons for bookmarks give users a visual guide to different bookmarks. You can manage many of the settings for how bookmark icons display in your deployment.

    IBM Connections supplies a default icon for bookmarks that are not associated with an icon. When you bookmark a page that does not have an icon associated with it, the default icon, default.gif, is placed in the favorite folder where the Bookmarks service is installed. For example, C:\Program files\IBM\Connections\Data\dogear\favorite on a Windows installation. To customize the default icon for your IBM Connections deployment, replace the default.gif file with the one you want to use. To revert to the default, delete the default.gif file and the Bookmarks service will recreate the default file the next time a default icon is requested.

    To edit configuration files that control configurable settings for bookmark icons, you must use the wsadmin client. See Start the wsadmin client for details. Follow these steps to configure settings for favicons.

    1. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    2. To update configuration properties enter the appropriate property into the following command:

      DogearCellConfig.updateConfig(.[property]', .[value]')

      where: [property] is a valid cell-level configuration setting [value] is the new value for the setting. For example: wsadmin>DogearCellConfig.updateConfig('favIconService.favicon.maxAge','60') The properties for changing favicons and the values the properties can accept are as follows:

      Option Description
      favIconService.favicon.maxAge

      Integer.

      Small (fav) icons are displayed to end users next to each bookmark. Bookmarks downloads and caches these icons from the hosts servers for each URL. This setting determines length of time (in days) an icon remains cached locally before an updated copy is retrieved.

      Default is 90 days.

      favIconService.favicon.maxSize

      Integer.

      Small (fav) icons are displayed to end users next to each bookmark. Bookmarks downloads and caches these icons from the hosts servers for each URL. This setting provides a cap (in KB) on the size of the cached icon to control image file size. The default is 6 KB.

      favIconService.favicon.directory

      String.

      Although you can change this setting in the configuration file, the recommended approach is to set this location from the websphere Application Server administrator console. For more information, see the topic "Changing the location of the favicon cache or full-text index."

      Determines where the favicon image caches will be stored on the file system. This will be located on the local file system of each node machine.

      favIconService.favicon.queuesize

      Integer.

      Starting from Connections 2.5, the request to update the favicon of a specific webpage will be handled by a scheduled task running at the server. Such requests will be put in the task queue and be consumed when the favicon is updated. This setting defines the maximum size of the requests the task queue can contain. When the queue is full, new requests will be discarded until the requests in queue are consumed. The default is 100.

      favIconService.favicon.start

      Integer.

      Provides the time (in minutes) the favicon task will start after Bookmarks service starts. The default is 5 minutes.

      favicon.ajaxproxy.intranet.enabled

      Boolean

      If set to True, Bookmarks loads bookmark favicons via the AJAX proxy; if False, favicons are loaded via direct network access.

    3. See Applying property changes for information about how to save and apply your changes.


    Change the location of the favicon cache

    Change the default directory for the favicon cache from the IBM websphere Application Server (WAS) administrator console.

    By default, the favicon cache is stored in the IBM Connections data directory under Bookmarks. The variable is stored in the WebSphere Application Server variables. You can change the location of the favicon cache by updating the WebSphere Application Server variable. To change the locations, complete the following steps: Follow these steps to change the default directory of the favicon cache or the full-text index.

    1. Launch the WebSphere Application Server Integrated Solutions Console.

    2. Select Environment > WebSphere variables.

    3. Select DOGEAR_FAVICON_DIR from the list of WebSphere variables.

    4. Enter a new location for the variable in the Value field and click Apply.

    5. Click OK.

    6. Restart the Bookmarks server for your changes to take effect.

    Determine whether a site is an internet or intranet site

    Establish a URL pattern in a Bookmarks configuration file to indicate whether a site is an internet or an intranet site.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. Enter a URL pattern for your intranet sites in a configuration file to differentiate between internet and intranet sites.

    1. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    2. Configure the URL pattern for your intranet sites, using the following format:

      <privateIntranetAllocationTable>
          <ipRange from="8.0.0.0" to="8.247.255.255" />
          <ipRange from="9.0.0.0" to="9.0.255.255" />
          <ipRange from="128.38.0.0" to="128.38.255.255" />
          <ipRange from="131.105.0.0" to="131.105.255.255" />
          <ipRange from="151.125.0.0" to="151.125.255.255" />
          <ipRange from="159.46.0.0" to="159.46.255.255" />
          <urlPattern>http://localhost:.*</urlPattern> 
          <urlPattern>http://.*\.aaabiz\.com.*</urlPattern>
      </privateIntranetAllocationTable>

      Use a regular expression to specify each <urlPattern> tag. The regular expression must be a Java RE. You can add multiple <urlPattern> expressions inside <privateIntranetAllocationTable>.

    3. Restart the server.

    4. Use wsadmin commands to update the Bookmarks configuration with the new URL ranges.

      1. Open a command window and start the wsadmin command line tool as described in the topic, Starting the wsadmin client.

      2. Enter the wsadmin command UrlService.recalculateIPAddresses() to update the IP addresses. The exact time depends on the number of URL records in your database. Repeat this update operation each time you edit the URL patterns.


    Denote sites as intranets

    You can make changes to configuration settings to denote a Bookmarks site as an intranet. Changes to Bookmarks configuration settings require node synchronization and a restart of the Bookmarks server before they take effect.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. Follow these steps to denote a site as an intranet.

    1. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    2. IP ranges are used to identify bookmarks located on your corporate intranet. As you expand or change your intranet topology, use these settings to incorporate changes into Bookmarks.

      If you had previously configured a value for IntranetAllocation.ipRange, when you run the DogearCellConfig.showConfig() command, one or more IntranetAllocation.ipRange settings will appear. For example:

      privateIntranetAllocationTable from 0.0.00.00 to 0.00.00.1
      privateIntranetAllocationTable from 1.1.11.11 to 1.101.0.1
      privateIntranetAllocationTable from 2.2.22.20 to 2.202.0.2
      privateIntranetAllocationTable from 3.3.33.30 to 3.303.0.3
      privateIntranetAllocationTable from 4.4.44.40 to 4.404.0.4

      This represents the various IP ranges of web sites in the corporate intranet. This setting is used to determine if a site is internal or external. Internal sites are represented by an intranet favicon.

      You might need to update this value after initially installing Bookmarks with no IP ranges or if you want to add a range after installation. This might be the case due to a corporate merger or acquisitions that result in added or deleted IP ranges.

      Any change to IP ranges will require an update to the intranet settings of bookmarks in the database. See the topic Assigning URLs to intranet sites for more information.

      The following commands allow the administrator to either add or remove ipRanges.

      DogearCellConfig.addIpRange('intranetAllocation.ipRange', ['from_range'], ['to_range'])

      Strings. This command will add an additional IP Range.

      [from_range] = the starting IP address of this range

      [to_range] = the ending IP address of this range

      Example:

      DogearCellConfig.addIpRange('intranetAllocation.ipRange','2.2.22.20','2.202.0.2')

      DogearCellConfig.removeIpRange('intranetAllocation.ipRange', ['from_range'], ['to_range]')

      Strings. This command will delete an existing IP Range.

      [from_range] = the starting IP address of this range

      [to_range] = the ending IP address of this range

      Example:

      DogearCellConfig.removeIpRange( 'intranetAllocation.ipRange','2.2.22.20','2.202.0.2')

      DogearCellConfig.clearIpRanges('intranetAllocation.ipRange')

      String.

      Clears all IP ranges recorded in the configuration settings

      Example:

      DogearCellConfig.clearIpRanges('intranetAllocation.ipRange')

    3. See Applying property changes for information about how to save and apply your changes.


    Assign URLs to intranet sites

    Use the URLService commands to assign URLs to intranet sites for your Bookmarks deployment. These commands do not require a file check out or a server restart to take effect. However, after making IP range configuration updates you need to restart Bookmarks for changes to take effect. Then you must run these commands to process URL changes. Use the UrlService commands when the internal IP ranges of your company change. These commands operate on the Bookmarks database and can recalculate whether an existing link is internal or not, based on the IP ranges that are updated using the DogearCellConfig.addIpRange or DogearCellConfig.removeIpRange commands. After making changes, it is a good idea to delete the contents of the Favicons subdirectory. The "favicons" that appear next to each Bookmarks link are cached in the favicon directory, and if you delete the contents of this directory, the icons that appear next to each link will be updated.

    1. See the topic Running Bookmarks administrative commands for information on using administrative commands.

    2. Use the following form for the URLService command:

      URLService.<command_name>(<arguments>)

    3. UrlService commands include:

      UrlService.reprocessIntranetAddress('[href]')

      [href] is exact URL whose intranet range is to be reprocessed .

      Example Usage: UrlService.reprocessIntranetAddress ('http://www.ibm.com')

      There should be no output in wsadmin console if successful.

      UrlService.reprocessIntranetAddressBatch('[fileName]')

      [fileName] is the name of the file containing URLs to be recalculated.

      You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      This command expects a file with URLs to be recalculated on each line. Enter a single URL on each line of the file.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.reprocessIntranet AddressBatch(/opt/test.txt")

      UrlService.reprocessIntranetAddresses()

      This command should be used if there have been no major changes to the network topology and the only goal is to process an update to the configured intranet IP ranges.

      This command reprocesses the intranet status of all Bookmarks URLs by comparing a locally cached version of its IP address to the intranet IP ranges provided in the Bookmarks cell-level configuration document.

      This command is much quicker than UrlService.recalculateIPAddresses , which not only checks the current intranet settings but also regathers the IP address for every URL in the database.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.reprocessIntranet Addresses()

      UrlService.recalculateIPAddress('[href]')

      [href] is exact URL whose intranet range is to be recalculated.

      Example Usage:

      UrlService.recalculateIPAddress('http://www.example.com')

      If you are only re-validating the intranet status of URLs because of a change to intranet IP tables, then UrlService.reprocessIntranetAddress('[href]') should be invoked.

      There should be no output in wsadmin console if successful.

      Example:

      UrlService.recalculateIPAddress("http://www.example.com")

      UrlService.recalculateIPAddressesBatch('[fileName]')

      [fileName] is the name of the file containing URLs to be recalculated.

      This command expects a file with the URLs to be recalculated on each line. Enter a single URL on each line of the file.

      If you are only re-validating the intranet status of URLs because of a change to intranet IP tables, then UrlService.reprocessIntranetAddressesBatch('[fileName]') should be invoked.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.recalculateIPAddressesBatch("c:/Bookmarks/recalc.txt")

      UrlService.recalculateIPAddresses()

      This command recalculates the IP addresses of all the URLs in the database. It works by updating the locally cached copy of the IP address for each URL.

      Run this command can be time consuming for large sized DBs. For each URL in the database, this command will connect to and validate the IP address from the DNS. It takes an average of 8 minutes per 500 URLs, depending on the speed of the network connection.

      If you are simply re-validating the intranet status of URLs because of a change to intranet IP tables, use the UrlService.reprocessIntranetAddress() command to speed the process.

      There should be no output in wsadmin console. Be sure to check logs as URLs that were not successfully updated will be logged.

      Example:

      UrlService.recalculateIPAddresses()

    Manage links

    As the Bookmarks administrator, you can remove broken or unwanted links, and configure what behavior is available to users for managing broken links.


    Related tasks

  • Manage notification for broken links
  • Delete unnecessary links


    Manage notification for broken links

    Configure what behavior is available from the Broken URL form. You configure Bookmarks settings using scripts accessed using the wsadmin client. These scripts use the AdminConfig object available in WebSphere Application Server Admin (wsadmin) to interact with the Bookmarks configuration file. Changes to Bookmarks configuration settings require node synchronization and a restart of the Bookmarks server before they take effect.

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details. When a user takes action to remove or correct a broken link, they can remove the link from their own bookmarks. You can configure whether the user can notify all other users about the broken link so they can also take action. The default is to enable the option, but, if you are administering a large deployment, you may want to turn this option off to stop notification mail from going to large groups. You can also turn on or off an option that notifies you each time a broken URL notification is sent, giving you the opportunity to correct or remove the link. Again, you may want to disable this option if the mail volume is excessive.

    Disabling this filter introduces vulnerability to XSS and other types of malicious attack. See Securing applications from malicious attack for additional information.

    1. Open a command window and start the wsadmin command line tool as described in the topic, Starting the wsadmin client.

    2. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    3. To edit a property using the wsadmin client, use the following command: DogearCellService .updateConfig("property", "value") where property is one of the following properties and value is the new value with which you want to set that property.

      brokenURLService.brokenURL.notifyAllOwners

      Boolean. true/false.

      Enables/disables an option on the Broken URL form to Send notification to all users who bookmarked this so that other users can also take action on a broken URL.

      If the notification option is enabled (True) then, after a user selects the notification option, this notification message displays: Notification will be sent to {x} people. If this option is disabled (False), the option to notify all bookmark owners is not visible and only the current owner of the bookmark is notified.

      brokenURLService.brokenURL.notifyAdmin

      Boolean. true/false.

      Enables/disables an option to notify the Bookmarks administrator each time a Broken URL notification is sent to one or more users.

      If the notification option is disabled, the Bookmarks administrator is not notified of broken links.

    4. See Applying property changes for information about how to save and apply your changes.


    Related

  • Manage links


    Replace URLs in bookmarks

    Run a command to replace URLs in bookmarks to correct broken links.

    .

    To edit configuration files, you must use the wsadmin client. See Start the wsadmin client for details.

    There may be times when you want to update the URLs for a collections of bookmarks. For example, when a web site changes its host name permanently, you will want to update all of the associated bookmarks with the new host name. For example, if http://site1.mycompany.com is changed to be http://site2.mycompany.com, run this replace URL command to update all bookmarks on http://site1.mycomapny.com.

    The new URL may already be bookmarked by some users who also bookmarked the original URL. In those cases, you can not simply update the bookmark to the new URL as the Bookmarks application does not allow a user to have two or more valid bookmarks to the same URL. The IDs of those duplicated bookmarks will be saved to a file that you specify. You can either leave those duplicated bookmarks in the application or run LinkService.deleteLinkByURLBatch('<file>') to delete them from the application.

    When you run this command you can replace URLs in the following ways:

    • Specify a single URL and a replacement URL and make an immediate update.

    • Use a pattern with wildcards to find and replace multiple URLs. The URLs that match the pattern are written to a file, along with the specified replacement URL. Once you verify the pairs, you run a second command to upload the file and perform the updates.

    • Upload a file containing URLs to find and the replacement URLs.

    1. See the topic Running Bookmarks administrative commands for information on using administrative commands.

    2. Use the following form for the UrlService command:

      UrlService.<command_name>(<parameters>)

    3. Run the following command to replace an existing URL with a new URL you specify:

      UrlService.replaceURLs('original_URL_str', 'replace_URL_str', 'log_file')

      Parameters:

      original_URL_str

      A plain text string that specifies the URL to be replaced

      replace_URL_str

      A plain text string that specifies the replacement URL

      log_file

      A local file path that is used to log any messages that result from running the command. The file will be created if it is not exist; otherwise, new log data is appended to the data in the existing file.

      The exact match command finds the bookmarks with the specified URL and updates them to the specified replacement URL. The command runs immediately.

      Example:

      wsadmin>UrlService.replaceURLs('http://www.mysite.com', 'http://www.mycompany.com', 'c:\\log.txt') 
      This command searches for the URL .http://www.mysite.com. and replaces each instance with .http://www.mycompany.com.. Log messages are printed to c:\log.txt.

    4. To find URLs to replace and write them to a file, enter this command:

      UrlService.findURLsToReplace('<base>', '<URL_pattern>', '<replace_str>', '<output_file>', '<log_file>')

      Parameters:

      base

      Aplain text string that is used to limit the number of URLs to be scanned. Only those URLs containing <base> string are scanned.

      URL_pattern

      AJava-style regular expression that is used to match URLs

      replace_str

      Plain text string that is used to replace the found pattern in the matched URL

      output_file

      Local file path that is used to store the matched URLs and their replacement URLs. The file will be created if it does not exist and will be appended if it already exists.

      log_file

      Local file path that is used to log any messages that result from running the command. The file will be created if it does not exist; otherwise, new log data is appended to the data in the existing file.

      This command scans the Bookmarks database to URLs with associated bookmarks that match the given <URL_pattern> and then calculates the replacement URLs based on the <replace_str>. The command does not update the matched URLs in the Bookmarks. Scan results are saved in <output_file> so you can check the matched URLs and their replacement URLs to verify that the pairs are what you want. If not, you can manually edit the file to add, remove, or update the URL pairs. The command runs as a backend task in the system

      Example:

      wsadmin>UrlService.findURLsToReplace('mycompany', 'w3\\.mycompany\\.com', 'www.mycompany.com', 'c:\\output.txt', 'c:\\log.txt') 

      This command scans all URLs containing the string 'mycompany' and matches them against the regular expression pattern "w3\\.mycompany\\.com". The "w3.mycompany.com" in the matching URLs will be replaced by "www.mycompany.com". The matched URLs and the replacement URLs are printed into c:\output.txt file. Log messages are printed to c:\log.txt.

    5. To replace the URLs based on the contents of a file, enter this command:

      UrlService.replaceURLs('<input_file>', '<log_file>')

      Parameters:

      input_file

      A text file that specifies pairs of the URL to be replaced and the replacement URL.

      log_file

      A local file path that is used to log any messages that result from running the command. The file will be created if it does not exist; otherwise, new log data is appended to the data in the existing file.

      Specify an input file which contains the original URLs and the replacement URLs. You can use the output file of the findURLsToReplace command as the input here. URLs are updated unless a bookmark for the replacement URL already exists. Those are skipped to avoid creating duplicate bookmarks. Log messages are printed to c:\log.txt.

      Example:

      wsadmin>UrlService.replaceURLs('c:\\output.txt', 'c:\\log.txt')
      This command loads the URL pairs in the file c:\output.txt and updates all the bookmarks on the specified original URLs to the replacement URLs. Log messages are printed to c:\log.txt.


    Delete unnecessary links

    Use these commands to delete unnecessary links for your Bookmarks deployment . for example, to remove offensive content. These commands do not require a file check out or a server restart to take effect.

    Use the LinkService command to remove links from a Bookmarks database. You can delete links in these ways:

    • Provide the link UID (which you can obtain by right-clicking on the bookmark, clicking "Copy link location" and pasting into a text editor, and then copying the 36 alphanumeric characters (the UID) that occur after "link=").

    • Provide the email address of the person that created the link and URL of the link.

    • Provide a single URL or a text file containing multiple URLs to delete all links associated with the specified URLs.

    Before you delete links, you can send a notification email to bookmark owners to let them know when the link will be deleted.

    1. See the topic Running Bookmarks administrative commands for information on using administrative commands.

    2. Use the following form for the LinkService command:

      LinkService.<command_name>(<arguments>)

    3. You can delete links in two ways - using the UID (which you can obtain by right-clicking on the bookmark, clicking "Copy link location" and pasting into a text editor, and then copying the 36 alphanumeric characters (the UID) that occur after "link=") or, alternately, by using the email address of the person that created the link and URL of the link.

      LinkService.deleteLinkByUID('[UID]')

      Deletes a single bookmark matching the UID specified.

      [UID] is the UID of the bookmark.

      When creating the text file, enter one UID per line.

      There should be no output in wsadmin console if successful.

      Example:

      LinkService.deleteLinkByUID("0A5G09219578A357F378C607680F7600000B")

      LinkService.deleteLinkByUIDBatch('[fileName]')

      Deletes a list of bookmarks matching the UIDs specified.

      [fileName] is the name of a text file containing the UIDs to be deleted. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      There should be no output in wsadmin console. Be sure to check logs as UIDs that were not successfully deleted will be logged.

      Example:

      LinkService.deleteLinkByUIDBatch("/opt/Bookmarks/badlinks.txt")

      If you are using DB2 as your database, you can create the batch file for deleting all of the bookmarks associated with a user this way:

      1. Open the DB2 Control Center.

      2. From the command editor, connect to the Bookmarks database.

      3. Get the user's person ID from the person table: select person_id from dogear.person where email='someEmail@company.com'

      4. Get the user's bookmark link IDs: select link_id from dogear.link

        ...where person='personId'

      5. Based on the results returned, highlight a group of bookmark links. We suggest 100 to 200 links at a time.

      6. Click on Selected and Export.

      7. Make sure the option No character delimiter is selected and export to a text file on your file system

      8. Run the LinkService.deleteLinkByUIDBatch command with the file created.

      LinkService.deleteLinkByPersonURL('[email]', '[href]')

      Deletes a single bookmark matching the email and URL specified.

      [email] is the address of the person who created the bookmark.

      [href] is the URL of the bookmark you want to delete. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console if successful.

      Example:

      LinkService.deleteLinkByPersonURL("jane_doe@acme.com","http://bad.url.com")

      LinkService.deleteLinkByPersonURLBatch('[fileName]')

      Deletes multiple bookmarks matching specified email addresses and URLs.

      [fileName] is the filename containing the addresses and URL to be deleted. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      This file must be formatted with [email] <space> [href] on each line. For example, a single line would look as follows:

      email@ibm.com http://www.theurl.com Note the single whitespace character between the address and the URL.

      [email] is the email address of the person with the bookmark.

      [href] is the URL of the bookmark. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console. Be sure to check logs as addresses and URLs matching the bookmark that was not successfully deleted will be logged.

      Example:

      LinkService.deleteLinkByPersonURLBatch("c:/Bookmarks/delete.txt")

      LinkService.deleteLinksByURL('[href]')

      Deletes all bookmarks (public and private) matching the URL specified. Those bookmarks will be marked as deleted in the database waiting for the search indexer to detect them and update the index.

      [href] is the URL of the bookmark you want to delete. It is important to input the exact href including the protocol.

      There should be no output in the wsadmin console if successful.

      Example:

      LinkService.deleteLinksByURL("http://bad.url.com")

      LinkService.deleteLinksByURLBatch('[fileName]')

      Deletes multiple bookmarks matching specified URLs.

      [fileName] is the filename containing the URLs to be deleted. Separate URLS with line breaks. You must create this text file and save it in a local directory (local to the server where you are running the wsadmin processor).

      There should be no output in the wsadmin console. Be sure to check logs as bookmarks matching specified URLs that are not successfully deleted will be logged.

      Example:

      LinkService.deleteLinksByURLBatch("c:/Bookmarks/delete_links.txt")

      UrlService.notifyBrokenURLOwners('<broken_URL>', '<replace_URL>')

      This command will find all owners of a single URL and send them an email notification. Optionally, you can supply a <replace_URL> as the suggested substitute URL for the broken URL.

      [broken_URL] is a plain text string that represents the broken URL.

      [replace_URL] is a plain text string that is the suggested substitute URL for the broken URL.

      Example:

      UrlService.notifyBrokenURLOwners('http://www.example.com','http://w3.example2.com') 
      This command will find all users who bookmarked http://www.example.com (either public or private bookmarks) and send them email notifications. In the notification, it will suggest that bookmark owners replace the old URL with the new one http://www.example2.com.

      UrlService.batchNotifyBrokenURLOwners('<repository_file>')

      This command will iterate all the broken URL and substitute URL pairs in the given <repository_file> and send email notifications to all the bookmark owners of the broken URLs in the file. In the notification, you can provide the corresponding <replace_URL> as the suggested substitute URL for the broken URL.

      [repository_file] is a local file path that contains the broken URLs and their suggested substitute URLs. Each pair of original URL and substitute URL should be placed in one line and separated by either white spaces or tabs.

      Example:

      UrlService.batchNotifyBrokenURLOwners('c:\\brokenurls.txt') 

      This command will load the URL pairs in c:\brokenurls.txt and send email notifications to users who bookmarked those URLs. For each broken URL, Bookmarks will send an email notification.


    Related

  • Manage links
  • Manage inappropriate content

    Restrict link redirects

    You can restrict link redirects to allow users to directly access URLs. This is an optional configuration change.

    To restrict link redirects check out LotusConnections-config.xml, open it in an editor and add some elements, and then check it back in.

    Restriction: If you implement this configuration change, links to external sites will be direct, rather than be redirected from Bookmarks, but links within Connections will not work.

    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="dogear.link.noredirect">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()

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

    Specify a list of fonts and colors users can use for bookmark lists

    If you want to limit the allowable fonts users can use when embedding bookmarks in a web page to to a list you specify, create a white list. If a white list is enabled, only the fonts specified can be used to display a list of bookmarks in a web page.

    To create a white list for fonts and colors, edit the embedStyle property in the dogear-config-cell.xml file.

    To edit configuration files that control configurable settings for bookmark icons, you must use the wsadmin client. See Start the wsadmin client for details.

    1. Access the Bookmarks configuration file as described in the topic Accessing the Bookmarks configuration file.

    2. To update configuration properties enter the appropriate property into the following command:

      DogearCellConfig.updateConfig(.[property]', .[value]')

      where: [property] is a valid cell-level configuration setting [value] is the new value for the setting.

    3. Change the value of embedStyle enabled from false to true.

    4. Set the font families and font colors you want to allow for the bookmark list. For example:

      <!--The embed snippet CSS white list
         -->
      	  <embedStyle enabled="false">
      	    <!-- font family white list-->
      	    <stringProperty name="font.familyList">Times,Arial,Times New Roman,Verdana,Helvetica,Geneva</stringProperty>
      	    <!-- font color white list-->
      	    <stringProperty name="font.colorList">red,blue,green,yellow,orange,black,white,gold,snow</stringProperty>
      	  </embedStyle>

    5. Save your changes.

    6. See Applying property changes for information about how to save and apply your changes.


    Results

    Users who embed bookmarks in a web page will be limited to the font families and colors in this list. If a user specifies a font family or color not on the list, the font and color will default to a font and color on the list.


    Related tasks

  • Change common configuration property values

    Manage multiple Bookmark buttons

    If you are creating bookmarks on more than one server, you may have to rename your Bookmarks browser buttons to avoid conflicts. When you install an Add Bookmark button to your browser toolbar, it is associated with a particular server. If you want to create bookmarks for Bookmarks deployments on more than one server, you must install an Add Bookmark button for each server. You may find, however, that if you click ButtonA to create a bookmark on ServerA, then click ButtonB to create a bookmark on ServerB, you will create another bookmark for ServerA instead. If this happens, follow these steps to rename the second Add Bookmark button to a unique name.

    1. Right-click the button you want to rename.

    2. Choose properties.

    3. Enter a new name.

    4. Click OK to save the button with the new name.

    Administer Communities

    You configure and administer Communities using scripts accessed using the IBM WebSphere Application Server wsadmin client.

    You can update the Communities environment in two ways:

    • Configuration settings. Modify these settings to control various configurable applications within Communities. When you make configuration changes, you use scripts to check out the Communities configuration file, 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 Communities environment and community users. Administrative commands do not require a server restart to take effect.


    Related

  • Manage users
  • Add a custom theme to Communities
  • IBM Connections Connector for Lotus Quickr

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

    Run Communities administrative commands

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

    To use administrative commands, you must use the wsadmin client. See Start the wsadmin client for details. Administrative commands interact with the Communities 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 Communities 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 Communities 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 Communities Jython script interpreter :

      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.

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


    Communities administrative commands

    Use the commands listed to perform administrative tasks for Communities. 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 Communities. Each section describes the commands for a specific service. The commands are listed in alphabetical order.


    CommunitiesListService commands

    CommunitiesListService.filterListByApp(List list, String filter)

    Returns a new list containing only the communities where the application type matches the regular expression filter. Examples of applications include IBM Lotus Quickr Wiki, and Lotus Quickr Teamspace.

    Depending on how the list is returned, you can filter an application from:

    • All links, when the list is returned by the ManagedAppService.fetchAllLink command.

    • A specific community, when the list is returned by the CommunitiesService.fetchCommByName command.

    • The communities that a specific user is a member or owner of, when the list is returned by the CommunitiesService.fetchCommByMember command.

    The following example gets a list of all the communities that the specified user is a member or owner of, and then gets a list of all the links associated with that user. The filter command then filters that list by the application name specified. A list of communities associated with the specified application is returned.

    wsadmin>bymember=CommunitiesService.fetchCommByMember("users_email_address")
    wsadmin>links=ManagedAppService.fetchLinkByComm(bymember)
    wsadmin>CommunitiesListService.filterListByApp(links,"application_name")

    CommunitiesListService.filterListById(List list, String filter)

    Returns a new list containing only the communities and subcommunities whose ID matches the regular expression filter.

    For example:

    wwsadmin>all=CommunitiesService.fetchAllComm()
    wsadmin>CommunitiesListService.filterListById(all, "c6a2c680-5933-4efa-9a14-be1723445d30")
    This example returns a list of all the communities and subcommunities and then filters the results by ID to list only the communities and subcommunities

    ...where the ID matches the one specified.

    CommunitiesListService.filterListByName(List list, String filter)

    Returns a new list containing only the communities and subcommunities whose names match the regular expression filter.

    For example:

    wsadmin>allComm=CommunitiesService.fetchAllComm()
    wsadmin>CommunitiesListService.filterListByName(allComm,"My Community Name")
    This example returns a list of all communities and subcommunities using the fetchAllComm command (command is set to a variable that will be used in the next command) and then filters the results to get the information for a particular community or subcommunity.

    CommunitiesListService.filterListByType(List list, String filter)

    Returns a new list containing only the communities and subcommunities whose type (private, public, or publicInviteOnly) matches the regular expression filter.

    For example:

    wsadmin>commByMember=CommunitiesService.fetchCommByMember("jane_smith@company.com")
    wsadmin>CommunitiesListService.filterListByType(commByMember,"publicInviteOnly")
    This example retrieves a list of all the communities and subcommunities for a particular user (in this case Jane Smith) and then filters that list to display all the user's communities and subcommunities that are publicInviteOnly. The fetch command is set to a variable that will be used in the listService command.


    CommunitiesMemberService commands

    CommunitiesMemberService.getMemberExtIdByEmail("email")

    See Synchronizing user data using administrative commands for details.

    CommunitiesMemberService.getMemberExtIdByLogin("login")

    See Synchronizing user data using administrative commands for details.

    CommunitiesMemberService.inactivateMemberByEmail("email")

    See Synchronizing user data using administrative commands for details.

    CommunitiesMemberService.inactivateMemberByExtId("externalID")

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.

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

    See Synchronizing user data using administrative commands for details.


    CommunitiesQEventService commands

    CommunitiesQEventService.clearQueuedEventByEventId(String eventId)

    Clears queued life-cycle replay events with the specified event ID, where eventId is a string. The events are removed from the queue and are not processed.

    The return value is the number of events that were cleared.

    For example:

    CommunitiesQEventService.clearQueuedEventsByEventId("2d93497d-065a-4022ae25-a4b52598d11a")

    CommunitiesQEventService.clearQueuedEventsByRemoteAppDefId(String remoteAppDefId)

    Clears queued life-cycle replay events with the specified associated application ID, where remoteAppDefId is one of the following: Activities, Blog, IdeationBlog, Files, Forum, Wiki, and StatusUpdates. The application IDs are case sensitive and must be entered as indicated in this documentation.

    The return value is the number of events that were cleared.

    For example:

    CommunitiesQEventService.clearQueuedEventsByRemoteAppDefId("Wiki")

    CommunitiesQEventService.clearQueuedEventsByResourceId(String resourceType, String resourceId)

    Clears queued life-cycle replay events with the specified resource ID, where resourceType and resourceId are both strings. The events are removed from the queue and are not processed.

    The resourceType parameter is always set to "community". The resourceId parameter is a value that can be obtained using one of the CommunitiesQEventService.viewQueuedEvents commands.

    The return value is the number of events that were cleared.

    For example:

    CommunitiesQEventService.clearQueuedEventsByResourceId("community", "e952cf0c-a86c-4e26-b1e0-f8bf40a75804")

    CommunitiesQEventService.clearQueuedEventsByResourceType(String resourceType)

    Clears queued life-cycle replay events with the specified resource type, where resourceType is a string. The events are removed from the queue and are not processed.

    The resourceType parameter is always "community".

    The return value is the number of events that were cleared.

    For example:

    CommunitiesQEventService.clearQueuedEventsByResourceType("community")

    CommunitiesQEventService.retryQueuedEventsByRemoteAppDefId(String remoteAppDefId)

    Retries queued life-cycle replay events with the specified associated application ID, where remoteAppDefId is one of the following: Activities, Blog, IdeationBlog, Files, Forum, Wiki, and StatusUpdates. The application IDs are case sensitive and must be entered as indicated in this documentation.

    The return value is either 1 or 0. 1 indicates success; 0 indicates failure.

    For example:

    CommunitiesQEventService.retryQueuedEventsByRemoteAppDefId("Wiki")

    CommunitiesQEventService.retryQueuedEventsByResourceId(String resourceType, String resourceId)

    Retries queued life-cycle replay events with the specified resource type and resource ID, where resourceType and resourceId are both strings.

    The resourceType parameter is always set to "community". The resourceId parameter is a value that can be obtained using one of the CommunitiesQEventService.viewQueuedEvents commands.

    The return value is either 1 or 0. 1 indicates success; 0 indicates failure.

    For example:

    CommunitiesQEventService.retryQueuedEventsByResourceId("community", "e952cf0c-a86c-4e26-b1e0-f8bf40a75804")

    CommunitiesQEventService.retryQueuedEventsByResourceType(String resourceType)

    Retries queued life-cycle replay events with the specified resource type, where resourceType is a string. The value of resourceType is always "community".

    The return value is either "retry succeed" or 0. 0 indicates failure.

    For example:

    CommunitiesQEventService.retryQueuedEventsByResourceType("community")

    CommunitiesQEventService.viewQueuedEventsByRemoteAppDefId(String remoteAppDefId, HashMap lastEvent, int maxRows)

    Lists the queued life-cycle replay events associated with the specified remote application ID, where:

    • remoteAppDefId is one of the following: Activities, Blog, IdeationBlog, Files, Forum, Wiki, and StatusUpdates. The application IDs are case sensitive and must be entered as indicated in this documentation.

    • lastEvent specifies the last row of the previous batch. This is a HashMap object. To obtain the first batch, specify None.

    • maxRows is the number of rows to be retrieved and viewed with a single command. Use maxRows when there is a large number of rows, 200, for example, to break up both the database reads and the display into batches.

    Return a HashMap that is the last viewed row. When there are no more rows, the value None is returned. This makes it straightforward to loop over all rows a few at a time.

    For example:

    CommunitiesQEventService.viewQueuedEventsByRemoteAppDefId("Blog", None, 100)

    Thus, to display all queued events of remoteAppDefId type Activities in batches of 10, when there are 200 entries, you might code in Jython:

    lastRow = CommunitiesQEventService.viewQueuedEventsByRemoteAppDefId(.Activities., None, 10)
    while (lastRow != None)
    lastRow = CommunitiesQEventService. viewQueuedEventsByRemoteAppDefId(.Activities., lastRow, 10)

    CommunitiesQEventService.viewQueuedEventsByResourceId(String resourceType, String resourceId, HashMap lastEvent, int maxRows)

    Lists the queued life-cycle replay events with the specified resource type and resource ID, where:

    • resourceType is the string "community".

    • resourceId is the communityUuid. This is a string.

    • lastEvent is a HashMap object.

    • maxRows is the number of rows to be retrieved and viewed with a single command. Use maxRows when there is a large number of rows, 200, for example, to break up both the database reads and the display into batches.

    Return a HashMap, which is the last viewed row. When there are no more rows, the value None is returned. This makes it straightforward to loop over all rows a few at a time.

    For example:

    CommunitiesQEventService.viewQueuedEventsByResourceId("community", "e952cf0c-a86c-4e26-b1e0-f8bf40a75804", None, 100)

    For example, you might use the following Jython code to display all queued events of resourceType "community" and resourceId b46300c7-7837-4ba3-b26b-3fcf67a75bba, in batches of 10 when there are 200 entries:

    lastRow = CommunitiesQEventService.viewQueuedEventsByResourceId(.community., "b46300c7-7837-4ba3-b26b-3fcf67a75bba", None, 10)
    while (lastRow != None)
    lastRow = CommunitiesQEventService.viewQueuedEventsByResourceId(.community., "b46300c7-7837-4ba3-b26b-3fcf67a75bba", None, 10)

    CommunitiesQEventService.viewQueuedEventsByResourceType(String resourceType, HashMap lastEvent, int maxRows)

    Lists the queued life-cycle replay events with the specified resource type, where:

    • resourceType is the string "community".

    • lastEvent specifies the last row of the previous batch. This is a HashMap object. To obtain the first batch, specify None.

    • maxRows is the number of rows to be retrieved and viewed with a single command. Use maxRows when there is a large number of rows, 200, for example, to break up both the database reads and the display into batches.

    For example:

    CommunitiesQEventService.viewQueuedEventsByResourceType("community", None, 100)

    This command returns a HashMap that is the last viewed row. When there are no more rows, the value None is returned. This makes it straightforward to loop over all rows a few rows at a time.

    For example, you might use the following Jython code to display all queued events of resourceType community in batches of 10 when there are 200 events:

    lastRow = CommunitiesQEventService.viewQueuedEventsByResourceType(.community., None, 10)
    while (lastRow != None)
    lastRow = CommunitiesQEventService.viewQueuedEventsByResourceType(.community., lastRow, 10)

    CommunitiesQEventService.viewQueuedEventsSummary()

    Lists a summary of all of the life-cycle replay events that are currently queued for processing.


    CommunitiesRemoteAppService commands

    CommunitiesRemoteAppService.resyncRemoteAppsForCommunity(communityUuid)

    See Synchronizing remote application data with the Communities database for details.

    CommunitiesRemoteAppService.resyncRemoteAppsForAllCommunities()

    See Synchronizing remote application data with the Communities database for details.

    CommunitiesRemoteAppService.restartResyncRemoteAppsForAllCommunities(last processed communityUuid)

    See Synchronizing remote application data with the Communities database for details.


    Co