Configuring and Customizing Your Environment

In this section:

You use the Configuration Tab to configure:

TIBCO WebFOCUS Server Settings

In this section:

Reference:

To open the TIBCO WebFOCUS Server Settings, click the Configuration tab and expand the Reporting Servers folder. You can:

Reference: Server Node Properties

The Server Node properties defined in the Basic pane are explained below.

Basic

Node Name

The name cannot be the same as any other node name, and it cannot contain more than forty-eight (48) characters. When the client accesses this server, it will use this name.

Node Description

Optional. The description of the node that appears in the Configuration pane. If this is omitted, the node name will be used.

x
Host

The Host name or IP address of the Host Server.

TCP/IP Port

The Port number for the TCP listener. The default port is 8120.

HTTP(S) Port

The Port number for the HTTP listener. This is typically one port after the TCP/IP port.

The default HTTP port is 8121.

Security

The security options for the Server connection.

  • Prompt for Credentials. The Client makes an explicit connection to the Server with the user ID and password specified in the Web Security tab. This is the default value.
  • HTTP Basic. The user ID and password are extracted from the authorization header. These credentials are then used to make an explicit connection to the Server. You should only select this option when your web tier is performing Basic Authentication.

    Note: You can verify that the authorization header is available by selecting HTTP Request Info in the Diagnostics tab.

  • Kerberos. The Client passes a Kerberos ticket for the user to the Server, along with the user ID and group memberships assigned to that user. This option enables an end-to-end single sign on solution from the desktop to the Client, from the Client to the Server, and from the Server to supported relational DBMS systems. To use Kerberos authentication, the Server must run in security OPSYS mode.
  • SAP Ticket. The Client passes the user MYSAPSSO cookie, which is created on SAP Enterprise Portal, to the Server. The Server then validates the cookie using the SAP security API. This option enables single sign on from the Client to a Server configured with the Data Adapter for SAP for environments using Open Portal Services in SAP Enterprise Portal.
  • Service Account. Allows you to specify a user ID and password to be used for all connections to the Server.

    The service account credentials are encrypted and stored in the SECURITY keyword of the odin.cfg file. When defined, the service account overrides any other credentials that may be presented for this Server node, and all users connect to the Server using the same credentials. This approach does not make it possible to identify which user is running a given request on the Server in Managed Reporting deployments, and therefore is not recommended for them.

  • Trusted. Allows non-authentication requests to connect to the Server as trusted. After a user is authenticated through a pre-authentication mechanism or a Sign in page, all subsequent requests to the Server are trusted.

    To use this option, the Server Security Provider must also be configured to allow trusted connections, and controls should be placed on the Server to ensure that it rejects connections from unauthorized clients. For example, you should employ the Server RESTRICT_TO_IP setting or configure a network firewall so that only your specified clients can connect to the Server.

    When you create a new Client Configuration, the Trusted option is selected, by default, and the Pass TIBCO WebFOCUS User ID and their Groups and Custom options appear below it. When you accept the default option, Pass TIBCO WebFOCUS User ID and their Groups, the Client passes the ID and group memberships assigned to the user to WebFOCUS Server. When you select the Custom option, the display refreshes to show the User ID and the User's Groups check boxes allowing you to customize the user information passed to the server. The options TIBCO WebFOCUS script variable and HTTP Header Field appear under both check boxes, as shown in the following image.

    The Custom Option on the Client Configuration page, and the configuration of check boxes and settings beneath it. This option includes the USER ID check box with the default WebFOCUS script variable assignment, IBIMR_user, and the User’s Groups check box, with the default WebFOCUS script variable assignment, IBIMR_memberof.

    Under the User ID check box, the TIBCO WebFOCUS script variable option displays the IBIMR_user parameter, by default. Under the User's Groups check box, the TIBCO WebFOCUS script variable option displays the IBIMR_memberof parameter, by default. You can type over the default values in the TIBCO WebFOCUS script variable options, and type your own values in the HTTP Header Field options.

    Note: When configuring the Client to make trusted connections to the Server, you must also enable the Server to accept trusted connections.

Advanced

The Server Node properties from the Advanced pane are explained below.

Service Name

Contains a description for the Server node. This description displays to end users.

Use HTTPS

Enables encrypted communication between the Client and the Server HTTP listener. The default value is off (check box cleared).

This option must be selected if the Server HTTP listener is configured to use SSL. If you are using a self-signed certificate to enable HTTPS communication with a Server, the certificate must be configured in the Java environment where the Client is installed. This enables HTTPS communication between the Server and the Administration Console.

TLS

Enables data encryption when transmitting data over the internet to ensure data privacy. The default value is off (check box cleared).

When selected, the Compression and Encryption options are hidden because TLS encrypts and compresses the data, by default.

Compression

Enables data compression. By default, data compression is disabled.

Encryption

Sets data encryption ability and the symmetric cryptography method used.

Select one of the following options from the drop-down list:

  • 0. Off. This is the default value.
  • AES. Advanced Encryption Standard. The AES selections are in the format 
    CIPHER(x)(-MODE)

    where:

    CIPHER

    Is AES128, AES192, AES256.

    x

    Is optional and defines an RSA key length of 1024 bits. When this is not specified, the RSA key is 512 bits.

    CBC

    Is optional and defines the use of Cipher Block Chaining (CBC) mode. When the mode is not specified, Electronic Code Book (ECB) is used.

    For example, AES256x-CBC is the AES256 cipher with a 1024-bit RSA key in CBC mode. AES128 is the AES128 cipher with a 512-bit RSA key in ECB mode.

Connect Limit

Specifies the number of seconds that the Client will hold the pending connection. Other possible values are 0 (no wait) and -1 (infinite wait). The default value is -1.

Maximum Wait

Specifies the time, in seconds, that the Client will wait before timeout. You can optionally specify different return times for the first row and other rows. A single number indicates that the return time is valid for any row. If two numbers are separated by a comma, the first number specifies the return time for the first row and the second number specifies the return time for the subsequent rows. The default value is -1, which indicates an infinite wait time.

Security Object

For any security option, an administrator can specify one or more HTTP header names and/or cookie names as follows:

  • Cookie. Specify each HTTP cookie name separated by a comma (,). For example:
    cookie_name1, cookie_name2
  • Header. Specify each HTTP header name separated by a comma (,). For example:
    header_name1, header_name2

Note:

  • HTTP cookie and header names must not contain commas (,) or colons (:). These are reserved delimiters.
  • REMOTE_USER is a special type of HTTP header variable whose contents will not be sent to the Server. Therefore, it is not a valid HTTP header value. Instead, specify the WF_REMOTE_USER variable.

Basic Cluster Manager Configuration Properties

Node Name

Is the host name or IP address of the server.

Node Description

Optional. The description of the node that appears in the Configuration pane. If this is omitted, the node name will be used.

Remote CLM Host

Is the Host name or IP address of the Cluster Manager on which a remote Cluster Manager (CLM) is listening. If more than one address is specified, one of the addresses will be randomly selected until a successful connection to the CLM happens. The number of IP addresses defined in this setting must be the same as the number of port numbers defined in Remote CLM Port. Separate multiple host names or IP addresses with a comma.

Remote CLM Port

Is the UDP number of the Port on which the Cluster Manger server is listening. The default port is 8200. If more than one port number is specified, the number of port numbers must be the same as the number of IP addresses defined in Remote CLM Host. Separate multiple host names or IP addresses with a comma.

Security

The security options for the Server cluster.

  • Prompt for Credentials. The Client makes an explicit connection to the Cluster Manager with the user ID and password specified in the Web Security tab. This is the default value.
  • HTTP Basic. The user ID and password are extracted from the authorization header. These credentials are then used to make an explicit connection to the Cluster Manager. You should only select this option when your web tier is performing Basic Authentication.

    Note: You can verify that the authorization header is available in by selecting HTTP Request Info in the Diagnostics tab.

  • Kerberos. The Client passes a Kerberos ticket for the user to the Cluster Manager, along with the user ID and group memberships assigned to that user. This option enables an end-to-end single sign on solution from the desktop to the Client, from the Client to the Cluster Manager, and from the Cluster Manager to supported relational DBMS systems. To use Kerberos authentication, the Cluster Manager must run in security OPSYS mode.
  • SAP Ticket. The Client passes the user MYSAPSSO cookie, which is created on SAP Enterprise Portal, to the Cluster Manager. The Cluster Manager then validates the cookie using the SAP security API. This option enables single sign on from the Client to a Cluster Manager configured with the Data Adapter for SAP for environments using Open Portal Services in SAP Enterprise Portal.
  • Service Account. Allows you to specify a user ID and password to be used for all connections to the Cluster Manager.

    The service account credentials are encrypted and stored in the SECURITY keyword of the odin.cfg file. When defined, the service account overrides any other credentials that may be presented for this Cluster Manager node, and all users connect to the Cluster Manager using the same credentials. This approach does not make it possible to identify which user is running a given request on the Cluster Manager in Managed Reporting deployments, and therefore is not recommended for them.

  • Trusted. Allows you to connect to the Cluster Manager with only a user ID. This option is useful when no password is available for the user. Controls should be placed on the Cluster Manager to ensure that connections from unauthorized clients are rejected. For example, you can employ the Cluster Manager RESTRICT_TO_IP setting or configure a network firewall so that only a particular client can connect to the Cluster Manager.

    When you create a new Cluster Manager Configuration, the Trusted option is selected, by default, and the Pass TIBCO WebFOCUS User ID and their Groups, and Custom options appear below it.

    When you accept the default option, Pass TIBCO WebFOCUS User ID and their Groups, the Client passes the ID and group memberships assigned to the user to the WebFOCUS Server. When you select the Custom option, additional settings appear and you can customize the user information sent from the Client to the WebFOCUS Server.

    Note: When configuring the Client to make trusted connections to the Server, you must also enable the Cluster Manager to accept trusted connections.

Advanced Cluster Manager Configuration Properties

Use HTTPS

Enables encrypted communication between the Client and the HTTP listener.

The default value is off.

This option must be selected if the Cluster Manager HTTP listener is configured to use SSL. If you are using a self-signed certificate to enable HTTPS communication with a Cluster Manager , the certificate must be configured in the Java environment where the WebFOCUS Client is installed. This enables HTTPS communication between the Cluster Manager and the Administration Console.

Compression

Enables data compression. By default, data compression is disabled.

Encryption

Sets data encryption ability and the symmetric cryptography method used.

Select one of the following options from the drop-down list:

  • 0. Off. This is the default value.
  • AES. Advanced Encryption Standard. The AES selections are in the format
    CIPHER(x)(-MODE)

    where:

    CIPHER

    Is AES128, AES192, AES256.

    x

    Is optional and defines an RSA key length of 1024 bits. When this is not specified, the RSA key is 512 bits.

    CBC

    Is optional and defines the use of Cipher Block Chaining (CBC) mode. When the mode is not specified, Electronic Code Book (ECB) is used.

    For example, AES256x-CBC is the AES256 cipher with a 1024-bit RSA key in CBC mode. AES128 is the AES128 cipher with a 512-bit RSA key in ECB mode.

  • IBCRYPT. User-defined IBCRYPT DLL is loaded.
Connect Limit

Specifies the number of seconds that the Client will hold the pending connection. This is useful in a cluster deployment to avoid a lengthy delay of failover response. Other possible values are 0 (no wait) and -1 (infinite wait). The default value is -1.

Maximum Wait

Specifies the time, in seconds, that the Client will wait before timeout. You can optionally specify different return times for the first row and other rows. A single number indicates the return time is valid for any row. If two numbers are separated by a comma, the first number specifies the return time for the first row and the second number specifies the return time for the subsequent rows. The default value is -1, which indicates an infinite wait time.

Security Object

For any security option, an administrator can specify one or more HTTP header names or cookie names as follows:

  • Cookie. Specify each HTTP cookie name separated by a comma (,). For example:

    cookie_name1, cookie_name2

  • Header. Specify each HTTP header name separated by a comma (,). For example:

    header_name1, header_name2

Note:

  • HTTP cookie and header names must not contain commas (,) or colons (:). These are reserved delimiters.
  • REMOTE_USER is a special type of HTTP header variable whose contents will not be sent to the Server. Therefore, it is not a valid HTTP header value. Instead, specify the WF_REMOTE_USER variable.

Configuring TIBCO WebFOCUS Server Connections

In this section:

How to:

Server connection nodes contain all of the information necessary for the Client to connect with and make use of a Server. A Server connection node provides access to one server. A Cluster Manager node provides access to multiple servers. Changes you make to the configuration in this section are captured in the odin.cfg file, located in drive:\ibi\WebFOCUS82\client\wfc\etc on Windows, or located in install_directory/ibi/WebFOCUS82/client/wfc/etc on UNIX or Linux.

The names of all Reporting Server Connection nodes also appear in the Multiple Servers List. This list is located in two places on the Hub. It appears above the Application Directories tree of the Application Directories area and in the Server Administration section of the Management Center area menu.

When you add a Reporting Server Connection node, the name of that node appears on the list. When you delete a Reporting Server Connection node, the name of that node disappears from the list. If you change the name of an existing Reporting Server Connection node, the new name is added, but the name of the existing node remains in the list until you delete the node it represents from the Reporting Server Connections page.

Procedure: How to Open the WebFOCUS Server Console From the WebFOCUS Administration Console

You can make global configuration changes in the server environment by using the Server Console.

  1. In the Administration Console, click the Configuration tab. Expand the Reporting Servers folder and expand the Server Connections folder.

    The existing Servers are shown.

  2. Right-click a Server node, and click Reporting Server Console.

    If you are prompted to sign in, type the credentials of the Server Administrator.

    The Server Console opens in a separate window.

For more information about the Server Console, see the Server Administration manual, or click Help.

Procedure: How to Add a WebFOCUS Server Server Connection

  1. In the Administration Console, click the Configuration tab, and expand the Reporting Servers folder.
  2. Right-click the Server Connections folder and click New.

    The Client Configuration pane opens.

  3. In the Client Configuration pane, type the node name, host, and TCP/IP port. You can optionally specify a node description and HTTP(S) port.

    Note: The name cannot be the same as any other node name, and it cannot contain more than forty-eight (48) characters. When the client accesses this server, it will use this name.

  4. Select the type of security to use when connecting to this Server.
    • If you select Prompt for Credentials or HTTP Basic, proceed to step 8.

      Note: If you are using HTTP Basic authentication, you can verify the authorization header by selecting HTTP Request Info in the Diagnostics tab.

    • If you select Kerberos or SAP Ticket, proceed to step 8.

      Note: See Configuring Kerberos for Single Sign On for additional setup requirements.

    • If you select Service Account, proceed to step 5.
    • If you select Trusted, proceed to step 6.

      Trusted is the default. This is the recommended approach to connect to a Server.

  5. If you selected Service Account, type the Service Account ID and password, then proceed to step 8.
  6. If you selected Trusted, configure the behavior of the trusted connection between the Client and the Server:
    • If you would like to pass the user ID and group information to the Server using the IBIMR_user and IBIMR_group script variables respectively, proceed to step 8. This is the default behavior.
    • If you would like to pass only the user ID, or to pass the user ID and/or group information with a different variable name or using HTTP headers instead of script variables, select the Custom radio button and proceed to step 7.
  7. If you selected Trusted - Custom, customize the information sent to the Server, and the script variables or HTTP headers used.
    1. User ID is pre-selected. Select TIBCO WebFOCUS script variable or HTTP Header field, depending on how you will pass user IDs. Accept the default script variable, IBIMR_User, or type an alternative script variable or HTTP Header field.
    2. If you would like to pass group information to the Server, select User's Groups, then select TIBCO WebFOCUS script variable or HTTP Header field, depending on how you will pass group information. Accept the default script variable, IBIMR_memberof, or type an alternative script variable or HTTP Header field.

    For more information on using TIBCO WebFOCUS script variables and HTTP headers, see Manipulating WebFOCUSDB2 Web Query Variables. For more information on configuring trusted connections on the Server, see Configuring Trusted Connections.

  8. Optionally, expand the Advanced section to customize the properties for service name, Use HTTPS, Compression, Encryption, Connection Limit, Maximum Wait, and Security Object. If left blank, these options use the default properties.

    Note: When configuring the Client to make trusted connections to the Server, you must also enable the Server to accept trusted connections.

    For more information about the Advanced settings, see Server Node Properties.

  9. Click Save.

    A node for the new WebFOCUS Server connection appears in the tree under the Server Connections folder. The name of the new WebFOCUS Reporting Server connection also appears in the Multiple Servers List. This list is located in two places on the Hub. It appears above the Application Directories tree of the Application Directories area and in the Server Administration section of the Management Center area menu.

Procedure: How to Modify a WebFOCUS Server Connection

  1. In the Administration Console, click the Configuration tab, and expand the Reporting Servers folder.
  2. Click the server connection you would like to modify.

    The connection properties appear in the Client Configuration pane.

  3. Make the desired changes and click Save.

Procedure: How to Configure Encrypted Communication with a WebFOCUS Server

This procedure assumes that you have already successfully installed and configured the WFServlet implementation.

  1. If you are using Sun JVM with an encryption cipher key that is over 128 bits, be sure to install the Java Cryptography Extension (JCE). You can obtain the JCE from the Oracle download website.

    Note: The JCE must be installed in the JVM directory that your application is using. For more information, see the JCE documentation.

  2. Redeploy the webfocus.war file if it is necessary to point to the .war file. Otherwise, point to the web application directory.
  3. In the Administration Console, expand the Reporting Servers folder, then expand the Server Connections folder.
  4. Select the Server node (for example, EDASERVE) you want to configure for encryption.

    The Client Configuration pane appears.

  5. Click the Advanced arrow to open the Advanced section.
  6. Click the encryption cipher you want to use from the Encryption list.

    Note: When using any of the AES encryption ciphers, the client randomly generates a new RSA key pair (public and private keys of the specified length) and sends the public key to the server. Upon receipt of the public key, the server generates a random secret key. The length of the secret key depends on the chosen cipher strength. The secret key is encrypted with the public RSA key and sent back to the client, which decrypts it with its private RSA key. After the exchange, the client and the server both share the same secret key, and use it to encrypt and decrypt all communication between them.

  7. Click Save.

Procedure: How to Set a Default WebFOCUS Server Node

Selecting a default Server node in the Configuration tab sets the node as the IBI_REPORT_SERVER value in the webfocus.cfg file. However, if a site profile, universal profile, or request URL specifies a different default Server node, that value will override this selection. Profiles and request URLs use the IBIC_server setting for that purpose.

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder, and then expand the Server Connections folder.
  2. Right-click a Server node, and then click Set as Default.

    A green check mark appears on the server icon indicating the default node.

Procedure: How to Test a WebFOCUS Server Connection

  1. In the Administration Console, on the Configuration tab, expand Reporting Servers, and then expand Server Connections.
  2. Right-click the connection you want to test, and point to Test.
    • Select TABLE Request to test a table query on the server.
    • Select GRAPH Request to test a graph query on the server.
    • Select Stored Procedure to test a stored procedure on the server.
  3. On the test page, click Run.
  4. If the Valid credentials are required for reporting server page opens, enter your User ID and Password, and then click Sign in.
  5. Review the test results.

    If you receive a Server Error message, the server connection failed.

    If a page opens, displaying the results of your test, the server connection was successful.

  6. When your review of the results is complete, close the results page, and on the test page, click Cancel.

Reconnecting the Client to the Repository

Whenever a network, operating system, relational database system, or Application Server disruption temporarily disconnects the Client from the Repository, the Client automatically reconnects to the Repository as soon as the disruption is resolved. There is no need to stop and restart the Application Server to re-establish the connection between the Client and the Repository.

If you are able to remain signed in to a session during the disruption, you will automatically reconnect to the Repository as soon as the connection is restored. If the disruption forces you to sign out, you will automatically reconnect to the Repository when you sign in again. After the connection is restored, you can resume your work from the point at which you were interrupted.

Records of the events that disrupt and restore the connection between the Client and the Repository are captured in the System log.

Alternate Server Mapping

You can configure Alternate Server nodes for use with the Managed Reporting Deferred Receipt feature.

Deferred Receipt requests can be processed by using the immediate Server (immediate server) or by using an alternate deferred receipt server (Deferred Server) dedicated to running only deferred requests. The resources for the Deferred Server are managed independently from the immediate server. The Deferred Server must have the same access to applications, data sources, and Master Files, and run in the same environment (for example, UNIX), as the immediate server.

Note: If you use the Server for z/OS, additional configuration is required to use deferred requests. You must set up an alternate server or service to handle deferred requests and then configure the WebFOCUS Client to send requests to that server by setting up a deferred server mapping. For more information, see the Installation and Configuration for Windows manual for your platform.

Procedure: How to Add an Alternate Server Mapping

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder.
  2. Right-click the Alternate Server Mapping folder and click New.

    The Alternate Server Mapping pane opens.

  3. Click the main server in the Server list.
  4. Click the alternate server from the Alternate Server list.
  5. Click Save.
  6. When you receive the Successfully Saved message, click OK.

Procedure: How to Modify an Alternate Server Mapping

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder, and then expand the Alternate Server Mapping folder.
  2. Click the node of the server mapping you would like to modify.

    The connection properties appear in the Client Configuration pane.

  3. Make the desired changes and click Save.

    Note: Changes to the main server value automatically clear the value assigned to the alternate server. Therefore, if you change the value in the main server setting, you must also select an alternate server.

  4. When you receive the Successfully Saved message, click OK.

Procedure: How to Map a Deferred Server Node to an Immediate Server Node

Using the Administration Console, add a node for the deferred server the same way as adding a non-deferred node. Next, perform the following steps to map the Deferred Server to an immediate Server node:

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder and right-click Alternate Server Mapping.
  2. Click New to create a new mapping.

    The Alternate Server Mapping page opens, allowing you to edit the altdnode.wfs file.

  3. Click the name of the immediate server in the Server list, which displays the list of all available Servers.
  4. Click the name of the deferred server in the Alternate Server list, which displays the list of all available Servers (excluding the immediate server you just specified).
  5. Click Save.

Note: You can map multiple immediate servers to the same deferred server by repeating these steps.

Managing Clustered Servers

Clustering allows you to automatically send requests to the best available server for processing.

The Cluster Manager (CLM) enables you to define clusters of Servers that can be brought up and down as needed. In addition, the Cluster Manager enables you to configure cluster properties, including response time and dispatch method. It then monitors cluster performance and provides statistics, such as the average response time for requests, the number of connection failures and errors, and how many requests were sent per minute.

For more information, see Server Node Properties.

Procedure: How to Add a Cluster Manager Node

This procedure details the steps you take to create a cluster of servers in a node using the Cluster Manager.

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder.
  2. Right-click the Cluster Manager folder and click New.

    The Cluster Manager Configuration pane opens.

  3. In the Cluster Manager Configuration pane, type the Node Name, Remote CLM host, and Remote CLM port. You can optionally specify a Node Description.

    The default Remote CLM Port is 8120.

    Note: The Node Name provided in the Administration Console for Cluster Manager configurations must match the Cluster name of the Cluster Manager Server.

  4. Select the type of security to use when connecting to this Cluster Manager:
    • If you select Prompt for Credentials, HTTP Basic, Kerberos, or SAP Ticket, click the appropriate option and proceed to step 7.
    • If you select Service Account, proceed to step 5.
    • If you select Trusted, proceed to step 6.

    Note:

    • If you are using HTTP Basic authentication, you can verify the authorization header by selecting HTTP Request Info in the Diagnostics tab.
    • If you are using Kerberos authentication, see Configuring Kerberos for Single Sign On for additional setup requirements.
  5. If you selected Service Account, enter a user ID and password. Proceed to step 7.
  6. If you selected Trusted, by default, the client passes the user ID and group information to the Server using the IBIMR_user and IBIMR_group script variables. You can customize this behavior by using the different variable names, using HTTP headers instead of script variables, or not passing group information.
    1. If you would like to enable the default behavior, select Pass WebFOCUS User ID and their Groups and proceed to step 7.
    2. If you would like to use a TIBCO WebFOCUS script variable or HTTP header to pass user or group information, select Advanced.
    3. User ID is pre-selected because you will always send user information. Select TIBCO WebFOCUS script variable or HTTP Header field, depending on how you will pass user IDs. Accept the default script variable, IBIMR_User, or type an alternative script variable or HTTP Header field.
    4. If you would like to pass group information to the Server, select User's Groups, then select TIBCO WebFOCUS script variable or HTTP Header field, depending on how you will pass group information. Accept the default script variable, IBIMR_memberof, or type an alternative script variable or HTTP Header field.

    Note: You must configure the security provider on the Server to accept trusted connections.

    For more information on using TIBCO WebFOCUS script variables and HTTP headers, see Manipulating WebFOCUSDB2 Web Query Variables. For more information on configuring trusted connections on the Server, see Configuring Trusted Connections.

  7. If you are using the default service name, use of SSL, compression, encryption, connection limit and wait time, and are not using cookies or headers, proceed to step 8. If you would like to customize these properties, expand the Advanced arrow and configure the desired fields.
  8. Click Save.

Procedure: How to Modify a Cluster Manager Node

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder, and then expand the Cluster Manager folder.
  2. Right-click the node you want to edit and click Edit.

    The node properties appear in the Cluster Manager Configuration pane.

  3. Make the desired changes and click Save.

Managing Legacy Cluster Configurations

Previous implementations of Server clustering are still supported through the Legacy Cluster Configuration screen.

Procedure: How to Configure a Legacy Cluster

  1. In the Administration Console, on the Configuration tab, expand the Reporting Servers folder.
  2. Right-click the Legacy Cluster Configuration folder and select New.

    The Legacy Cluster Configuration pane opens.

  3. Type a Node Name and, optionally, a Node Description.
  4. Select the servers to include in the cluster as follows:
    • Click a single server in the Available list box, and click the right arrow.
    • Hold down the Ctrl key, click multiple non-adjacent servers, and click the right arrow.
    • Hold down the Shift key and click on the first and last adjacent server to include all of them, and click the right arrow.
  5. Click Save.

Using Client Profiles

In this section:

Client variables are not passed to the Server, so they cannot be included directly in any of the Server profiles (edasprof.prf, user profiles, and group profiles). However, you can make use of Client variables by specifying procedures in the site profile or universal profile. The site profile and the universal profile run after the Server profile processing, but before the report request. The site profile executes from the Client and the universal profile executes code from both the Client and the ReportCaster Distribution Server.

The site profile and the universal profile can also be added directly to webfocus.cfg or site.wfs.

The Client Site Profile

How to:

A site profile is sent to the Server by the Client and is executed on the Server immediately after all Server profiles. It can override settings in the Server profiles and can take advantage of the variable values set by the other profiles. This makes the amper variables exported by the Client with the (pass) syntax available for use on the Server.

For more information on using amper variables, see Manipulating WebFOCUSDB2 Web Query Variables. For more information on Server profiles, see WebFOCUS Reporting Server Profiles.

Customers can use a site profile to:

  • Make a series of data source connections dependent on a variable sent from the Client.
  • Use a Client variable (for example, &REMOTE_ADDR or &IBIMR_user) in a custom security procedure on the Server, which can set other amper variables that affect subsequent report processing. This is an example of application-based security.

Note: The site profile is only processed when procedures are run by the Client. Use the universal profile to include commands to be processed when procedures are run by the ReportCaster Distribution Server.

The following diagram illustrates site profile processing. The numbers associated with the files refer to the order in which the files are processed.

diagram illustrates profile processing
Procedure: How to Create a Site Profile
  1. In the Administration Console, on the Configuration tab, under the Application Settings folder, click Client Settings.
  2. Type the name of the desired procedure in the Site Profile (IBI_SITE_PROFILE) field.

    The Site Profile (IBI_SITE_PROFILE) field uses the following syntax: 

    _site_profile=command

    where:

    command

    Is any valid Server syntax.

Once you have completed these steps, the profile procedure or procedures run automatically. There is no need to restart the Server.

The Universal Profile

How to:

A universal profile is sent to the Server by both the Client and the ReportCaster Distribution Server and is executed on the Server. It runs immediately following all Server profiles.

Unlike the site profile, the universal profile is included during the execution of procedures by ReportCaster. Therefore, it should not include any logic or constructs that will execute only on the Client. For example, HTTP header variables should not be included, because they are available to the Client but not to the ReportCaster Distribution Server.

Procedure: How to Create a Universal Profile
  1. In the Administration Console, on the Configuration tab, under the Application Settings folder, click Client Settings.
  2. On the Client Settings page, type the desired procedure in the Universal Profile (IBI_UNIVERSAL_PROFILE) field.

    The Universal Profile (IBI_UNIVERSAL_PROFILE) parameter uses the following syntax: 

    IBI_UNIVERSAL_PROFILE=command

    where:

    command

    Is any valid Server syntax. The universal profile is executed by both the Client and the ReportCaster Distribution Server. This differs from the Site Profile, which is only executed by a Client request.

    Once you have completed these steps, the profile procedure (or procedures) run automatically. There is no need to restart the Server.

Managing Distribution Directories

In this section:

How to:

The Distribution Directories folder contains a configuration of distribution directory nodes that supports scheduled report distributions from ReportCaster. Distribution directory nodes specify those folders within the IBFS FILE subsystem that capture output from scheduled report distributions, and can be mapped to existing file system directories that are accessible to the ReportCaster Distribution Server, as shown in the following image.

The Network Location Page for a new distribution directory node showing the Name, Type, and Path fields.

When using the Repository method, the ReportCaster Distribution Server delivers scheduled report output to these IBFS FILE subsystem folders and their associated network locations or FTP server locations. The output is then available for use by other tools or applications that can retrieve it from the designated network or FTP server location.

Because they are folders within the IBFS FILE subsystem, distribution directory nodes are subject to the same security configuration as any other IBFS resource. Administrators can therefore use distribution directory nodes to limit the availability of the IBFS files that support scheduled report distributions to a selected set of authorized groups and users.

The Network Location page opens when you open a new or existing distribution directory node. This page contains the following fields:

Name

The Name field identifies the name of a distribution directory node within the IBFS FILE subsystem. The value you assign to this field must be unique. You receive an error if you attempt to create more than one distribution directory node with the same name.

The value you assign to the Name field appears on the folder that represents the distribution directory node in the Resources tree. When the Resources tree on the Legacy home page is displayed in Full View mode, folders for distribution directory nodes appear under the FILE subsystem folder, as shown in the following image.

The Resources Tree in Full View mode showing a list of distribution directory folders under the File folder of the WebFOCUS node.

The value you assign to the Name field also appears on folders that represent distribution directory nodes in the Browse for Folder dialog box that opens from the Distribution dialog box of the ReportCaster Basic Scheduling Tool and Advanced Scheduling Tool, as shown in the following image. Administrators and authorized users can see these folders when they configure a Report Distribution schedule that uses the Repository method.

The Browse for Folder dialog box showing a list of distribution directory folders under the File System folder.
Type

The Type field allows administrators to select the type of distribution method and external connection to be supported by a new distribution directory. There are two options:

Path. When this option is selected, the new IBFS distribution directory node will be connected to a directory that is accessible to the Distribution Server. The Path field remains on display in the Network Location page and contains the path to that directory.

FTP Server. When this option is selected, the new IBFS distribution directory node will be connected to an FTP server identified by a predefined FTP setting configuration maintained in ReportCaster. The Path field is replaced by the Server field with its list of predefined FTP Setting configurations.

Distribution directory nodes can only support a single connection type. Therefore, this field is visible only when creating new distribution directory nodes. It is not visible in distribution directory nodes that have already been created.

In addition, because the option to assign a distribution directory node to an FTP server is possible only when predefined FTP Connection setting configurations are available, this field, and the two options it contains, appears only when at least one predefined FTP Setting configuration, in addition to the (Default Setting) configuration, is available in ReportCaster. For more information about FTP Setting configurations, see the ReportCaster technical content.

Path

The Path field identifies the path to the network location that corresponds to a distribution directory node in the IBFS system, as shown in the following image. Because this location is the file system target of the scheduled report output, the Distribution Server must be able to write files to the location defined by this path. Within this limitation, the path can identify any location that supports your requirements.

The Network Location page showing a distribution directory node configuration mapped to a Path.

The format of a path assigned to this value must conform to the requirements of the operating system used by the Distribution Server or to the requirements of the Universal Naming Convention (UNC). For example, you could use one of the following paths to identify a file system directory named ReportOutput\Report01, that is located on a server named Server01, which, in a Microsoft Windows-based network, is mapped to the drive letter W:\.

  • For Windows: W:\ReportOutput\Report01
  • For UNIX or Linux: /ReportOutput/Report01
  • For the Universal Naming Convention: \\Server01\ReportOutput\Report01

If a path uses a format that is accessible to the Application Server as well, full details of the results of the file distribution are available for review from the Application Server.

If a path points to a directory on a machine that does not host the Application and Distribution Servers, both the Application Server, typically Tomcat, and the Distribution Server must be running under a user ID that has permission to access the directory. The Application Server must at least have Read permission to the targeted directory. The Distribution Server must have Read/Write permission to the targeted directory. The configuration of these permissions takes place within the external network, and is beyond the scope of this document.

Note that you must define the path to the file system location before you can create a distribution directory node for it. If the path in a distribution directory node does not point to an existing network location, the distribution directory is invalid and cannot support a scheduled report distribution.

FTP Server

The FTP Server field identifies the predefined FTP Setting configuration to which a distribution directory node is mapped in the IBFS system, as shown in the following image.

The Network Location page showing a distribution directory node configuration mapped to an FTP Server.

The list of servers in this field is limited to the set of predefined FTP server configurations available in the ReportCaster Console Configuration tab. The list excludes the default FTP Server configuration defined within ReportCaster because it is not a true IBFS node. It also excludes any user-defined FTP configurations attached to FTP Distribution schedules. In order to include the configurations defined in either of these locations, administrators must create a duplicate pre-defined FTP Setting configuration within ReportCaster.

The details of an FTP Server configuration identify the name of the FTP server to which the connection is made, the authorized User ID and Password for that FTP server, and the security protocol it uses. For more information about the FTP Settings configuration, see the ReportCaster technical content.

When creating a new distribution directory node, this setting appears only after you click the Server option in the Type setting.

When working with an existing distribution directory node, this setting appears only if the distribution directory node was configured to support an FTP Server connection when it was created.

Granting Access to Distribution Directory Nodes

Just as the ability to distribute scheduled report output using the Repository method is typically limited to administrators, and to those users in the Developers and Advanced Users groups who are authorized to create, edit, and distribute content within their assigned workspaces, the ability to access distribution directory nodes that support scheduled report distributions to the FILE subsystem should be limited to administrators, and to the users who are authorized to distribute the scheduled report output they contain. Using the tools of the workspace-based security model, administrators can ensure that distribution directories are available only to these authorized users.

In order to make distribution directories fully accessible to authorized users, administrators must do the following:

  1. Ensure that the ability to access resources in the IBFS FILE subsystem folder is available to users in authorized groups.
  2. Make the ability to distribute scheduled report output to the File System available to users in authorized groups.
  3. Make individual distribution directory nodes available to the groups that must use them to contain report output created from scheduled report distributions.

These requirements call for the assignment of the existing List Role to the FILE folder in the IBFS system, and the creation of two new roles: a role that grants access to the file system distribution method, referred to as the Distribution to File System role, and a second role that grants access to the privileges required to create or overwrite scheduled report content in a distribution directory, referred to as the Distribution Directory Access role.

A rule that makes the List role available to all users in the EVERYONE group is assigned to the FILE folder, by default. This rule must be assigned to the FILE folder in order to make Distribution Directory nodes, which exist within the IBFS FILE subsystem available to authorized groups and users.

The Distribution to File System role is designed to grant users the Distribute to File System (opDistributeFileSystem) privilege when working with a workspace. This role can include additional privileges, if required, or administrators can add this privilege to an existing role that contains other privileges. However, by creating a dedicated role limited to file system distribution access, administrators can achieve the most effective control over this role and its use.

The Distribution Directory Access role is designed to grant users the additional access needed to work with individual distribution directory nodes. It consists of the Access Resource (opList) privilege that enables users to see the distribution directory node and its contents, the Create Items (opCreateItem) privilege that enables users who own reporting schedules to create files containing scheduled report output in the distribution directory node, and the Edit Items (opWrite) privilege that enables users who own reporting schedules to overwrite files containing scheduled report output in the distribution directory if the previous version of that file did not use a unique filename that includes a timestamp. The Create Items and Edit Items privileges are required because the Distribution Server that produces the scheduled report output signs into WebFOCUS with the ID of the user that owns the reporting schedule in order to transfer scheduled report output to the distribution directory node.

As with the File System Distribution role, this role can include additional privileges, if required, or administrators can add these privileges to an existing role that contains other privileges. However, by creating a dedicated role limited to the ability to create and view content in a distribution directory node, administrators can achieve the most effective control over this role and its use.

Administrators must also create distribution directory nodes for those workspaces that generate scheduled report output. If all members are permitted to see or generate scheduled report output from a workspace, a single distribution directory node can accommodate all output from that workspace. However, if access to sensitive or confidential report output from a workspace must be restricted to a smaller group, additional distribution directories that are limited to these smaller groups may be required.

In order to complete the configuration required to make distribution directories available to authorized users, administrators must create rules for the workspaces and distribution directories that support scheduled report output distribution to the IBFS File subsystem. They must create a Distribution to File System rule for each workspace that generates scheduled report output for delivery to the File System in order to allow group members in that workspace to access the File System folder and workspace directory subfolders when they create a schedule. They must also create a Distribution Directory Access rule for each distribution directory node that contains scheduled report output in order to allow group members from the workspace that generated the scheduled report output to access that distribution directory and create scheduled report output in it.

We recommend that administrators configure distribution directory notes in the following task sequence:

  1. Identify the workspaces and groups that require access to distribution directories for scheduled report output.
  2. Ensure that all users who need to run scheduled reports are included in the groups that must have access to the scheduled report output.
  3. Create a Distribution to the File System role.
  4. Create a Distribution Access role.
  5. Create the distribution directory nodes required to contain the scheduled report output generated by each workspace.
  6. Create a Distribution to File System rule for each group that generates scheduled report output for distribution to the file system.
  7. Create a Distribution Directory Access rule for each group assigned to a distribution directory node that contains scheduled report output from their workspace.

Tasks one and two are not included in the topics that follow. They require an assessment that can only be made by each administrator based on the requirements of their organization. The remaining tasks are described in detail in the topics that follow.

Procedure: How to Create a Distribution to the File System Role

This role is designed to grant the privilege to distribute scheduled report output from a workspace to the IBFS File subsystem. We recommend that this role be limited to a single privilege and be identified by that privilege as described in this procedure. However, this role can include additional privileges if required, or the Distribute to File System (opDistributeFileSystem) privilege can be assigned to an existing role.

  1. Sign in as an administrator, and open the Security Center.
  2. In the Security Center, click the Roles tab.
  3. Click New Role to open the New Role dialog box.
  4. In the Name field, type a name for this new role. For example, Distribution to the File System.
  5. Under the Scheduling and Distribution privilege category folder, select the Distribute to File System check box.
  6. Click OK to save the new role.

    The Distribution to the File System role appears in the Roles list.

Procedure: How to Create a Distribution Directory Access Role

This role is designed to grant the privilege to access distribution directory nodes and create and overwrite scheduled report output in them. We recommend that this role be limited to the Access Resource, Create Item, and Edit Item privileges and be identified as a distribution directory access role as described in this procedure. However, this role can include additional privileges if required, or these privileges can be assigned to an existing role.

  1. Sign in as an administrator, and open the Security Center.
  2. In the Security Center, click the Roles tab.
  3. Click New Role to open the New Role dialog box.
  4. In the Name field, type a name for this new role. For example, Distribution Directory Access.
  5. Under the Basic Reporting privilege category folder, select the Access Resource check box.
  6. Under the Application Development privilege category folder, select the Create Items check box and select the Edit Items check box.
  7. Click OK to save the new role.

    The Distribution Directory Access role appears in the Roles list.

Procedure: How to Create a Distribution to File System Rule for a Workspace

A Distribution to File System rule grants access to the IBFS File subsystem to those groups assigned to a workspace that uses ReportCaster to distribute scheduled report output. Before you begin, make sure that all users who need access to the File subsystem are assigned to those groups to which this rule is assigned.

  1. Sign in as an administrator, and open the Workspaces view.
  2. In the Resources tree, under the Workspaces node or in the content area, right-click the workspace that requires the use of the File System distribution method for scheduled report content, point to Security, and then click Rules to open the Security Rules dialog box.
  3. On the Users and Groups tab, click the name of the Group that must have access to the File System Distribution Method.
  4. In the Rules for Group list, click the name of the role you created for distribution directory access. For example, Distribution to File System.
  5. In the Access column of the Distribution to File System role entry, click Permitted, and in the Apply To column, accept the default value, Folder and Children.
  6. Click Apply and then click OK to save the new rule.
  7. Repeat steps 3 through 6 to create the Distribution to File System rule for any additional workspaces or groups.

Procedure: How to Test the Assignment of a Distribution to File System Rule to a Workspace

  1. Sign in with the user ID and password of a member of a group to which the Distribution to File System rule was assigned, and open the Workspaces view.
  2. Right-click a report in the workspace, point to Schedule, and then click Repository to open the ReportCaster Distribution Scheduler wizard.
  3. Click Folder Location to open the Browse for Folder dialog box.
  4. If the File System folder appears at the top of the Choose the folder tree, click OK and close the ReportCaster Distribution Scheduler wizard.
  5. If the File System folder does not appear, click Cancel, close the ReportCaster Distribution Scheduler wizard, and perform the following steps.
    1. Right-click the workspace, point to Security, and click Rules on this Resource in order to determine if the Distribution to File System rule is assigned to the group under which you signed in, and if it was not, assign the rule to the group.
    2. Ensure that the List role is assigned to the FILE subsystem folder for the EVERYONE group.

Procedure: How to Create a Distribution Directory Node

When creating a node for a distribution directory, you must type a path to an existing network location. You cannot create a new network path merely by typing it in this field and saving the distribution directory node. If the path does not point to an existing network location, the distribution directory node is invalid and cannot support a scheduled report distribution.

  1. On the Administration Console Configuration tab, right-click the Distribution Directories folder, and then click New to open the Network Location page.
  2. In the Name field, type the name that identifies the new distribution directory node.
  3. To create a distribution directory node that connects to a network location, perform the following steps:
    1. Click Path in the Type field.
    2. In the Path field, type the path to the existing network location that corresponds to the distribution directory node in the IBFS system using one of the following formats.

      For Windows:

      drive:\path

      For UNIX or Linux:

      /path

      For the Universal Naming Convention:

      \\server\path

      where:

      drive
      Is the letter that represents the drive to which the server is mapped.
      server

      Is the name of the server that hosts the directory to which scheduled reports for the node identified in the Name field are to be directed.

      path

      Is the name of the network path to the directory to which scheduled reports for the node identified in the Name field are to be directed.

      For example:

      • For Windows: W:\ReportOutput\Report01
      • For UNIX or Linux: /ReportOutput/Report01
      • If using the Universal Naming Convention: \\Server01\ReportOutput\Report01
    3. Continue with step 5.
  4. To create a distribution directory node that connects to an FTP Server, perform the following steps:
    1. Click Server in the Type field.
    2. Click the name of the predefined FTP Setting configuration that corresponds to the distribution directory node in the IBFS system.
    3. Continue with step 5.
  5. Click Save As.
  6. If you receive a message warning you to enter all required information, click OK, and type and save the required information as described in steps 2 through 4.
  7. If you receive a message stating that the node was successfully saved, click OK.

    The Network Location page closes, and a node for the new distribution directory appears under the Distribution Directories folder.

Procedure: How to Create a Distribution Directory Access Rule for a Distribution Directory Node

  1. Sign in as an administrator, and open the Administration Console.
  2. On the Configuration tab, expand the Distribution Directories folder.
  3. Right-click the distribution directory node you wish to update, point to Security, and then click Rules to open the Security Rules dialog box.
  4. On the Users and Groups tab, in the Groups list, click the name of the group that must have access to the distribution directory node.
  5. In the Rules for Group list, click the name of the role you created to make distribution directory nodes accessible. For example, Distribution Directory Access.
  6. In the Access column of the Distribution Directory Access role entry, click Permitted, and in the Apply To column, accept the default value, Folder and Children.
  7. Click Apply and then click OK to save the new rule.
  8. Repeat steps 3 through 7 to create the Distribution Directory Access rule for any additional distribution directory nodes or groups.

Procedure: How to Test the Assignment of a Distribution Directory Access Rule to a Workspace

  1. Sign in with the user ID and password of a member of the group to which the Distribution Directory Access role was assigned.
  2. Right-click a report in the workspace, point to Schedule, and then click Repository to open the ReportCaster Distribution Scheduler wizard.
  3. Click Folder Location to open the Browse for Folder dialog box.
  4. Expand the File System folder that appears at the top of the Choose the folder tree.
  5. If a folder with the name of the distribution directory node appears under the File System folder, click OK and close the ReportCaster Distribution Scheduler wizard.
  6. If the folder for the distribution directory node does not appear, click Cancel, close the ReportCaster Distribution Scheduler wizard, and perform the following steps:
    1. Right-click the distribution directory node, point to Security, and click Rules on this Resource in order to determine if the Distribution Directory Access rule is assigned to the group under which you signed in, and if it was not, assign the rule to the group.
    2. Ensure that the List role is assigned to the FILE subsystem folder for the EVERYONE group.

Procedure: How to Edit a Distribution Directory Node

You can use the Edit command to change the values in an existing distribution directory node, or to create a new node modeled on an existing node.

If you save an existing distribution directory node without changing the name, you overwrite the existing node with the revised version. However, if you save an existing distribution directory node with a new name, you automatically create a new node, and leave the existing node with the old name intact. You do not overwrite the existing node.

If you need to replace an existing node with a new node, you must delete the existing node after creating the new node. For more information, see How to Delete a Distribution Directory Node.

Note: The Type field is available only when you create a new distribution directory node. Therefore, you cannot change the type assigned to an existing Distribution Directory node.

  1. On the Administration Console Configuration tab, expand the File System Distribution Directories folder, right-click your selected distribution directory, and then click Edit.
  2. If you must rename the distribution directory node, type a new name for the distribution directory node in the Name field.
  3. If this distribution directory node must connect to a new network location, in the Path field, type the new path for the distribution directory to an existing network location, using one of the following formats.

    For Windows:

    drive:\path

    For UNIX or Linux:

    /path

    For the Universal Naming Convention:

    \\server\path

    where:

    drive
    Is the letter that represents the drive to which the server is mapped.
    server

    Is the name of the server that hosts the directory to which scheduled reports for the node identified in the Name field are to be directed.

    path

    Is the name of the network path to the directory to which scheduled reports for the node identified in the Name field are to be directed.

    For example:

    • For Windows: W:\ReportOutput\Report01
    • For UNIX or Linux: /ReportOutput/Report01
    • If using the Universal Naming Convention: \\Server01\ReportOutput\Report01
  4. If this distribution directory node must connect to a new FTP server, click the name of that FTP Server in the Server list.
  5. If you did not change the Name, click Save.

    or

    If you changed the Name, click Save As.

  6. If you receive a message warning you to enter all required information, click OK, type the required information, and save the profile as described in steps 2 and 3.
  7. If you receive a message stating that the node was successfully saved, click OK.

    The Network Location page closes.

    If you did not change the name, the updated node appears under the Distribution Directories folder.

    If you changed the name, the new and the existing node appear under the Distribution Directories folder. You must assign the Distribution to File System and the Distribution Directory Access rule to the new distribution directory node to make it available to the groups that will use it for scheduled report distributions.

    If you need to delete the existing node, see How to Delete a Distribution Directory Node.

Procedure: How to Delete a Distribution Directory Node

  1. On the Administration Console Configuration tab, expand the Distribution Directories folder, and then right-click the distribution directory node you want to delete.
  2. Click Delete.
  3. When you receive a message asking if you are sure you want to delete the node, click Yes.

    The deleted node no longer appears under the Distribution Directories folder.

Understanding Application Settings

Application Settings determine the configuration and behavior of the WebFOCUS web application.

For more information about configuration files, see TIBCO WebFOCUS Client Configuration Files. For more information about individual Application Settings, see Application Settings.

Procedure: How to View or Edit Application Settings

  1. In the Administration Console, on the Configuration tab, expand the Application Settings folder and select the category of settings you would like to view or edit.

    The settings appear in the main configuration pane.

  2. Make the desired changes and click Save.

Managing Automatic Sign Outs

Client sessions that remain idle risk exposing sensitive information and system resources to unauthorized use. In order to minimize the time that a client session remains idle, two settings, located on the BI Portals page of the Administration Console Configuration tab, limit the length of an idle session to 120 minutes, by default.

The Session Timeout (minutes) (IBI_SESSION_TIMEOUT) setting limits session idle time for users who signed in with a valid User ID. Similarly, the Public Session Timeout (minutes) (IBI_PUBLIC_SESSION_TIMEOUT) setting limits session idle time for public users who signed in with an Anonymous User ID.

As a best practice, we recommend that administrators replace the default values in both of these settings with shortest time that accommodates their security needs and supports typical resource usage for the two different user types.

To warn users that their idle sessions are about to expire, the Enable Auto Sign-out (IBI_AUTO_SIGNOFF) setting and the Idle Timeout message duration (minutes) (IBI_AUTO_SIGNOFF_MESSAGE_DURATION) setting also appear on the BI Portals page. When the Enable Auto Sign-out check box is selected, a message stating that the current session will expire due to inactivity opens after a session has been idle for the number of minutes specified by the relevant Session Timeout (minutes) setting.

The message remains open and visible for the number of minutes specified in the Idle Timeout message duration (minutes) setting, which is two minutes, by default. If the message opens from the Home Page or the Security Center, it includes a countdown of the remaining time before sign-out. If the message opens from a portal, the countdown does not appear.

To continue their session, users can click OK. This action closes the message box and restores the session. A new session timeout countdown starts as soon as the restored session goes idle.

If users do not click OK before the scheduled timeout, the message box closes, and the session comes to an end.

For users assigned to a zone that uses form-based authentication or another authentication method that requires them to present credentials before opening a new session, the window displaying the Home Page refreshes and displays the Sign in page automatically after the session ends.

For users assigned to a zone that uses a Single Sign On pre-authentication method, the window displaying the Home Page refreshes and displays the sign-out page specified in the Custom logout target URL setting opens instead.

Typically, this is the default sign-out page that does not link users to the sign-in page. However, this setting can also contain the URL of the sign-out page established by a pre-authentication provider, which ends the Single Sign On product session for that provider.

If the Security Center is open, the window displaying it will also refresh and display the Sign in page. Any other windows, such as the Administration Console, that were open at the time of the session timeout remain open and unchanged. However, you will receive an Unexpected Behavior error message the first time you attempt to use them after the timeout. When you click OK to clear this message, the window automatically refreshes and displays the Sign in page. As a best practice, we recommend that you close all but one window before signing in to WebFOCUS for a new session.

When users sign in again, or restart their session with authentication from their third-party authentication provider, the default page or portal defined in the Redirect /ibi_apps to setting opens, enabling them to return to tasks that may have been interrupted by the session timeout.

Understanding Custom Settings

How to:

The Custom Settings page allows you to customize your product installation by typing customized values for standard settings.

When you save updates to settings that you type into the Customized Setting text box, they are transferred to the site.wfs file, located at drive:\ibi\WebFOCUS82\client\wfc\etc. When you use this page to assign new values to settings, they override the default values assigned to them. These overrides are carried over as you upgrade to new versions.

After you save a custom setting, the text continues to display on this page. You can use comments to identify specific updates and additional information about them.

For an example of applying custom settings, see Managed Reporting Internal Variables.

Procedure: How to Configure Custom Settings

Only an administrator can configure settings on the Custom Settings page.

  1. In the Administration Console, on the Configuration tab, click Custom Settings.
  2. Under the final comment statement at the top of the Custom Settings text box, or the most recent custom setting entry, type the variables, settings, commands, or comments that comprise the custom settings.

    Use the format required by the application or operating system that will execute the command.

    To help track changes to custom settings, use comments to identify and separate individual changes.

  3. To store your custom settings in an encrypted format, select the Encrypt check box.

    Note: Even when you select this check box, settings continue to appear in an unencrypted format in the Custom Settings text box.

  4. When your configuration is complete, click Save.
  5. When you receive a confirmation message, click OK.
  6. When the Custom Setting page clears, click Custom Settings under the Application Settings folder to see your updated comments, settings, or commands in the Custom Settings text box.

Understanding NLS Settings

How to:

You can use the Administration Console to configure National Language Support and enable the Dynamic Language Switch.

Separate message files exist for every national language supported by the product. If you want to customize the set of characters used in your report output, you must select the code page for every language you use.

Procedure: How to Configure National Language Support

  1. In the Administration Console, on the Configuration tab, click NLS Settings to open the NLS Settings page.
  2. Click the option for the operating system on which the Client resides.

    The list adjusts to display the available code pages for the selected operating system.

  3. From the list, click a code page that configures the client for the correct display of report output in the browser.

    Note: The language selected for the Client usually corresponds to the language selected for the Server from the Server Console.

    If the language chosen from the Server Console does not appear in the drop-down list in the Administration Console, click User Defined Code Page and type the number of the user-defined code page.

    Use this option, for example, when the server adds support for a new code page that is not yet reflected in the client software.

    In the following sample configuration window, the administrator specified the User Defined Code Page 437.

    NLS Language Page Operating System selection options including user defined code page.

    Unicode (UTF-8) is available for the Windows, UNIX, or AS/400 operating systems.

    Note: Because of a Java encoding limitation for ISO8859-1, characters 0x80 through 0x9F are not supported with the Application Server configured for code page 137. As a result, French users wanting to display the following characters correctly should configure the Application Server to use Cp1252.

    • U+0152 Latin Capital Ligature OE
    • U+0153 Latin Small Ligature oe
  4. Click Save to store your NLS settings. The console generates and updates the client configuration file (nlscfg.err), found in drive:\ibi\WebFOCUS82\client\home\etc, with the CODE_PAGE setting. Note that if you click NLS Settings again, your new setting is highlighted as the active code page.

Reference: Client Code Page Settings

The following code page settings are available:

  • * 137 - U.S. English/Western European
  • 874 - Thai
  • * 942 - Japanese
  • * 946 - Simplified Chinese
  • 949 - Korean
  • 1250 - Eastern European
  • 1251 - Russian
  • * 1252 - Western European
  • 1253 - Greek
  • 1254 - Turkish
  • * 1255 - Hebrew
  • 1256 - Arabic
  • 1257 - Baltic
  • * 10942 - Japanese EUC
  • * 10948 - Traditional Chinese
  • * 65001 - Unicode (UTF-8)

Note: Only those code page settings marked with an asterisk are fully supported in the current release.

Customizing the Dynamic Language Switch

How to:

You can customize the languages that are made available on Sign in pages by activating the Dynamic Language Switch.

Procedure: How to Customize the Dynamic Language Switch

  1. In the Administration Console, on the Configuration tab, under the Application Settings folder, click Dynamic Language Switch.

    The Dynamic Language Switch page opens with a list of the languages made available by the code page selection in the National Language Support page. By default, the Enable Dynamic Language check box is cleared and all of the language check boxes are deactivated.

    The Dynamic Language Switch page also shows the Client Code Page setting specified in How to Configure National Language Support.

  2. Select the Enable Dynamic Language check box to activate the check boxes for all of the available languages displayed in the panel, as shown in the following image.
    The Enable Dynamic Language check box and table of Locales
  3. Select the check box next to each of the languages that you want to appear on the Sign in pages and in the Language menu.
  4. Select the check box next to the Locale heading if you want all of the languages to appear in the Select Languages drop-down list on the Sign in pages and in the Language menu.
  5. Click Save.
  6. When you receive a message stating that your change was saved successfully, click OK.

Note: To remove languages from the Select Languages list on the Sign in pages, clear the check boxes next to the languages you want to remove.

Understanding Redirection Settings

In this section:

How to:

Redirection settings specify the way in which the Client handles output files by file extension. You can review these settings though the Redirection Settings page of the Administration Console Configuration tab. Each entry in the page identifies an output file format by its TIBCO WebFOCUS Extension, Content Type, File Format, Server Extension, Client Extension, and IBFS File Format, as shown in the following image.

The Redirection Settings page displaying detailed entries for selected file extensions with varying values in the Redirect and Save Report fields.

Note: This image displays the lower half of the page to show file extensions with varying values in the Redirect and Save Report fields.

The mime.wfs file, located in the directory drive:\ibi\WebFOCUS82\client\wfc\etc, contains information about available format types. When you open the Redirection Settings page, you display redirection settings stored in the mime.wfs file, and when you save changes, you store them in the mime.wfs file.

Before making any changes to the redirection settings, you must assess the impact they will have on the applications and user experience within your organization. If you require further assistance, consult Customer Support Services.

Notes:

Redirecting and Saving File Output

On the Redirection Settings page, values in the Redirect and Save Report settings determine whether the output from a request is stored in a temp folder file during processing, and whether a name is to be assigned to that file automatically. The combination of values assigned to these two settings determines the way in which output from requests is to be displayed and saved.

The Redirect setting allows you to specify if the output from a request should be saved to a file in the temp folder located under the client directory.

  • If the value in the Redirect setting is yes, the output is saved to a file in the temp folder, where a name can be assigned to it, as directed by the value assigned to the Save Report setting.
  • If the value in the Redirect setting is len, the output is saved to a file in the temp folder only if it exceeds the value assigned to the IBIWF_sendbufsize setting, which, by default, is 16384 bytes. Any output that must be saved to a file in the temp folder is then sent to the browser without an additional HTTP call.
  • If the value in the Redirect setting is no, output is processed as directed by the value assigned to the Save Report setting.

    The Save Report setting allows you to specify if report files should be assigned names automatically when they are created.

    • If the value in the Save Report setting is no, the report, chart, or other output opens directly in the Browser or application without prompting users to open or save it. Users still have the option to save the report after it is opened. A randomly-generated name is assigned to the report output file regardless of whether the request originated from the Resources tree, or from InfoAssist, WebFOCUS® App Studio, or some other application tool.
    • If the value in the Save Report setting is yes, the report, chart, or other output is saved to a file in the temp folder, as follows:
      • If the report request specifies an output file name, it is assigned to the output file. Then the browser makes an HTTP call to retrieve the temporary stored output file, and prompts the user to open, save, or cancel it.
        • Reports, charts, or other content files that require a date and time can be created by including the following coding technique that uses amper variables to specify the filename and capture the date and time the report is created by the Server. For more information, see the example in the topic,Adding a Date and Time to the PCHOLD AS Filename.
      • If the report request does not specify a file name:
        • If you run the report from an item in the Resources tree, the name value of that item is assigned to the request output file, and the date and time that the file was created is automatically added to the file name.

          Note: The name value of an item appears on the Properties panel in the Name field.

          • However, if the Do Not Assign Timestamp to a Redirected Report Name setting check box is also selected, the automatic date and time assignment is not added to the file name.
        • If you run the report from a tool, such as TIBCO WebFOCUS Designer, InfoAssist, the Text Editor, or the App Studio Report Canvas, a randomly-generated name is assigned to the output file, and the date and time that the file was created is automatically added to the file name.
          • However, if the Do Not Assign Timestamp to a Redirected Report Name setting check box is also selected, the automatic date and time assignment is not added to the file name.

Specifying an Output File Name Within a Report Request

To specify an output file name within a report request, use the PCHOLD AS filename option.

Within a report request, the syntax for the PCHOLD option is:

ON TABLE PCHOLD [AS filename] [FORMAT fmt]

where:

AS filename

Specifies a name for the PCHOLD file.

FORMAT fmt

Specifies the format of the PCHOLD file. For example, XLSX.

Note: If the PCHOLD AS name specified in the report request contains eight or fewer characters, it is returned to the browser in uppercase. If it contains nine or more characters, it is returned to the browser in the case specified.

For information on creating reports with the PCHOLD command, see the Creating Reports with TIBCO WebFOCUS Language guide.

Adding a Date and Time to the PCHOLD AS Filename

Some applications, such as Microsoft Excel®, require a unique name for every file opened. In order to accommodate this requirement, when you assign a value of yes to the Save Report setting, you can add amper variables to the report request to obtain the date and time the report is created by the Server, specify a file name with the date and time appended, and assign that file name to the report file, as shown in the following example: 

-SET &TIME = STRIP(8,&TOD,'.',A8);
-SET &FNAME = OUTPUT_ | &YYMD | _ | &TIME;
TABLE FILE CAR
BY CAR
ON TABLE PCHOLD AS &FNAME FORMAT XLSX
END
XSLX

Procedure: How to Change Redirection Settings

Before making any changes to the Redirection Settings, you must assess the impact they will have on the applications and user experience within your organization. You may need to consult with the administrators of other large scale applications or network administrators within your organization that would be affected by your changes. If you require further assistance, consult Customer Support Services.

  1. In the Administration Console, on the Configuration tab, click Redirection Settings.
  2. In the Redirect list:
    1. Click yes to redirect the output to a temporary directory for files using the specified extension.
    2. Click no to allow the output to be processed as directed by the value assigned to the Save Report setting.
    3. Click len to redirect report content to a temporary directory only when it exceeds the buffer size defined in the IBIWF_sendbufsize setting.
  3. In the Save Report list:
    1. Click yes to prompt users in the browser to open or save the output for files using the specified extension.
    2. Click no to open output directly in the Browser or application without prompting users to open or save it.
  4. If you want to encrypt the redirection settings, select the Encrypt check box at the bottom of the screen.
  5. Click Save to save your changes in the Redirection Settings panel.

Saving GRAPH (PNG, SVG, GIF, JPEG, or JPG) Requests

In order to use the Save Report functionality for GRAPH requests that specify a PNG, SVG, GIF, JPEG, or JPG format in the procedure, you must take the following steps:

  1. Set Save Report to yes for the .htm extension.

    Running a server-side GRAPH request creates an HTM file that contains a link to the actual graph output, which is stored as a temporary image file with a .jpeg, .jpg, .gif, .svg, or .png extension.

  2. When you execute a GRAPH request, if you select the Save option when prompted to open or save the output, the output is saved to an HTM file using only a reference to the graph image, which will eventually expire and be deleted from the server, as determined by the temporary file expiration settings in the Client Configuration.
  3. To preserve the output of the GRAPH request, open the saved HTM file, right-click the graph image, and select Save Picture As to save it to disk permanently. You can then substitute an absolute reference to the saved image file in the HTM output file.

Understanding InfoAssist Properties

InfoAssist Properties allow you to set the system-wide defaults that apply to all InfoAssist users. To update these settings, select the Configuration tab, and then select InfoAssist Properties. For more information about specific InfoAssist Properties see InfoAssist Properties.

Understanding TIBCO WebFOCUS Designer Properties

WebFOCUS Designer Properties allow you to set the system-wide defaults that apply to all users of WebFOCUS Designer. To update these settings, select the Configuration tab, and then select Designer Properties. For more information about specific WebFOCUS Designer Properties, see TIBCO WebFOCUS Designer Properties.

Understanding the Role Update Utility

The Role Update Utility lists the differences between the privileges currently assigned to Repository Roles and their corresponding Package Roles. Repository Roles are defined in the repository, and are used by resource templates. Package Roles are maintained in a separate file, and define the standard set of privileges assigned to roles within a release.

When you upgrade to a new release, or change the privileges assigned to Repository Roles by updating them in the Security Center, this utility identifies all variances between the privileges assigned to the Repository Roles used by resource templates and the standard set of privileges defined by the Package Role.

For each Repository Role whose set of assigned privileges varies from its corresponding Package Role, the utility gives you the option to disregard the variance, add the missing privileges to the Repository Role, or replace the Repository Role entirely with the standard set of privileges defined in the Package Role. Replacing a Repository Role with a Package Role is the only way to remove any additional privileges that appear in a Repository Role but not in the corresponding Package Role. The utility also enables you to make these changes globally to all Repository Roles whose set of assigned privileges vary from the set of privileges assigned to the Package Roles.

After an upgrade or installation of a new release, the utility enables you to identify all variances between the existing Repository Roles and the new Package Roles and incorporate the new privileges into the Repository Roles or maintain them without updates.

If there are no upgrades or changes, a role entry displays the message, No privilege differences between package and repository. If this is the case with your display, you can disregard this feature until you upgrade or change a Repository Role.

For more information on how to update a role after a typical installation, see the WebFOCUS and ReportCaster Installation and Configuration technical content.