Configure Operational Decision Manager


  1. Create ODM cluster
    1. ODM cell
    2. Decision Server topology
    3. Profile templates
    4. Create/augment a default profile with Rule Execution Server
    5. Augment a dmgr profile with Rule Execution Server
    6. Run configureDSCluster to create a cluster
    7. Unaugment from existing profiles
    8. Uninstall from a cluster
    9. Configure the Decision Center consoles
      1. Configure
      2. Augment an existing profile
      3. Augment a dmgr profile
      4. Run configureDCCluster to create a cluster
      5. Unaugment Decision Center from a cluster
      6. Uninstall Decision Center from a cluster
    10. Configure event runtime
      1. Augment an existing WAS management profile
      2. Augment an existing WAS custom profile
      3. Create profiles for a cluster
      4. Configure a cluster
      5. Create a cluster that uses WebSphere MQ
    11. Define a highly available collection of catalog servers
  2. Configure Rule Execution Server on WAS
    1. Set up a data source and connection pool
      1. Create a data source and connection pool
      2. Create J2C authentication data
      3. Set custom properties
      4. Test the connection to the database
    2. Activate security on WAS
      1. Introduction to WAS security
      2. Create users and groups
      3. Map the resAdministrators group to the Monitor role
      4. Security policies for the Rule Execution Server console
    3. Deploy the Rule Execution Server Management EAR
  3. Create a Rule Execution Server database schema using Installation Settings wizard
    1. Installation Settings wizard
    2. Open the Rule Execution Server console
    3. Welcome to the Installation Settings wizard
    4. Choose the database schema
    5. Review the database schema
    6. The Installation Settings wizard report
  4. Create Rule Execution Server database schema using SQL scripts
  5. Deploy the MBean descriptors
  6. Integrate WebSphere MQ in WAS
  7. Configure Rule Execution Server in different environments
  8. Troubleshoot Rule Execution Server
  9. Verify the deployment and configuration
  10. Configure Decision Server Events on WAS
  11. Configure the Decision Center consoles on WAS
  12. Verify your configuration of Decision Center

  • Configure Rule Execution Server in shared mode
  • Configure Rule Execution Server in scoped mode

  • Configure Rule Designer in Eclipse


    Cluster ODM servers

    ODM provides scripts for creating...

    • Decision Server clusters
    • Decision Center clusters

    Topologies...

    ODM cell Enable all applications provided by ODM. Includes a Decision Center cluster and a Decision Server cluster.
    Decision Server cell Subset of ODM components supporting rules and event runtime execution.

    Environments......

    • Shared environment

      Single authoring server that deploys artifacts to multiple runtime servers. Supports branching and merging. Enables high availability for all ODM capabilities. Separates execution and simulation workloads. Lacks the ability to customize Decision Center for a single phase (development, test, or production). Introduces a single point of failure for authoring, which can be ameliorated using database replication.

    • Staged environment

      Each cell managed independently. Isolates authoring and execution by stage and cell. Allows customization of Decision Center in each cell. Supports high availability. Requires the provisioning and management of multiple JVMs and Decision Center databases. Requires synchronization of Decision Center rule and event projects using Export and Import commands.

    Configure cells using profile template or manually.


    ODM cell

    With the ODM cell topology, each node contains a Decision Server instance and a Decision Center instance. Each instance in the cell forms a separate cluster.

      Decision Center cluster Server-side components of Decision Center. Contains an EAR file for the web consoles, and an EAR file for the event widgets.
      Decision Server cluster Rules and event logic components. Handles test suites and simulations. Rule and event runtimes are co-located in the same JVM.

    The Rule Execution Server console is deployed as an EAR file on a separate server outside the Decision Server cluster.


    Decision server cluster topology

    Each node in cluster contains a Decision Server instance, providing...

    Co-locate the rule and event runtime engines in the same JVM for local invocations of decision services by event detection.

    The Rule Execution Server console is deployed as an EAR file in a separate server outside the Decision Server cluster.


    ODM profile templates

    • ODM_INSTALL/executionserver/applicationservers/WebSphere8

    • ODM_INSTALL/teamserver/applicationservers/WebSphere8

        Decision Center EAR file.

    • ODM_INSTALL/shared/profiles/profileTemplates/rules

      • Augment a dmgr with Decision Server profile.

          management/ds

      • Augment a dmgr with Decision Center profile

          management/dc

    • WAS_HOME/profileTemplates/rules

        To augment a dmgr profile...

        • management/ds
        • management/dc

    • WAS_HOME/profileTemplates/rules/default/ds

        Augment a node or a WAS profile with Decision Server.

    • WAS_HOME/profileTemplates/rules/default/dc

        Augment a node or a WAS profile with Decision Center.

    • ODM_INSTALL/runtime

        Event runtime EAR files:

        • wberuntimeear.ear
        • WBETesterEar.ear

    • ODM_INSTALL/runtime

        Event widgets EAR file: EventWidgetsEar.ear

    • WAS_HOME/profileTemplates/wbe/management

        Augment a dmgr profile with the event runtime.

    • WAS_HOME/profileTemplates/wbe/default

        Augment a node or a WAS profile with the event runtime.


    Create/augment a default profile with Rule Execution Server

    Before starting, create an empty database. Exception is Apache Derby, which does not require a database to be created beforehand.

    To create a default profile with Rule Execution Server, run...

    To augment an existing profile with Rule Execution Server, stop all application servers in the profile, then run...

      manageprofiles.sh -augment
                        -templatePath "ODM_HOME/WAS/profileTemplates/rules/default/ds"
                        -profileName ODMSrv01
      

    Parameters...

      -create Create a new profile.
      -augment Augment the existing profile.
      -unaugment Undo augmentation
      -templatePath /path/to/template WAS_HOME/profileTemplates/rules/default/ds
      -dsHome /path/to/decision_server Required if Decision Server is located in non-default location.
      -profileName profile_name Name of the profile.
      -cellName cell_name Name of the cell.
      -nodeName node_name Name of the node.
      -hostName host_name Computer hosting the profile.
      -serverName server_name Server name.
      -enableAdminSecurity true|false Default is false. If true, also provide -adminUserName and -adminPassword.
      -adminUserName username User ID to access WAS. Required if enableAdminSecurity is enabled.
      -adminPassword password Password to access WAS. Required if enableAdminSecurity is enabled.
      -dbType database_type

      • Derby_Embedded (default)
      • DB2_Universal
      • Derby_NetworkServer
      • Oracle
      • MS_SQL_Server

      -dbName database_name Required unless -dbType is Derby_Embedded.
      -dbUserId database_user_name Required unless -dbType is Derby_Embedded.
      -dbPassword password Password to access the database server. Required unless -dbType is Derby_Embedded.
      -dbJDBCClasspath /path/to/JDBC_class_files Required unless -dbType is Derby_Embedded.
      -dbJDBCLicenseClasspath /path/to/jdbc_license Required if -dbType is DB2_Universal.
      -dbHostName host_name Host name for the database server. Required unless -dbType is Derby_Embedded.
      -dbServerPort port_number Port of the TCP/IP service on which the database is listening. Required unless -dbType is Derby_Embedded.


    Augment a dmgr profile with Rule Execution Server

    1. Log on to dmgr host

    2. If dmgr does not exist, create a dmgr management profile.

    3. Install the profile templates for WAS.

    4. Create a default node.

      The node will become the first cluster member, and a server for the Rule Execution Server console.

      You can create a default node on another computer, use an existing node, or use the -createNode option to create the target node on the computer where the configuration is run.

    5. Augment dmgr profile...

      cd /opt/IBM/WebSphere/AppServer/profiles/dmgr/bin
      ./stopManager.sh -username wasid -password password
      cd /opt/IBM/Websphere/AppServer/bin/
      ./manageprofiles.sh -augment \
                          -profileName odmDmgr \
                          -templatePath ODM_HOME/profiles/profileTemplates/rules/management/ds
      

    The manageprofiles.sh command...

    1. Creates users resAdmin, resMonitor, and resDeployers.

    2. Copies configureDSCluster.sh to...

        WAS_HOME/profiles/Dmgr01/bin


    Run configureDSCluster to create a cluster

    Note that you cannot use the configuration script to initialize the cluster or add a node to an existing cluster.

    1. Edit

      ...and set cluster properties...

      wodm.dsrules.clusterName Can be existing cluster. If no cluster exists, a cluster is created. Default name is DecisionServerCluster.
      wodm.dsrules.rulesMgrServerName Server hosting Rule Execution Server console. For example: RulesMgrSrv.
      wodm.dsrules.db.type Database type: DB2, Oracle, or MSQL. The default is DB2.
      wodm.dsrules.db.jdbcDriverPath Path to the JDBC drivers. Separate the driver names with a colon (;). For example:

        /drivers/db2jcc.jar;/drivers/db2jcc_license_cu.jar;
      wodm.dsrules.db.name Name of the database. For example: MyDB.
      wodm.dsrules.db.hostname Name of the host where the database is hosted: For example: MyDB_server.
      wodm.dsrules.db.port Port number to establish the connection to the database.
      wodm.dsrules.db.user User name to connect to the database. For example: db_user1.
      wodm.dsrules.db.password Password for the user to connect to the database. For example: db_user1_pwd.

    2. Create cluster....

      WAS_HOME/profiles/Dmgr01/bin/
      ./configureDSCluster.sh -dmgrAdminUsername websphere \
                              -dmgrAdminPassword websphere\
                              -clusterPropertiesFile WAS_HOME/profiles/Dmgr01/bin/rules/configureDSCluster.properties \
                              -createNode \
                              -targetNodeName DecisionServerNode01 \
                              -dmgrHostName localhost \
                              -dmgrPort 8879

    Parameters...

    Parameter name Required Description
    -dmgrAdminUsername Mandatory WAS administrator's user identifier
    -dmgrAdminPassword Mandatory WAS administrator's password.
    -clusterPropertiesFile Mandatory Path to the properties file.
    -uninstall Optional Remove applications and resources from the cluster. Cluster itself is not removed because it might contain other applications.
    -createNode Optional Create a default node profile with the name set in the -targetNodeName parameter.
    -targetNodeName Optional Default is RulesNode01
    -dmgrHostName Optional Computer hosting deployment manager. Mandatory if we create the target node using -targetNodeName.
    -dmgrPort Optional SOAP TCP port of the deployment manager. By default, 8879.

    If you make a mistake, you can execute the script again.

    The script performs the following actions:

    • Installs JDBC provider, JCA connector, and data source at node level.
    • Installs Rule Execution Server console to the cluster.
    • Deploys hosted transparent decision services and SSP to the cluster member. Users are mapped to application groups when an application is deployed.
    • Starts deployment manager server.
    • Configures security.
    • Creates resAdmin, resDeployer, resMonitor users.
    • Configure users and groups.
    • Installs execution unit (XU).
    • Maps users and groups to roles.
    • Starts cluster, servers, and applications.


    Unaugment Rule Execution Server from existing profiles

    You can unaugment Decision Server from existing profiles without deleting the cluster.

    cd WAS_HOME/bin/
    ./manageprofiles.sh -unaugment \
                        -profileName Dmgr01 \
                        -templatePath WAS_HOME/profileTemplates/rules/management/ds \
                        -nodeName DecisionNode \
                        -cellName DecisionCell \
                        -targetNodeName DecisionServerNode01
    
    

    The command removes the resAdmin, resDeployer, and resMonitor users. The cluster is kept as is to prevent any risk of deleting previously existing configurations.


    Uninstall Rule Execution Server from a cluster

      cd WAS_HOME/profiles/Dmgr01/bin/
      ./configureDSCluster.sh -dmgrAdminUsername websphere \
                              -dmgrAdminPassword websphere \
                              -clusterPropertiesFile WAS_HOME/profiles/Dmgr01/bin/rules/configureDSCluster.properties \
                              -targetNodeName DecisionServerNode01 \
                              -dmgrHostName localhost \
                              -dmgrPort 8879 \
                              -uninstall 

    Parameters...

    Parameter name Mandatory/Optional Description
    -dmgrAdminUsername Mandatory WAS administrator
    -dmgrAdminPassword Mandatory WAS administrator
    -clusterPropertiesFile Mandatory Full path to the properties file.
    -uninstall Mandatory Remove applications and resources from the cluster. The cluster itself is not removed because it might contain other applications.
    -createNode Optional Create a default node profile with the name set in the -targetNodeName parameter.
    -targetNodeName Optional Default is set to RulesNode01
    -dmgrHostName Optional Computer hosting the dmgr. Mandatory if target node was created using -targetNodeName.
    -dmgrPort Optional The SOAP TCP port of the deployment manager. By default, 8879.

    Results:

    • Uninstalls hosted transparent decision services and Scenario Service Provider (SSP).
    • Uninstalls the Rule Execution Server console.
    • Removes the Rule Execution Server console server.
    • Uninstalls the execution unit (XU).
    • Uninstalls the data source.
    • Removes the administrative and applicative groups.


    Configure the Decision Center consoles

    You can create new profiles for the Decision Center consoles and configure a WAS cluster. To create a new stand-alone server to host Decision Center, first create a new profile. You can create a profile using the Profile Management Tool or the manageprofiles command.


    Configure Decision Center on a new profile

    manageprofiles.sh -create \
                      -templatePath "ODM_HOME/WAS/profileTemplates/rules/default/dc" \
                      -dcHome "ODM_HOME"

    Parameters:

    -create To create the new profile.
    -templatePath /path/to/template Location of the profile template. Provide the path to..

      WAS_HOME/profileTemplates/rules/default/dc

    -dsHome /path/to/decision_center Specify if you have installed Decision Center in a non-default location.
    -profileName profile_name Name of the profile.
    -cellName cell_name Name of the cell.
    -nodeName node_name Name of the node.
    -hostName host_name Computer hosting the profile.
    -serverName server_name Server name.
    -enableAdminSecurity true|false Default is false. If true, also provide -adminUserName and -adminPassword.
    -adminUserName username User ID to access WAS. Required if enableAdminSecurity is enabled.
    -adminPassword password Required if enableAdminSecurity is enabled.
    -dbType database_type

    • Derby_Embedded (default)
    • DB2_Universal
    • Derby_NetworkServer
    • Oracle
    • MS_SQL_Server

    -dbName database_name Required unless -dbType is Derby_Embedded.
    -dbUserId database_user_name User ID to access the database server. Required unless -dbType is Derby_Embedded.
    -dbPassword password Password to access the database server. Required unless -dbType is Derby_Embedded.
    -dbJDBCClasspath /path/to/JDBC_class_files Path to the JDBC class path files. Required unless -dbType is Derby_Embedded.
    -dbJDBCLicenseClasspath /path/to/jdbc_license Path to the JDBC class path files. Required if -dbType is DB2_Universal.
    -dbHostName host_name Host name for the database server. Required unless -dbType is Derby_Embedded.
    -dbServerPort port_number Port of the TCP/IP service on which the database is listening. Required unless -dbType is Derby_Embedded.

    After running manageprofiles.sh, the profile is created.


    Augment an existing profile with Decision Center

    Create a database before running the profile augmentation command below. Exception is Apache Derby, which does not require a database to be created beforehand.

    To augment an existing appserver profile, stop all application servers in the profile, then run...

    manageprofiles.sh -augment 
                      -templatePath "ODM_HOME/WAS/profileTemplates/rules/default/dc"
                      -profileName WODMSrv01

    Parameters:

    -augment Augment the existing profile.
    -unaugment Undo augmentation
    -templatePath /path/to/template WAS_HOME/profileTemplates/rules/default/dc
    -profileName profile_name Existing application server profile to augment.
    -dsHome /path/to/decision_center Specify if Decision Center is installed in non-default location.
    -profileName profile_name Name of the profile.
    -cellName cell_name Name of the cell.
    -nodeName node_name Name of the node.
    -hostName host_name Computer hosting the profile..
    -serverName server_name Server name.
    -enableAdminSecurity true|false Default is false. If true, also provide -adminUserName and -adminPassword.
    -adminUserName username User ID to access WAS. Required if enableAdminSecurity is enabled.
    -adminPassword password Password to access WAS. Required if enableAdminSecurity is enabled.
    -dbType database_type

    • Derby_Embedded (default)
    • DB2_Universal
    • Derby_NetworkServer
    • Oracle
    • MS_SQL_Server

    -dbName database_name Required unless -dbType is Derby_Embedded.
    -dbUserId database_user_name User ID to access the database server. Required unless -dbType is Derby_Embedded.
    -dbPassword password Password to access the database server. Required unless -dbType is Derby_Embedded.
    -dbJDBCClasspath /path/to/JDBC_class_files Path to the JDBC class path files. Required unless -dbType is Derby_Embedded.
    -dbJDBCLicenseClasspath /path/to/jdbc_license Path to the JDBC class path files. Required only if -dbType is DB2_Universal.
    -dbHostName host_name Host name for the database server. Required unless -dbType is Derby_Embedded.
    -dbServerPort port_number Port of the TCP/IP service on which the database is listening. Required unless -dbType is Derby_Embedded.


    Augment a dmgr profile with Decision Center

    1. Install Decision Center, which includes WAS and its profile templates.

    2. Create a default dmgr profile, unless one exists already.

    3. Create a node.

      The node must be started and visible to the deployment manager. You can create a default node on another computer, use an existing node, or use the -createNode option to create the target node on the computer where the configuration is run.

    4. Augment dmgr profile...

      cd WAS_HOME/bin/
      ./manageprofiles.sh -augment \
                          -profileName Dmgr01 \
                          -templatePath WAS_HOME/profileTemplates/rules/management/dc
      

    The manageprofiles.sh command...

    1. Creates users rtsAdmin, rtsUser1, and rtsConfig.

    2. Copies configureDCCluster.sh script to deployment manager target directory, for example...

        profiles/Dmgr01/bin


    Run configureDCCluster to create a cluster

    Not that you cannot use the configuration script to add a node to an existing cluster.

    1. Set the ODM_HOME environment variable.

    2. Edit configureDCCluster.properties to set the cluster name and database values.

      You can find this file in...

        profiles/Dmgr01/bin/rules/

      Configuration properties...

      wodm.dcrules.clusterName Can be existing cluster. If no cluster exists, a cluster is created. Default name is DecisionCenterCluster
      wodm.dcrules.db.type Database type: DB2, Oracle, or MSSQL. The default is DB2.
      wodm.dcrules.db.jdbcDriverPath Path to the JDBC drivers. Separate names colon (;). For example:

        C:/drivers/db2jcc.jar;C:/drivers/db2jcc_license_cu.jar;

      wodm.dcrules.db.name Name of the database. For example: MyDB
      wodm.dcrules.db.hostname Name of the host where the database is hosted: For example: MyDB_server
      wodm.dcrules.db.port Port number to establish the connection to the database
      wodm.dcrules.db.user User name to connect to the database. For example: db_user1
      wodm.dcrules.db.password Password for the user to connect to the database. For example: db_user1_pwd

    3. Run...

        cd WAS_HOME/profiles/Dmgr01/bin/
        ./configureDCCluster.sh -dmgrAdminUsername websphere \
                                -dmgrAdminPassword websphere  \
                                -clusterPropertiesFile WAS_HOME/profiles/Dmgr01/bin/rules/configureDCCluster.properties
                                -createNode \
                                -targetNodeName DecisionCenterNode01 \
                                -dmgrHostName localhost \
                                -dmgrPort 8879 

      Parameters...

      Parameter name Required Description
      -dmgrAdminUsername Mandatory WAS administrator
      -dmgrAdminPassword Mandatory WAS administrator
      -clusterPropertiesFile Mandatory Full path to the properties file.
      -uninstall Optional Remove applications and resources from the cluster. The cluster itself is not removed because it might contain other applications.
      -createNode Optional Create a default node profile with the name set in the -targetNodeName parameter.
      -targetNodeName Optional Default RulesNode01
      -dmgrHostName Optional Computer hosting the dmgr. Mandatory if target node was created using -targetNodeName.
      -dmgrPort Optional SOAP TCP port of the deployment manager. By default, 8879.

    If you make a mistake, you can execute the script again.

    The script performs the following actions:

    • Installs the JDBC provider and the data source at node level.
    • Installs the Decision Center application at the cluster level. Users are mapped to application groups when an application is deployed.
    • Starts the deployment manager server if it is not already started.
    • Configures security.
    • Creates the rtsAdmin, rtsInstaller, rtsUser1, and rtsConfig users.
    • Configures users and groups.
    • Maps users and groups to roles.
    • Starts the cluster, servers, and applications.

    Connect to the Decision Center administration console to verify whether the cluster is correctly started and, if it is not, start it manually.


    Unaugment Decision Center from an existing cluster

    cd WAS_HOME/bin/
    ./manageprofiles.sh -unaugment \
                        -profileName Dmgr01 \
                        -templatePath WAS_HOME/profileTemplates/rules/management/dc \
                        -nodeName DecisionNode \
                        -cellName DecisionCell \
                        -targetNodeName DecisionCenterNode01
    

    The command removes the rtsAdmin, rtsInstaller, rtsUser1, and rtsConfig users. The cluster is kept as is to prevent any risk of deleting previously existing configurations.


    Uninstall Decision Center from a cluster

      cd WAS_HOME/profiles/Dmgr01/bin/
      ./configureDCCluster.sh -dmgrAdminUsername websphere \
                              -dmgrAdminPassword websphere  \
                              -clusterPropertiesFile WAS_HOME/profiles/Dmgr01/bin/rules/configureDCCluster.properties
                              -targetNodeName DecisionCenterNode01 \
                              -dmgrHostName localhost \
                              -dmgrPort 8879 \
                              -uninstall 

    Parameters...

    Parameter name Mandatory/Optional Description
    -dmgrAdminUsername Mandatory WAS administrator
    -dmgrAdminPassword Mandatory WAS administrator password
    -clusterPropertiesFile Mandatory Full path to the properties file.
    -uninstall Mandatory Remove applications and resources from the cluster. The cluster itself is not removed because it might contain other applications.
    -createNode Optional Create a default node profile with the name set in the -targetNodeName parameter.
    -targetNodeName Optional Default is RulesNode01
    -dmgrHostName Optional Computer hosting the dmgr. Mandatory if target node was created using -targetNodeName.
    -dmgrPort Optional SOAP TCP port of the deployment manager. By default, 8879.

    Results:

    • Uninstalls the clustered application (teamserver).
    • Uninstalls the data source.
    • Removes application users and groups.


    Configure event runtime

    Augment existing WAS management profile using profile templates

    Before augmenting, stop the deployment manager.

    During the profile creation task, you are prompted to select the database manager which hosts the tables for the event runtime. Unless you are using Apache Derby, create this database before starting to create the profile.

    After augmenting, review profile security configuration. If administrative security is enabled, application security must also be enabled.


    Augment an existing management profile using manageprofiles.sh

    manageprofiles.sh -augment \
                      -templatePath "ODM_HOME/WAS/profileTemplates/wbe/management" \
                      -profileName Dmgr01

    Parameters:

    -augment Augment the existing profile.
    -templatePath /path/to/template was_install_dir/profileTemplates/wbe/management
    -profileName profile_name Existing management profile to augment.
    -wbeHome /path/to/install Installation location for Decision Server Events. Specify if you have installed Decision Server Events in a nondefault location.
    -hostName host_name Computer hosting the profile.
    -adminUserName username Required if WAS administrative security is turned on.
    -adminPassword password Required if WAS administrative security is turned on.
    -wbeDbType database_type

    • Derby_Embedded: Not supported for use in a cluster
    • DB2_Universal: Default for management profile
    • Derby_NetworkServer
    • Oracle
    • MS_SQL_Server

    -wbeDbName database_name Required unless -wbeDbType is Derby_Embedded.
    -wbeDbUserId database_user_name Required unless -wbeDbType is Derby_Embedded.
    -wbeDbPassword password Password for the user ID used to access the database server. Required unless -wbeDbType is Derby_Embedded.
    -wbeDbJDBCClasspath /path/to/JDBC_class_files Path to the JDBC class path files. Required unless -wbeDbType is Derby_Embedded.
    -wbeDbHostName host_name Host name for the database server. Required unless -wbeDbType is Derby_Embedded.
    -wbeDbServerPort port_number DB listener port. Required unless -wbeDbType is Derby_Embedded.
    -wbeMsgingType messaging_type JMS provider to be configured.

    Default_Messaging Default. Use WAS default messaging.
    MQ_JMS_Messaging Use WebSphere MQ
    No_Messaging No JMS provider configured. Configure a JMS provider manually.

    -wbeMqMsgingQmgrName queue_manager_name WebSphere MQ queue manager name. Required only if -wbeMsgingType is MQ_JMS_Messaging.
    -wbeMqMsgingQmgrHostName host_name Host name of the WebSphere MQ queue manager. Required if -wbeMsgingType is MQ_JMS_Messaging.
    -wbeMqMsgingQmgrPort port_number WebSphere MQ queue manager listener port. Required if -wbeMsgingType is MQ_JMS_Messaging.
    -wbeMqMsgingTransType transport_type WebSphere MQ client transport type, either BINDINGS or CLIENT. Required only if -wbeMsgingType is MQ_JMS_Messaging.
    -disableBusSecurity Disable bus security for the service integration bus, WbeBus, when the bus is created.

    If administrative security is enabled for the profile, also enable application security for the profile.


    Unaugment an existing profile

    manageprofiles.sh -unaugment 
                      -templatePath "ODM_HOME/WAS/profileTemplates/wbe/management"
                      -profileName WODMDmgr01

    Parameters:

    -unaugment Unaugment the existing profile.
    -templatePath /path/to/template was_install_dir/profileTemplates/wbe/management
    -profileName profile_name Existing management profile to unaugment.

    Decision Server Events features are removed from the profile.


    Augment an existing WAS custom profile

    Stop node agents and servers in the profile, then run...
      manageprofiles.sh -augment \
                        -templatePath "ODM_HOME/WAS/profileTemplates/wbe/managed"
                        -profileName Custom01

    Parameters:

      -augment Augment the existing profile.
      -templatePath /path/to/template was_install_dir/profileTemplates/wbe/managed
      -profileName profile_name Existing custom profile to augment.


    Unaugment an existing profile

    manageprofiles.sh -unaugment 
                      -templatePath "ODM_HOME/WAS/profileTemplates/wbe/managed"
                      -profileName WODMCustom01

    Parameters:

      -unaugment Unaugment the existing profile.
      -templatePath /path/to/template was_install_dir/profileTemplates/wbe/managed
      -profileName profile_name Existing custom profile to unaugment.

    Decision Server Events features are removed from the profile.


    Create profiles for a gold topology cluster

    1. Install Decision Server Events on both Computer1 and Computer2.

    2. On Computer1, create a WAS management profile.

      1. Run...

          cd was_install_dir/bin/ProfileManagement ./pmt.sh

      2. On the Welcome page, select Launch Profile Management Tool then Create.

      3. On the Environment Selection page, under WebSphere Application Server, click Management then Next then Deployment manager.

      4. Click Typical or Advanced profile creation.

      5. Clear Launch the First steps console and click Finish.

      As an alternative to using the Profile Management Tool, for example where a graphical user interface is not available, navigate to the was_install_dir/bin directory and run manageprofiles.sh. To create the deployment manager, use the template...

        cd /opt/WAS/ODM/AppServer/bin/
        ./manageprofiles.sh -create \
                          -templatePath /opt/WAS/ODM/AppServer/profiles/profileTemplates/management \
                          -serverType DEPLOYMENT_MANAGER \
                          -profileName odmDmgr \
                          -profilePath /opt/WAS/ODM/profiles/dmgr \
                          -enableAdminSecurity true \
                          -adminUserName celladmin \
                          -adminPassword celladmin \
                          -cellName odmCell \
                          -startingPort 49000 
        

    3. Ensure that the deployment manager is stopped, then Augment an existing WAS management profileaugment the WAS management profile with Decision Server Events.

      Select WAS default messaging as the messaging provider.

    4. Start the deployment manager on Computer1:

        cd was_install_dir/profiles/dmgr_profile_name/bin
        ./startManager.sh command

    5. On Computer1, create a WAS custom profile.

      1. Run...

          cd was_install_dir/bin/ProfileManagement
          ./pmt.sh

      2. On the Welcome page, select Launch Profile Management Tool then Create.

      3. On the Environment Selection page, under WebSphere Application Server, click Custom profile then Next.

      4. Click Typical or Advanced profile creation.

      5. On the Federation page, federate the custom profile into the cell of the deployment manager.

        • Enter the connection details for the deployment manager that we created in step 2.

        • Clear Federate this node later.

        • Click Next then click Create.

        If federation is successful, you can skip step 7.

      6. Clear Launch the First steps console and click Finish.

      As an alternative to using the Profile Management Tool, for example where a graphical user interface is not available, navigate to the was_install_dir/bin directory and run manageprofiles.sh. To create the custom profile, use the template...

        cd /IBM/ODM/ODM/AppServer/bin/
        ./manageprofiles.sh -create \
                            -templatePath /IBM/ODM/ODM/AppServer/profiles/profileTemplates/managed \
                            -profileName node01 \
                            -profilePath /IBM/ODM/ODM/profiles/node01 \
                            -nodeName node01 \
                            -cellName ODMNode01Cell \
                            -federateLater true \
                            -dmgrHost dmgrhost.mydomain.com \
                            -dmgrPort 49003 
        

    6. Check that the system clocks on all of the computers that you are using to create the cluster are synchronized and, to ensure that any time-based logic evaluates correctly, that the clocks are set to the same time zone.

    7. If you successfully federated in step 5, you can skip this step. Otherwise, on Computer1, federate the custom profile into the cell of the deployment manager:

      1. cd was_install_dir/bin

      2. Run...
        addnode -profileName profile_name \
                <deployment manager host> <deployment manager port>

      3. Start the WAS administrative console for the deployment manager.

      4. Log in to the WAS administrative console and validate that the application server has been successfully federated to the deployment manager. Click...

          System administration | Nodes

      On Computer1, the custom profile is now federated into the cell of the deployment manager.

    8. Augment the WAS custom profile with Decision Server Events.

      1. Ensure that the node agent is stopped. To stop the node agent in the WAS administrative console, click System administration > Node agents. Select the node agent and click Stop.

      2. Augment the custom profile with Decision Server Events.

    9. On Computer2, repeat steps 5 to 8 to create, federate, and augment a second WAS custom profile.


    Configure a gold topology cluster

    In this task, you configure the gold topology cluster for which we created profiles, to complete creating the cluster environment.

    Before configuring the cluster, first create the profiles.

    The following steps assume that security is enabled for the service integration bus, as described in Secure the service integration bus.

    If security is not enabled, replace SIB_ENDPOINT_SECURE_ADDRESS with SIB_ENDPOINT_ADDRESS and omit the BootstrapSecureMessaging chain from each hostname:port pair in steps 2, 8, 9,10.

    1. Create a WAS cluster and add two application servers as members of the cluster:

      1. Click...

          Servers | Clusters | WebSphere application server clusters | New

      2. In the Cluster name field, enter a name for the cluster, for example...

          EventRuntimeCluster

        ...then click Next.

      3. In the Member name field, enter a name for the first application server that you are adding to the cluster, for example eventruntime01.

      4. Select the name of the node on which the first application server runs, then click Next.

      5. In the Member name field, enter a name for the next application server that you are adding to the cluster, for example eventruntime02.

      6. Select the name of the node on which this application server runs. Click Add member, then click Next.

      7. To add more application servers to the cluster, repeat steps f. and g.

      8. Click Finish and Save.

    2. Identify and record...

        hostname:port:BootstrapSecureMessaging,hostname:port:BootstrapSecureMessaging

      ...where each hostname:port pair corresponds to the host name and SIB_ENDPOINT_SECURE_ADDRESS of the application servers in the event runtime cluster. To identify this information from the administrative console:

      1. Click...

          Servers > WebSphere application server clusters > Event Runtime Cluster > Cluster members

        ...and note the hostname.

      2. For each cluster member, click Ports and record the port number associated with the SIB_ENDPOINT_SECURE_ADDRESS.

    3. Create a JVM custom property that points to the ODM installation directory.

      You must do this step for every application server in the cluster.

      1. Click...

          Servers | Server Types | WebSphere application servers | server-name | Java and Process Management | Process Definition | Java Virtual Machine | Custom properties

        ...where server-name is an application server in the cluster.

      2. Click New.

      3. In the Name field, type wbe.home

      4. As the value, enter the location of the home directory of your ODM installation.

        • For example, if you installed using the launchpad and accepted the default install location:

            ODM_HOME

        • For example, if you installed using Installation Manager and accepted the default install location:

            /opt/ibm/ODM85

      5. Click Apply and Save.

    4. Modify the server heapsize parameters.

      You must do this step for every application server in the cluster.

      1. Click...

          Servers | Server Types | WebSphere application servers | server-name | Java and Process Management | Process Definition | Java Virtual Machine

        • In the Initial heap size field, enter 768.

        • In the Maximum heap size field, enter 1024.

        • Click Apply and Save.

    5. Enable the Startup Bean service for each application server in the cluster.

      You must do this step for every application server in the cluster.

      1. Click...

          Servers | Server Types | WebSphere application servers | server-name | Container Services | Startup beans service

      2. Select Enable service at server startup.

      3. Click Apply and Save.

    6. Add the event runtime cluster as a member to the service integration bus:

      1. Click...

          Service integration | Buses | WbeBus | Bus members | Add | Cluster | DecisionServerCluster | Next

      2. Select a messaging engine policy setting from the options...

        • High availability
        • Scalability
        • Scalability with high availability

      3. To ensure the recovery of JMS messages after a failover, configure a message store.

        Set the type of message store by selecting either File store or Data store.

        Click Next

      4. On the Configure messaging engines panel, click the messaging engine name.

      5. Set the data store values:

        1. Either, if you are using a file store, set the value of Log directory path to point to a data store on a shared file system, for example...

            c:\filestoredirectory

          Set the Permanent store directory path to point to a data store on a shared file system.

        2. Or, if you are using a database, set the Data connection JNDI name, the schema name and the authentication alias, to point to a data store on a database that you have already created.

        Click Next.

      6. Click Change heap sizes. Accept the default values.

      7. Review the Summary information. Click Finish and Save.

    7. Create three service integration bus destinations for the event runtime messaging destinations:

      1. Click...

          Service integration | Buses | WbeBus | Destinations | New | Queue | Next

        In the Identifier field, type eventQueue, then click Next.

      2. Repeat this step to create two further queues, with identifiers of historyModuleQueue and durableEventQueue.

      3. Click Finish and Save.

    8. Modify the provider endpoints for the connection factories to point to the servers in the event runtime cluster:

      1. Click Resources > JMS > Connection factories.

      2. From the Scope list, click Cell=cell-name, where cell-name is the name of the cell.

      3. Click WbeConnectionFactory

      4. In the Provider endpoints field, type hostname:port:BootstrapSecureMessaging,hostname :port:BootstrapSecureMessaging, where each hostname:port pair corresponds to the host name and SIB_ENDPOINT_SECURE_ADDRESS of the application servers in the event runtime cluster.

      5. Click Apply and Save.

    9. Modify the provider endpoints for the JMS queue connection factory to point to the servers in the event runtime cluster:

      1. Click Resources > JMS > Queue connection factories.

      2. From the Scope list, click...

          Cell=cell-name

      3. Click WbeQueueConnectionFactory

      4. In the Provider endpoints field, type...

          hostname:port:BootstrapSecureMessaging,hostname:port:BootstrapSecureMessaging

        Each hostname:port pair corresponds to the host name and SIB_ENDPOINT_SECURE_ADDRESS of the application servers in the event runtime cluster.

      5. Click Apply and Save.

    10. Modify the provider endpoints for the JMS topic connection factory to point to the servers in the event runtime cluster:

      1. Click Resources > JMS > Topic connection factories.

      2. From the Scope list, click Cell=cell-name, where cell-name is the name of the cell.

      3. Click WbeTopicConnectionFactory

      4. In the Provider endpoints field, type...

          hostname:port:BootstrapSecureMessaging,hostname:port:BootstrapSecureMessaging

        Each hostname:port pair corresponds to the host name and SIB_ENDPOINT_SECURE_ADDRESS of the application servers in the event runtime cluster.

      5. Click Apply and Save.

    11. Install the event runtime application:

      1. Click Applications > New Application > New Enterprise Application.

      2. Click Remote file system.

      3. Click Browse and click a node or deployment manager to browse its file system. Locate the wberuntimeear application file.

      4. Enter the full path of the location of the wberuntimeear application file.

          ODM_HOME/runtime/wberuntimeear.ear

        Click Next.

      5. In the Preparing for the application installation window, select Fast Path. Click Next.

      6. In the Select installation options window, accept the default options and click Next.

      7. In the Map modules to servers window, in the Clusters and Servers field, click WebSphere:cell=cell-name,cluster=DecisionServerCluster, where cell-name is the name of the cell. Select both check boxes, click Apply, then Next.

      8. Click Finish and Save.

    12. Optional: Confirm that the EventWidgetEar is installed if you want to use Event Widgets in your cluster environment.

        Applications | Application Types | WebSphere enterprise applications

      Ensure that the EventWidgetsEar application is listed and shown as started.

      • Event Chart Manager
      • Event Chart
      • Event Capture
      • Event Replay

      Restriction: The Event Tester widget is not supported in a cluster environment.

    13. To ensure that all these changes take effect, and that the cluster can be started correctly, start the node agents on all the computers in the cluster:

        cd cd was_install_dir/bin
        ./startNode.sh -profileName profile_name

    14. Start all the application servers in the cluster:

      1. To do this step in the WAS administrative console, click Servers > Clusters > WebSphere application server clusters > <cluster-name> > Cluster members, where <cluster-name> is the name that you entered in step 1.

      2. Select the application server and click Start.

    The gold topology cluster is now configured and running.

    If the cluster fails to start, starting clusters.


    Create a cluster that uses WebSphere MQ as the messaging provider

    You can cluster Decision Server Events to provide high availability and scalability for the event runtime, but by using WebSphere MQ as the messaging provider instead of by using WAS default messaging as the messaging provider.

    A Decision Server Events cluster consists of a single deployment manager and one or more managed nodes. An event runtime cluster spans the managed nodes and provides high availability and scalability of the event runtime. This documentation describes how to set up a clustered event runtime for high availability and scalability, that uses WebSphere MQ as the messaging provider; but not how to configure WebSphere MQ for high availability. You create a two node cluster spanning two computers, as shown in the following diagram:

    • There is one cluster, contained inside a single cell.
    • A management profile is configured on Computer1.
    • There are managed nodes (custom profiles) on both Computer1 and Computer2.
    • Each computer has Decision Server Events and WAS installed.
    • WebSphere MQ is installed and configured for use with Decision Server Events and provides all of the JMS messaging capability for the event runtime.

    This cluster topology can be extended across more computers in a similar way, in a single cluster.

    To complete this task:


    Configure WebSphere MQ for use as a messaging provider

    Before you can use WebSphere MQ as the messaging provider for your Decision Server Events cluster, do some configuration tasks in WebSphere MQ.

    The WebSphere MQ administrator must do the following tasks:

    1. Create the queue manager, using the crtmqm command.

    2. Start the queue manager, using the strmqm command.

    3. If you are using WebSphere MQ V7.1, publish/subscribe must be enabled. Use the ALTER QMGR command for this queue manager.

    4. Create the queues required, by running:
        runmqsc queue-manager-name < mq-install-dir\java\bin\MQJMS_PSQ.mqsc
      where mq-install-dir is the installation location of WebSphere MQ.

    5. If you are configuring a cluster, create the extra queues required, by running:

        runmqsc queue-manager-name < InstallDir\config\was\create_MQ_JMS_MQ_queues.mqsc

      where InstallDir is the installation location of Decision Server Events.

    The WebSphere MQ queue manager is created and configured.


    Create profiles for a cluster that uses WebSphere MQ as the messaging provider

    In this task, we create the WAS profiles augmented with Decision Server Events required for a cluster that uses WebSphere MQ as the messaging provider.

    Configure WebSphere MQ for use as a messaging provider.

    1. Install Decision Server Events on both Computer1 and Computer2.

    2. On Computer1, create a WAS management profile.

      1. cd was_install_dir/bin/ProfileManagement
        ./pmt.sh command.

      2. On the Welcome page, select Launch Profile Management Tool then Create.

      3. On the Environment Selection page, under WebSphere Application Server, click Management then Next then Deployment manager.

      4. Click Typical profile creation or Advanced profile creation.

      5. Clear Launch the First steps console and click Finish.

      As an alternative to using PMT, for example where a graphical user interface is not available, cd...

        cd was_install_dir/bin
        ./manageprofiles.sh

      To create the deployment manager, use the profile template...

        cd /opt/WAS/ODM/AppServer/bin/
        ./manageprofiles.sh -create \
                          -templatePath /opt/WAS/ODM/AppServer/profiles/profileTemplates/management \
                          -serverType DEPLOYMENT_MANAGER \
                          -profileName odmDmgr \
                          -profilePath /opt/WAS/ODM/profiles/dmgr \
                          -enableAdminSecurity true \
                          -adminUserName celladmin \
                          -adminPassword celladmin \
                          -cellName odmCell \
                          -startingPort 49000 
        

    3. Ensure that the deployment manager is stopped, then augment the WAS management profile with Decision Server Events.

      Select WebSphere MQ as the messaging provider and provide the appropriate connection details.

    4. Start the deployment manager on Computer1:

        cd was_install_dir/profiles/dmgr_profile_name/bin
        ./startManager.sh

    5. On Computer1, create a WAS custom profile.

      1. was_install_dir/bin/ProfileManagement
        ./pmt.sh

      2. On the Welcome page, select...

      3. On the Federation page, federate the custom profile into the cell of the deployment manager.

        • Enter the connection details for the deployment manager that we created earlier.

        • Clear...

            Federate this node later

        • Click Next then click Create.

        If federation is successful, you can skip step 7.

      4. Clear Launch the First steps console and click Finish.

      As an alternative to using the Profile Management Tool, for example where a graphical user interface is not available, navigate to the was_install_dir/bin directory and run manageprofiles.sh. To create the custom profile, use the was_install_dir/profileTemplates/managed/ profile template.

        cd /IBM/ODM/ODM/AppServer/bin/
        ./manageprofiles.sh -create \
                            -templatePath /IBM/ODM/ODM/AppServer/profiles/profileTemplates/managed \
                            -profileName node01 \
                            -profilePath /IBM/ODM/ODM/profiles/node01 \
                            -nodeName node01 \
                            -cellName ODMNode01Cell \
                            -federateLater true \
                            -dmgrHost dmgrhost.mydomain.com \
                            -dmgrPort 49003 
        

    6. Check that the system clocks on all of the computers that you are using to create the cluster are synchronized and, to ensure that any time-based logic evaluates correctly, that the clocks are set to the same time zone.

    7. If you successfully federated in step 5, you can skip this step. Otherwise, on Computer1, federate the custom profile into the cell of the deployment manager:

        cd install_dir/bin
        ./addnode -profileName profile_name 
                  <deployment manager host> 
                  <deployment manager port>

        Default SOAP port of the deployment manager is 8879.

      1. Start the WAS administrative console for the deployment manager.

      2. Log in to the WAS administrative console and validate that the application server has been successfully federated to the deployment manager. Click...

          System administration | Nodes

      On Computer1, the custom profile is now federated into the cell of the deployment manager.

    8. Augment the WAS custom profile with Decision Server Events.

      1. Ensure that the node agent is stopped. To stop the node agent in the WAS administrative console, click...

          System administration | Node agents | node agent | Stop

      2. Augment the custom profile with Decision Server Events.

    9. On Computer2, repeat steps5 to 8 to create, federate, and augment a secondWAS custom profile.


    Configure a cluster that uses WebSphere MQ as the messaging provider

    In this task, you configure the cluster for which you have created profiles, to complete creating the cluster environment.

    Before configuring the cluster, first create the profiles.

    1. Create a WAS cluster and add two application servers as members of the cluster:

      1. Click...

          Servers | Clusters | WebSphere application server clusters | New

      2. In the Cluster name field, enter a name for the cluster, for example DecisionServerCluster, then click Next.

      3. In the Member name field, enter a name for the first application server that you are adding to the cluster, for example eventruntime01.

      4. Select the name of the node on which the first application server runs, then click Next.

      5. In the Member name field, enter a name for the next application server that you are adding to the cluster, for example eventruntime02.

      6. Select the name of the node on which this application server runs. Click Add member, then click Next.

      7. To add more application servers to the cluster, repeat steps f. and g.

      8. Click Finish and Save.

    2. Create a JVM custom property that points to the ODM installation directory.

      You must do this step for every application server in the cluster.

      1. Click...

          Servers | Server Types | WebSphere application servers | server-name | Java and Process Management | Process Definition | Java Virtual Machine | Custom properties | New

      2. In the Name field, type wbe.home

      3. As the value, enter the location of the home directory of your ODM installation.

        • For example, if you installed using the launchpad and accepted the default install location:

            ODM_HOME

        • For example, if you installed using Installation Manager and accepted the default install location:

            /opt/ibm/ODM85

      4. Click Apply and Save.

    3. For every application server in the cluster, enable the Startup Bean service for each application server in the cluster.

        Servers | Server Types | WebSphere application servers | server-name | Container Services | Startup beans service | Enable service at server startup | Apply | Save

    4. Install the event runtime application:

      1. Click Applications > New Application > New Enterprise Application.

      2. Click Remote file system.

      3. Click Browse and click a node or deployment manager to browse its file system. Locate the wberuntimeear application file.

      4. Enter the full path of the location of the wberuntimeear application file.

          ODM_HOME/runtime/wberuntimeear.ear

        Clic

        k Next.

      5. In the Clusters and Servers field, click WebSphere:cell=cell-name,cluster=DecisionServerCluster, where cell-name is the name of the cell.

      6. Select both check boxes.

      7. Click Apply, then Next.

      8. Click Finish and Save.

    5. To ensure that all these changes take effect, and that the cluster can be started correctly, start the node agents on all the computers in the cluster:

        cd was_install_dir/bin
        ./startNode.sh -profileName profile_name

    6. Start all the application servers in the cluster:

        Servers | Clusters | WebSphere application server clusters | cluster-name | Cluster members | application_server | Start

    The cluster that uses WebSphere MQ as the messaging provider is now configured and running. If the cluster fails to start


    What to do next

    Configure the technology connectors...

    1. Administer connector application deployment

    2. Configure technology connectors on a separate computer


    Defining a highly available collection of catalog servers

    The event runtime uses WebSphere eXtreme Scale during event processing. By default, the WebSphere eXtreme Scale catalog service runs only within the deployment manager. If the deployment manager is unavailable, the WebSphere eXtreme Scale shard placement might be affected. If you define a catalog service domain, you increase the availability of the event runtime cluster if the deployment manager is unavailable or restarts.

    Catalog service domains define a group of catalog servers that manage the placement of shards and monitor the health of container servers in your data grid.

    Follow the procedure described in Create catalog service domains in WebSphere Application Server to include the catalog service in multiple node agent processes or in an application server that is not hosting a WebSphere eXtreme Scale application.


    Configure Rule Execution Server on WAS

    The Rule Execution Server console...

      http://myhost.mydomain.com:port/res

    ...includes an Installation Settings wizard that will automatically...

    1. Run SQL drop statements to clear an existing Rule Execution Server database.
    2. Create the database schema

    To switch from default embedded Derby database to Oracle, DB2, or MySql, run Ant against...

      ODM_INSTALL/executionserver/bin/ressetup.xml

    ...which creates a new instance of the Rule Execution Server management archive and, in the case of a Java EE application server, the execution unit (XU).

    For file-based persistence on Solaris, the file system must support all characters used in directory and file names present in the ruleset path (RuleApp name and ruleset name).

    Set the LANG system property with encoding compatible with your package and rule names, for example en_US.UTF-8.

    If select the file persistence type for RuleApps, you cannot use Decision Warehouse.

    For MySQL perisistence, edit...

    • my.ini (Windows)
    • my.cnf (UNIX)

    ...and set...

    Integration extensions are available from ODM SupportPacs


    Database permissions

    Database permission Operation
    Edit RuleApps Create schema
    CREATE ANY INDEX Not required Required
    DROP ANY INDEX Not required Required
    CREATE ANY SEQUENCE Not required Required
    DROP ANY SEQUENCE Not required Required
    SELECT ANY SEQUENCE Required Not required
    CREATE ANY TABLE Not required Required
    DROP ANY TABLE Not required Required
    INSERT ANY TABLE Required Not required
    SELECT ANY TABLE Required Not required
    UPDATE ANY TABLE Required Not required
    DELETE ANY TABLE Required Not required
    CREATE ANY TRIGGER Not required Required
    CREATE ANY VIEW Not required Required
    DROP ANY VIEW Not required Required

    If persistence is set to file, you can skip all database-related tasks and proceed to Deploy the Rule Execution Server Management EAR.


    Create an empty Derby database

    If you are using default embedded Derby, to create a database...

    1. Stop the application server.

    2. Run...

        DerbyInstallDir/bin/ij

    3. Create the database resdb.

        ij> connect 'jdbc:derby:c:/resdb;user=resdbUser;password=resdbUser;create=true';

    4. Close the ij utility.

        ij> quit;

    5. Start the application server.


    Set up a data source and connection pool

    Create JDBC provider...

    1. If you are using Oracle OCI, set environment variables PATH and LD_LIBRARY_PATH to include these drivers.

      Review driver documentation to determine if these settings are required for your driver type.

    2. Log in to the Integrated Solutions Console and open...

        Resources | JDBC | JDBC Providers | Scope | New

      For example:

      Option Description
      Database type Derby
      Provider type Derby JDBC Provider
      Implementation type Rule Execution Server JDBC Provider, which supports XA features.

    3. Click Next.

    4. Skip Step 2.

      A summary is provided in Step 3.

    5. Check that the class path to the JAR file of your driver and the implementation class are correct.

      Default values are usually sufficient.

    6. Click Finish and Save to save the changes to the master configuration, making sure that the Synchronize changes with Nodes check box is selected.

    7. Restart your server to have these changes taken into account.


    Create a data source and connection pool

    Create a connection pool and a data source in WAS to enable Rule Execution Server.

    1. In the Integrated Solutions Console, open...

        Resources | JDBC | Data sources

    2. Under Scope, select the scope that you selected for the JDBC provider in Create a JDBC provider and click New.

    3. In Step 1, enter Rule Execution Server datasource as the name for the data source and jdbc/resdatasource in the JNDI name field, and click Next.

      You can enter any name for the data source, but the JNDI name must be jdbc/resdatasource.

    4. In Step 2, choose Select an existing JDBC provider, select the JDBC provider that we created in Create a JDBC provider, and click Next.

    5. In Step 3, enter the specific database properties for the data source.

    6. Deselect Use this data source in container managed persistence (CMP).

    7. Click Next.

    8. In Step 4, set up any required security aliases and click Next when done.

      In Step 5, a summary of the data source is provided.

    9. Click Finish and then Save to save the changes to the master configuration.


    Create J2C authentication data

    In WAS, you can secure your enterprise information system by creating J2C authentication data. After you have created your data source and connection pool, we create the J2C authentication data. J2C is a secure mechanism for integrating enterprise information systems to an application server and enterprise applications.

    1. In the Integrated Solutions Console, open...

        Resources | JDBC and Data sources | Rule Execution Server datasource | Related Items | JAAS - J2C authentication data | New

      ...and set the fields Alias, User ID, and Password.

      For example, this procedure uses the following values:

      • Alias: ResDerbyUser
      • User ID: resdbUser
      • Password: resdbUser

    2. Click Apply and Save to save directly to the master configuration.

    3. Open...

        Resources | JDBC and Data sources | Rule Execution Server datasource | Security settings | Component-managed authentication alias | alias | NodeName/ResDerbyUser

    4. For Container-managed authentication alias, select...

        node name/ResDerbyUser

    5. Click Apply and Save to save directly to the master configuration.


    Set custom properties

    The database to which you want to connect might require that you set some custom properties.

    Depending on the database to which you want to connect, you have different properties to define. The table below presents the minimum set of properties required to define the supported databases.

    If the driver that you use is not listed, check the WAS documentation for more information.

    Some of these properties might already have been defined. For example, if you are following this configuration procedure and have created a Derby database, all the properties for that database have already been defined.

    Database driver properties

    Database Properties
    DB2 Universal JDBC Driver

    • databaseName: The actual database name if driverType is set to 4, or a locally catalogued database name if driverType is set to 2

    • driverType: The possible values are 2 or 4. The following properties are required only if driverType is 4:

      • serverName: The TCP/IP address or host name

      • portNumber: The TCP/IP port number
    DB2 Universal JDBC XA Driver

    • databaseName: The locally catalogued database name

    • driverType: The possible values are 2 or 4. If you are running a version of DB2 earlier than DB2 V8.1 FP6, you are restricted to using only Type 2 driver. The following properties are required only if driverType is 4:

      • serverName: The TCP/IP address or host name
      • portNumber: The TCP/IP port number

    DB2 legacy CLI-based Type 2 databaseName: for example, Sample
    Oracle JDBC Driver URL: For example, jdbc:oracle:oci:@sample
    Derby databaseName: The path to the location of the database files.

    You can also set custom properties for any of the resources listed in the Custom properties page.

    1. In the Integrated Solutions Console, open...

        Resources | JDBC | Data sources

    2. Click the data source that you want to customize.

    3. Under Additional Properties, click Custom properties.

    4. Change an existing property or create a new one by clicking New.

      1. Click createDatabase.

        The General Properties page opens.

      2. Type create in the Value field.

      For example, for a Derby data source, if you have not created the database yet, you can set the value of the createDatabase property to create. The database is created at the first database connection.

    5. Click OK and Save to save the changes to the master configuration.


    Testing the connection to the database

    After you have created a data source and connection pool, and set the custom properties, you can test the connection to your database.

    1. In the Integrated Solutions Console, open...

        Resources | JDBC | Data sources

    2. Select the check box next to the data source that you want to test and click Test connection.

    The status of the connection is indicated at the top, as shown in the following example.

      The test connection operation for data source Rule Execution Server datasource on server server1 at node <NodeName> was successful.


    Activating security on WAS

    WAS provides security infrastructure and mechanisms to protect sensitive Java™ EE resources and administrative resources and to address enterprise end-to-end security requirements on authentication, resource access control, data integrity, confidentiality, privacy, and secure interoperability.


    Introduction to WAS security

    In WAS, security is organized in layers, from the platform security up to the WAS-specific layer, based on the Java™ EE model, over the Java security layer.

    The following diagram shows the security layers in WAS.

    WAS supports the Java EE model for creating, assembling, securing, and deploying applications.

    By default, the Rule Execution Server console does not require security in WAS. However, to activate access control for Rule Execution Server in WAS, follow these steps:

    1. Create users and groups: If you do not already have groups and users defined or if you want to define new groups and users, proceed with the subsequent steps. If you already have groups and users defined that can match the expected role, proceed to connect them to the roles during the application deployment.

    2. Mapping the resAdministrators group to the Monitor role


    Create users and groups

    Create users and groups and assign them roles using a user registry with a federated repository.

    If you do not have groups and users defined or if you want to define new groups and users, proceed with the following steps. If you already have suitable groups and users defined, skip this procedure and connect users to their appropriate roles when you deploy the applications. WAS uses various kinds of user registries: OS, LDAP, or Custom. To configure a federated repository as a user registry, you work from the WAS Integrated Solutions Console. You control access to Rule Execution Server and enforce security by defining groups and users.

    • resAdministrators

      Gives a user full administrator rights to:

      • Access and use the Rule Execution Server console to populate the database schema

      • Deploy, browse, and modify RuleApps

      • Monitor the decision history, purge and back up the history

      • Run diagnostics and view server information

        Default user/pass: resAdmin/resAdmin

      • resDeployers

        Gives a user the rights to:

        • Deploy, browse, and modify RuleApps
        • Test rulesets

        Default user/pass: resDeployer/resDeployer

      • resMonitors

        Gives a user the rights to:

        Default user/pass: resMonitor/resMonitor

        • View RuleApps
        • Monitor decision history and access Decision Center reports

    1. In the side panel, open...

        Security | Global security

    2. Configure the repository security as follows:

      • If Federated repositories is already selected under Current realm definition, make sure that Enable application security is selected. If you select Enable application security, click Apply and Save to save the changes to the master configuration.

      • If Federated repositories is not already selected, click Security Configuration Wizard, and then complete the wizard as follows:

      1. In Step 1, to specify the level of protection, select Enable application security and click Next.

      2. In Step 2, select Federated repositories and click Next.

      3. In Step 3, type a name in the Primary administrative user name field and enter websphere in the Password field, and then click Next.

      4. In Step 4, review the security configuration summary and click Finish.

      5. Click Save to save the changes to the master configuration.

      6. Restart WAS.

        Then log in to the Integrated Solutions Console as the primary administrative user.

    3. In the side panel, open Users and Groups  > Manage Groups, and then click Create.

    4. Enter resAdministrators as the group name, then click Create.

    5. Click Create Like and create another group named resDeployers. Click Create.

    6. Click Create Like again and enter another group named resMonitors. Click Create, then click Close.

    7. In the side panel, open Users and Groups  > Manage Users and then click Create.

    8. Enter resAdmin as the User ID and again resAdmin as the password. Also specify the given name and last name.

    9. Click Group Membership and proceed as follows:

      1. Click Search, select the resAdministrators, resDeployers, and resMonitors groups.

      2. Click Add.

      3. Click Close, then click Create and Close again.

    10. Create users with deployer and monitor roles as follows:

      1. Create another user named resDeployer with password resDeployer.

      2. Assign the user to the resDeployers and resMonitors groups.

      3. Create a user named resMonitor with password resMonitor.

      4. Assign the user to the resMonitors group.

    11. Restart the application server or the deployment manager.


    Mapping the resAdministrators group to the Monitor role

    You can give Rule Execution Server users access to the model MBeans by configuring a mapping between the resAdministrators group declared in the custom registry and the Monitor role. To access the MBeans of the Rule Execution Server model, an application must have sufficient security credentials, restricted to the Monitor role in the WAS authentication system.

    1. In the Integrated Solutions Console, open Users and Groups  > Administrative group roles.

    2. Click Add.

    3. For Role(s), select Monitor, click Search, and move the entry beginning with resAdministrators from the Available column to the Mapped to role column, and then click OK.

    4. Click Save to save directly to the master configuration.

    5. Restart the application server or the deployment manager.


    Security policies for the Rule Execution Server console

    To record and manage sets of MBeans, you need to override the WAS security policies for the Rule Execution Server console.

    When the global security of WAS is activated, the MBean server is not accessible from the deployed application. You must override these security policies for the Rule Execution Server console so that it can record and manage a set of MBeans.

    Rule Execution Server is packaged with a specific policy file, was.policy, which overrides the server policies. The was.policy file is packaged in the META-INF directory of the jrules-res-management-WAS<version_number>.ear file.


    Deploy the Rule Execution Server Management EAR

    After you have activated the security, deploy the Rule Execution Server EAR to WAS. You deploy the Rule Execution Server management EAR to WAS to apply the persistence type you set in a previous step and you map security users groups.

    1. Open the Integrated Solutions Console.

    2. In the side panel, open...

        Applications | New Application | New Enterprise Application | Local file system | archive file | Next

        • InstallDir/executionserver/applicationservers/WebSphere8/jrules-res-management-WAS8.ear
        • InstallDir/executionserver/applicationservers/WebSphere85/jrules-res-management-WAS85.ear

    3. Select the check box...

        Detailed - Show all installation options and parameters

    4. Expand...

        Choose to generate default bindings and mappings

      Select the check box...

        Generate Default Bindings

      and click Next.

    5. Click Continue to accept the security warning.

    6. In Step 1, click Next to accept the default settings.

    7. In Step 2, proceed as follows:

      • If you have only one server, skip Step 2.

      • If you have more than one server, select the server to which you want to deploy the application, and then select the check box for ILOG Rule Execution Server Console and click Next.

    8. In Step 3 through Step 8, click Next to accept the default settings.

    9. Click Map security roles to users or groups. Here you map security roles to users and groups, as follows:

      1. Select the check box next to the resAdministrators role.

      2. Click Map Groups and click Search. The groups are shown in a column titled Available.

      3. Click resAdministrators under Available, and then click the arrow button to move resAdministrators to the Selected column.

      4. Click OK to return to the Mapping Users to Roles page.

      5. Repeat steps 10.a through 10.d to map the roles resDeployers and resMonitors for the other groups, making sure that only the check box next to the role that you are assigning is selected.

        Role Mapped groups
        resAdministrators resAdministrators
        resDeployers resDeployers
        resMonitors resMonitors

    10. Click Next.

      • On WAS 7, Step 10 provides a summary.

      • On WAS 8, proceed as follows:

      1. Click Next.

      2. In Step 10 and Step 11, click Next to accept the default settings.

        Step 12 provides a summary.

    11. Click Finish.

    12. After the installation has completed, click Manage Applications at the bottom of the panel.

    13. Click ILOG Rule Execution Server.

    14. Click Manage Modules.

    15. Click ILOG Rule Execution Server Console.

    16. Under General Properties, for Class loader order, select Classes loaded with local class loader first (parent last).

    17. Click OK, then click Save to save directly to the master configuration.

    18. In the side panel, open Applications  > Application Types > WebSphere enterprise applications.

    19. In the Enterprise Applications page, select the check box next to ILOG Rule Execution Server and click Start to start the application.


    Create a Rule Execution Server database schema

    You can create the Rule Execution Server database schema by running SQL scripts, either from the Rule Execution Server console or from the SQL tool of your database.


    Create a database schema using the Rule Execution Server console

    Use the Installation Settings wizard of the Rule Execution Server console to...

    • Set database type, name, location, driver, JDBC URL, and credentials
    • Create the Rule Execution Server schema with the necessary tables and views.

    The Installation Settings wizard creates all the required tables for Rule Execution Server and for Decision Validation Services, even if you do not have a license for Decision Validation Services.

    If you are using file persistence or have an existing database schema, the Installation Settings wizard will not open. To modify the database schema after the database tables are created it is necessary to run the SQL scripts in the database client.

    To configure the database to store managed Java XOM, follow the procedure twice, with a different target database each time. The combination of persistence settings for RuleApps and managed Java XOMs affects the way in which you use the Installation Settings wizard.

    • If RuleApp persistence and Java XOM persistence are both set to file: No wizard is presented.

    • If RuleApp persistence and Java XOM persistence are both set to datasource, the process is in two steps:

      1. When you sign in to the Rule Execution Server console, the RuleApp persistence details part of the Installation Settings wizard is displayed for you to create the schema for RuleApps and the Decision Warehouse trace.

      2. After you have created the schema, the Java XOMs persistence details part of the wizard is displayed for you to configure the database for Java XOM persistence.

    • If RuleApp persistence is set to file and Java XOM persistence is set to datasource: You see only Java XOMs persistence details and you cannot use the Decision Warehouse.

    • If RuleApp persistence is set to datasource and Java XOM persistence is set to file or is not defined: When you sign in to the Rule Execution Server console, only RuleApp persistence details is displayed for you to create the schema for RuleApps. The Java XOMs persistence details part of the wizard is not shown.

    The following table summarizes the cases.

      Persistence RuleApps
      file datasource or jdbc
      Java XOMs file No Installation Settings wizard RuleApps persistence details only
      datasource or jdbc

      Java XOMs persistence details only

      No Decision Warehouse

      Complete Installation Settings wizard


    Open the Rule Execution Server console

    1. Start the database.

    2. Open the Rule Execution Server console in a Web browser...

        http://myhost.mydomain.com:port/res

    3. Sign in to the Rule Execution Server console as the user with resAdministrator rights...

      User ID resAdmin
      Password resAdmin

    4. If you are using datasource as the persistence setting, and an empty database schema, the Installation Settings wizard opens.


    Welcome to the Installation Settings wizard

    The wizard starts with RuleApp persistence details if you set datasource persistence for RuleApps, whatever the persistence type for managed Java XOMs.

    If you set datasource persistence for both RuleApps and Java XOMs, Java XOMs persistence details are displayed after RuleApp persistence details. In this case, you go through the same steps twice.

    The wizard starts with Java XOMs persistence details only if you have set the persistence type to file for RuleApps and to datasource for managed Java XOMs.

    Both parts of the wizard are similar and you use them in the same way:

    • Persistence details about the type of database used, including information about the driver and JDBC URL.
    • A brief description of the purpose of the Installation Settings wizard.
    • A diagnostic report that explains why the persistence check failed (because you have not yet created the database tables).


    Choose the database schema

    After you have read the Welcome page, you choose the database schema. Specific settings are available for DB2 . Optionally, you can select a customized SQL script.

    To choose the database schema:

    1. In the Database schema selected field, select an available database schema type.

      A type that corresponds to the type of database you are using is selected by default, but you can choose another type from the drop-down list.

      If you select a db2 or db2_os390 schema, an extra field displays so that you can enter the name of the buffer pool, which is used to create the Decision Warehouse tablespace. This buffer pool must have a page size of 32K. Check the DB2 documentation for information about how to create a 32K buffer pool.

      The scripts for creating the Decision Warehouse database on DB2 are written for databases that use automatic storage. When you use the Installation Settings wizard, we create both the Rule Execution Server and the Decision Warehouse database, so your database must use automatic storage.

      If you have not configured your DB2 database to use automatic storage, you cannot use the Rule Execution Server console to create the Rule Execution Server tables.

    2. Optional: Select custom if you want to use a customized SQL script, then click Browse to select the location of the custom script.

    3. Click Next to review the database schema.


    Review the database schema

    After you have selected a database type, you confirm the creation of a schema for Rule Execution Server. You can also use SQL drop statements that flush data from an existing table and view the SQL statements.

    Before using this option, ensure that you have a backup of database resources.

    To confirm the creation of a schema:

    1. Select from the following options:

      Option Description
      Create SQL schema resdbUser Run the SQL statement for the schema type selected in the previous step.
      Keep drop SQL statements Flush data from an existing Rule Execution Server database.
      Show SQL statements Display the SQL statements.

    2. Click Execute to start the options that you have selected.


    The Installation Settings wizard report

    After you have confirmed the database schema, the Installation Settings wizard creates the schema. A report shows the status of the schema creation.

    To use the options in the report:

    1. Click Show execution details to view the list of SQL statements executed.

    2. Click Finish.

      If you have just worked in RuleApps persistence details and the persistence setting for managed Java™ XOMs is datasource, the Java XOMs persistence details part of the wizard displays now for you to repeat the procedure.

    3. With database configured, when you log on to the Rule Execute Server console, you should see...


    Create the database schema by running SQL scripts

    After we create an empty database, we create the schema for the Rule Execution Server database. One way of doing so consists in running SQL scripts.

    The script that creates the database schema is named repository_<DatabaseName>.sql.

    To use Decision Warehouse, you can also create the required database tables by running the script trace_<DatabaseName>.sql. If you are also persisting the Java™ XOM in a database, create these tables by running the xomrepository_<DatabaseName>.sql script.

    If you use Command Editor to run the scripts, log in with the credentials you use for the data source for Rule Execution Server.

    Use any tool that can handle SQL to import and run the SQL scripts.

    Database Database tool
    IBM DB2 DB2 command line processor
    Derby ij command line processor
    MySQL mysql command line processor
    Oracle sqlplus command line processor
    Postgre SQL Postgre SQL command line tool
    SQL Server Query Tool
    Sybase isql command line processor

    To access the database, the database user must be granted the following credentials:

    • A user ID
    • A password
    • Complete privileges on the tables and view of the schema (create, insert, delete)
    • Privileges for index creation (create index)
    • On Oracle, additional creation privileges create trigger and create sequence.

    When you use an Oracle database, run all the scripts in the SQL Plus client.

    When you use DB2, the scripts that create the Rule Execution Server database tables are written for databases that use automatic storage. The following constraints apply:

    • BP32K is the buffer pool that is expected in SYSCAT.BUFFERPOOLS. If BP32K is not there, you can use the existing buffer pool or create a new buffer pool named BP32K. Use the following command to query SYSCAT.BUFFERPOOLS for the existing buffer pool:

        Select * from SYSCAT.BUFFERPOOLS

      Otherwise... to create a buffer pool named BP32K:

        CREATE BUFFERPOOL BP32K SIZE 2000 PAGESIZE 32K

    • You must update the trace_db2.sql script and select the custom option in the Installation Settings wizard to run it. Modify the following line in the script to specify storage for tablespace:

        CREATE TABLESPACE RESDWTS PAGESIZE 32K BUFFERPOOL BP32K;

      Here is an example of the tablespace specification in the script:

        CREATE TABLESPACE RESDWTS PAGESIZE 32K MANAGED BY Database USING [ FILE 'C:\DB2\Container.file' 640 ] BUFFERPOOL BP32K;

    • You might have to further modify the script based on your database settings.


    Run the Derby SQL scripts

    This example shows how to run the Derby SQL script to create the schema. It is assumed that the embedded version of Derby is used.

    The following example describes how to create a Derby schema.

    1. Stop the application server.

    2. Connect to the database. For example, to create and connect to the database c:/resdb as the user resdbUser, use the command:

        ij>connect 'jdbc:derby:c:/resdb;user=resdbUser;password=resdbUser;';

    3. Run the script that creates the database schema:

        ij> run 'InstallDir/executionserver/databases/repository_derby.sql';

      If the script is being run for the first time, some errors related to the drop statements might occur.

      If you have installed Decision Validation Services, also create the required database schema by running the script trace_derby.sql.

    4. Close the ij utility:

        ij> quit;

    5. Start the application server.


    Deploy the Rule Execution Server MBean descriptors

    To configure Rule Execution Server for WAS, also deploy the MBean descriptors.

    Make sure you give the application server process enough access right to read the jrules-mbean-descriptors.jar file. For example, change the permissions on the file using a chmod 777 command. The Rule Execution Server architecture is based on the Java Management Extension (JMX) API. MBeans are Java objects used by the JMX API. To configure Rule Execution Server for WAS, deploy the MBean descriptors, either globally for all Rule Execution Server instances or for a single Rule Execution Server instance.

    • To deploy globally, copy the InstallDir/executionserver/lib/jrules-mbean-descriptors.jar file to...

        <WAS_HOME>/lib

    • To deploy to a targeted server instance, follow the procedure below.

    To deploy MBean descriptors:

    1. Open the Integrated Solutions Console.

    2. In the panel, open Servers  > Server Types > WebSphere application servers.

    3. In the Application servers pane, click the name of your server.

    4. Under Server Infrastructure, expand Java and Process Management and click Process definition. In WAS for z/OS, an additional layer provides three resources that can be administered: Adjunct, Control, and Servant. If you are working in that environment, select the Servant.

    5. Under Additional Properties, click Java Virtual Machine.

    6. In the Classpath field, add InstallDir/executionserver/lib/jrules-mbean-descriptors.jar.

    7. Click OK, then Save to save the changes directly to the master configuration.


    Deploy the XU RAR

    After you have deployed the MBean descriptors, you deploy resource adapter archive (RAR) for the execution unit (XU) onto WAS. The RAR file contains the XU and the persistence layer. In some cases, because of the application constraints, you might have to deploy the XU inside the application. Choose the appropriate deployment mode of the XU: either embed it into the EAR or deploy it as a global connector. Be aware of the following consequences:

    • When the XU is deployed as a global connector:

      • The deployed Java™ EE applications might use its third-party libraries (such as ASM) instead of the libraries deployed in the application server.

      • Use a parent last setting for the XU Java EE application if your Java EE application does not support the version of the third-party libraries distributed with Decision Server. If you cannot use a parent last setting, you might need to embed the XU into the EAR that executes the rules.

    • If you choose an embedded XU packaging, use a parent last setting for the code library if the third-party libraries version deployed at the level of the application-server code library are not compatible with the XU.

    To deploy the XU RAR:

    1. Open the Integrated Solutions Console.

    2. In the panel, open...

        Resources | Resource Adapters | Resource adapters | Install RAR

    3. In the panel, select Local file system and browse to the resource archive file:

      InstallDir/executionserver/applicationservers/WebSphere<version_number>/jrules-res-xu-WAS<version_number>.rar

    4. In Scope, select the node where you want to install the XU RAR file, and then click Next.

    5. In the General Properties page:

      1. Set the name for the XU, such as RES XU Resource Adapter

      2. For WAS version 8.5, select Isolate this resource provider

      3. Click OK

    6. cd new XU resource adapter and click on its name.

    7. Under Additional Properties, click J2C connection factories and New.

    8. Enter the following values:

      • Name: xu_cf

      • JNDI name: eis/XUConnectionFactory

    9. Click OK and Save to save the changes to the master configuration.

    10. Optionally, you can define more than one XU resource adapter.

      You need additional XU resource adapters when you have more than one node in your environment or you want to isolate the development environment and testing environment in one single node. You can deploy a JCA resource adapter at any level, depending on the capability of the application server. On WAS, you can install the XU resource adapter at the cell, node, cluster, or server level. But install it at the node level before you can deploy it at other levels.

      For example, to define a XU resource adapter on the server level:

      1. In the panel, open...

          Resources | Resource Adapters | Resource adapters | Install RAR

      2. Select the scope Node=xxx, Server=yyy, where xxx is the name of your node, yyy is the name of your server.

      3. Click New and enter the name of the XU as XU.

      4. In Archive Path, select...

          ${CONNECTOR_INSTALL_ROOT}/jrules-res-xu-WAS<version_number>.rar

      5. For WAS version 8.5, select Isolate this resource provider.

      6. Click OK.

      7. Repeat 5 through 9 to define the connection factory.

    11. Restart the server.

      Whenever you install or uninstall a XU, restart the application server.


    Step 10: Deploy the hosted transparent decision service EAR

    You can optionally deploy the EAR file for hosted transparent decision services. You must deploy the EAR file on the same node as the execution unit (XU).

    1. Open the Integrated Solutions Console.

    2. In the side panel, click Applications > New Application and New Enterprise Application.

    3. In the side panel, select Local file system and browse to the archive file, and then click Next.

      InstallDir/executionserver/applicationservers/WebSphere<version_number>/jrules-res-htds-WAS<version_number>.ear

    4. Select the check box Detailed - Show all installation options and parameters.

      1. Expand Choose to generate default bindings and mappings.

      2. Select the check box Generate Default Bindings.

      3. Click Next.

    5. Click Continue to accept the security warning.

    6. For Step 1 to Step 10, click Next to accept the default settings.

      Step 11 provides a summary.

    7. Click Finish.

    8. After the installation completes, click Save to save directly to the master configuration.

    9. In the side panel, open Applications  > Application Types > WebSphere enterprise applications and click jrules-res-htds.

    10. Click Manage Modules.

    11. Click DecisionService.

    12. Under General Properties, for Class loader order, select Classes loaded with local class loader first (parent last).

    13. Click OK.

    14. Click OK and Save to save directly to the master configuration.

    15. In the side panel, open Applications  > Application Types > WebSphere enterprise applications.

    16. In the Enterprise Applications page, select the check box next to jrules-res-htds, and then click Start to start the application.


    What to do next

    1. Set the web container custom property DecodeUrlAsUTF8 to false to support a localized ruleset path.

    2. Set the ruleset.xmlDocumentDriverPool.maxSize ruleset property to the appropriate value.


    Step 11: Set the DecodeUrlAsUTF8 custom property

    The hosted transparent decision service requires that set the web container custom property DecodeUrlAsUTF8 to False to support a localized ruleset path.

    To set the DecodeUrlAsUTF8 web container custom property:

    1. Open the Integrated Solutions Console.

    2. Click...

        Servers | Server Types | WebSphere application servers | server name | Container Settings | Web container settings | Web container | Additional Properties | Custom properties | New

          ...and then type DecodeUrlAsUTF8 as the name and False as the value.

        • Click Apply and Save to save directly to the master configuration.


    Integrate WebSphere MQ in WAS

    The Java Message Service (JMS) API enables access to Decision Server rule services. To use a message-driven rule bean (MDB), create the necessary resources under the WebSphere MQ JMS provider.

    When a JMS message arrives, the EJB container calls an MDB, which calls a ruleset running in the execution unit (XU) of the Rule Execution Server. The call to the rule engine is delegated to a rule session.

    The following procedure demonstrates how to set up both point-to-point and publish-and-subscribe. If you need only one of them, comment out the resource reference in the MDB's deployment descriptor.

    Before integration, create the following resources in WebSphere MQ:

      Queue JRulesIn, JRulesOut
      Topic JRulesTopicIn, JRulesTopicOut

    Use these resources to submit rule execution requests and obtain execution results.


    Create the WebSphere MQ queue connection factory

    1. Log in to the Integrated Solutions Console and open...

        Resources | JMS | JMS Providers | WebSphere MQ messaging provider | Additional Properties | Queue connection factories | New

    2. For "Step 1: Configure basic attributes" set...

        Name JRules Queue Connection Factory
        JNDI name jms/BRESQueueConnectionFactory

    3. For "Step 2: Select connection method" select...

        Enter all the required information into this wizard

    4. For "Step 2.1: Supply queue connection details" type the name of your queue manager or queue sharing group.

    5. For "Step 2.2: Enter connection details" type the connection details to establish a connection to the queue manager or queue sharing group, then click Next. The default queue port is 1414.

    6. For "Step 3: Test connection", click Test connection.

      If your message queue is running, you see the following message:

        A connection was successfully made to WebSphere MQ.

    7. Click Next.

      A summary opens showing the details of the connection factory.

    8. Click Finish and then click Save to save directly to the master configuration.


    Create the WebSphere MQ input queue for request messages

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Queues | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK

    2. In General Properties, set...

      Name JRules Input Queue
      JNDI name jms/BRESQueueIn
      Queue name JRulesIn

    3. Type in the name of your queue manager or queue sharing group name, then click OK.

    4. Click Save to save directly to the master configuration.


    Create the WebSphere MQ output queue for sending a response message

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Queues | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK

    2. In General Properties, set...

      Name JRules Output Queue
      JNDI name jms/BRESQueueOut
      Queue name JRulesOut

    3. Type in the name of your queue manager or queue sharing group name, then click OK.

    4. Click Save to save directly to the master configuration.


    Create a topic connection factory

    After you have created the queue factory, input queue, and output queue, create a topic connection factory. To do so, set the scope to node or server, select the provider and JNDI name, enter the connection details, test the connection, and save.

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Topic connection factories | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK

    2. In "Step 1: Configure basic attributes" set...

      Option Description
      Name JRules Topic Connection Factory
      JNDI name jms/BRESTopicConnectionFactory

    3. In "Step 2: Select connection method", select Enter all the required information into this wizard and click Next.

    4. In "Step 2.1: Supply queue connection details", type the name of your queue manager or queue-sharing group, then click Next.

    5. In "Step 2.2: Enter connection details", type the connection details to establish a connection to the queue manager or queue sharing group (the default queue port is 1414), then click Next.

    6. In "Step 3: Test connection", click Test connection.

      If your message queue is running, you see the following message: A connection was successfully made to WebSphere MQ.

    7. Click Next. A summary opens showing the details of the connection factory.

    8. Click Finish, then click Save to save directly to the master configuration.


    Create the WebSphere MQ input topic

    After you have created the WebSphere MQ topic connection factory, you can create the JMS topic destination for receiving a request message. To do so, set the scope to node or server level, select the provider, set the JNDI and input topic names, and save.

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Topics | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK.

    2. In General Properties, set...

      Option Description
      Name JRules Input Topic
      JNDI name jms/BRESTopicIn
      Topic name JRulesTopicIn

    3. Click Save to save directly to the master configuration.


    Create the WebSphere MQ output topic

    After you have created the WebSphere MQ topic connection factory and input topic, also create the JMS queue destination for sending a response message. To do so, set the scope to node or server level, select the provider, set the JNDI and output topic names, and save.

    To create the JMS output topic:

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Topics | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK

    2. In General Properties, set...

      Name JRules Output Topic
      JNDI name jms/BRESTopicOut
      Topic name JRulesTopicOut

    3. Click Save to save directly to the master configuration.


    Create the WebSphere MQ queue activation specification

    After you have configured WebSphere MQ queues, we create the queue activation specification.

    The queue activation specification manages the relationship between the Decision Server message-driven rule beans (MDB) running in WAS and a destination in WebSphere MQ. To create the activation specification, set the scope to node or server level, select the provider, set the specification and JNDI names, enter the connection details, and save.

    To create the activation specification:

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Activation specifications | Scope (Node | Server) | New | WebSphere MQ messaging provider | OK

    2. In "Step 1: Configure basic attributes" set...

      Name JRules Activation Spec
      JNDI name eis/IlrRuleExecutionEJB

    3. In "Step 1.1: Specify MDB destination data", set the field Destination JNDI name to...

        jms/BRESQueueIn

      ...set the Destination type to Queue.

    4. In "Step 2: Select connection method", select...

        Enter all the required information into this wizard

    5. In "Step 2.1: Supply queue connection details", type the name of your queue manager or queue sharing group.

    6. In "Step 2.2: Enter connection details", type the connection details to establish a connection to the queue manager or queue sharing group.

      The default queue port is 1414.

    7. In Step 3: Test connection, click Test connection.

      If your message queue is running, you see the following message:

      A connection was successfully made to WebSphere MQ.

    8. Click Next.

      A summary opens showing the details of the connection factory.

    9. Click Finish, then click Save to save directly to the master configuration.


    Create the WebSphere MQ topic activation specification

    After you have created the queue activation specification, we create the topic activation specification.

    The topic activation specification manages the relationship between the Decision Server message-driven rule beans (MDB) running in WAS and a destination in WebSphere MQ. To create the activation specification, set the scope to node or server level, select the provider, set the specification and JNDI names, enter the connection details, and save.

    To create the topic activation specification:

    1. In the Integrated Solutions Console, open...

        Resources | JMS | Activation specifications | Scope (Node or Server) | New | WebSphere MQ messaging provider | OK

    2. In "Step 1: Configure basic attributes" set...

      Name JRules Topic Activation Spec
      JNDI name eis/IlrRuleExecutionTopicEJB

    3. In "Step 1.1: Specify MDB destination data" set the field Destination JNDI name to...

        jms/BRESTopicIn

      set the Destination type to Topic

    4. In "Step 1.2: Configure Durable Subscription", select Nondurable subscription

    5. In "Step 2: Select connection method", select Enter all the required information into this wizard

    6. In "Step 2.1: Supply queue connection details", type the name of your queue manager or queue sharing group, then click Next. The default queue port is 1414.

    7. In "Step 2.2: Enter connection details", type the connection details to establish a connection to the queue manager or queue sharing group, then click Next.

    8. In "Step 3: Test connection", click Test connection.

      If your message queue is running, you see the following message:

        A connection was successfully made to WebSphere MQ.

    9. Click Next.

      A summary opens showing the details of the connection factory.

    10. Click Finish, then click Save to save directly to the master configuration.


    Install the message-driven rule bean

    After you have created the queue and topic activation specifications, you install the Decision Server message-driven rule bean (MDB) in WAS as an enterprise application. To do so, we create a new enterprise application.

    To install the Decision Server message-driven rule bean:

    1. Open the Integrated Solutions Console.

    2. In the panel, open...

        Applications | New Application | New Enterprise Application | Local file system

      ...and browse to the following path:

        InstallDir/executionserver/applicationservers/WebSphere<version_number>/jrules-res-mdb-WAS<version_number>.jar.

    3. Click Next.

    4. Select the check box Detailed - Show all installation options and parameters.

    5. Expand Choose to generate default bindings and mappings and select the check box Generate Default Bindings.

    6. Click Next, then click Continue to accept the security warning.

    7. Click Step 5: Bind listeners for message-driven beans.

      1. Type jms/BRESTopicIn as the Destination JNDI name for IlrRuleExecutionTopicEJB.

      2. Type jms/BRESQueueIn as the Destination JNDI name for IlrRuleExecutionEJB.

      3. Click Next.

    8. Click "Step 6: Map resource references to resources"

      Use the default binding for the referenced resources.

      Step 7 provides a summary.

    9. Click Finish.

    10. When the installation has completed, click Save directly to the master configuration.

    11. In the Integrated Solutions Console, open Applications  > Application Types > WebSphere enterprise applications.

    12. In the Enterprise Applications page, select the check box next to jrules-res-mdb-WAS<version_number>.jar and click Start to start the application.


    Enabling server-wide Last Participant Support

    To complete the integration of WebSphere MQ, you enable Last Participant Support.

    To finish integrating WebSphere MQ in WAS for asynchronous execution, you enable Last Participant Support (LPS) so that a single one-phase commit resource is used with any number of two-phase commit resources in the same global transaction. To do so, set the ACCEPT_HEURISTIC_HAZARD custom property to true in the Integrated Solutions Console and then restart the application server.

    To enable server-wide LPS, go to...

      Servers | Server Types | WebSphere application servers | server name

    The properties page for the application server opens

  • Under Container Settings, expand Container Services and click Transaction Service.

    The properties page for the transaction service opens.

  • Under Additional Properties, click Custom properties.

  • On the Custom Properties page, click New and type ACCEPT_HEURISTIC_HAZARD as the Name and TRUE as the Value.

  • Click Apply and Save directly to the master configuration.

  • Restart the application server.


    Configure Rule Execution Server in different environments

    Configuration settings required to enable Rule Execution Server on different environments in a single cell.

    It is very likely that the development of your BRMS requires more than a single deployment of Rule Execution Server. The development lifecycle of a business rule application is similar to any other software development process, including stages for implementation, testing, deployment, and maintenance. At the very least, you are likely to need an environment for your development team, one for your QA team, and another one for in-production applications. In the cases where you configure Rule Execution Server in a single cell, it is good practice to isolate the rulesets that you use on each server, and ensure that the execution units (XUs) do not interfere with each other.

    These instructions assume that you do not configure multiple instances of Rule Execution Server in a single cell.

    To set up different environments in a single cell, follow these steps:

    1. Set up different data sources.
    2. Deploy and configure a XU for each environment.
    3. Deploy the Rule Execution Server console for each environment.

    To configure Rule Execution Server in different environments:

    1. Set up different data sources.

      Use a unique JNDI name. For example: jdbc/resdatasourceEnv1 and jdbc/resdatasourceEnv2.

    2. Deploy a XU for each environment and define a J2C connection factory.

      1. In the side panel, open...

          Resources | Resource Adapters | J2C connection factories | xu_cf

      2. Modify the JNDI name to...

          eis/XUConnectionFactoryEnv1

        Modify the execution components that call this XU so that they use this JNDI instead of the default.

      3. Under Additional Properties, click Custom properties.

      4. Click the plugins property.

      5. In the Value field, change xuName=default in the property to xuName=xuEnv1, and then click OK.

      6. Click the persistenceProperties property.

      7. In the Value field, change JNDI_NAME=jdbc/resdatasource to JNDI_NAME=jdbc/resdatasourceEnv1.

      8. Click OK and Save to save the changes to the master configuration.

      9. Repeat the same process for XUs in other environments.

    3. Deploy the Rule Execution Server console for each environment.

      1. To modify the deployment descriptor of the Rule Execution Server console EAR: in the web.xml file, uncomment the JMX_XU_QUERY_PART parameter and specify xuName=xuEnv1.

      2. Deploy the Rule Execution Server console EAR on the server in the resource reference settings in the application server.

        1. Set the JNDI for the data source to jdbc/resdatasourceEnv1.
        2. Set the JNDI name for the XU to eis/ConnectionFactoryEnv1.

      3. Repeat the process to deploy the Rule Execution Server console for the other environments.

    4. Restart the node agents after you complete the configuration
    5. Call the XU instances to register the XU with the Rule Execution Server console.


    Troubleshooting Rule Execution Server

    Various paths are available for you in case of poor performance: you activate the execution unit (XU) log to study the execution trace, configure the XU memory profiler, explore database driver issues, or allocate more memory to applications.

    • To let a scalable number of users access resources through the Java components, JCA assigns the task of implementing connection pooling to application server vendors.

    • If the diagnostics are performed before any execution units (XU) have been started, the test is passed and a message displays to report that no execution unit (XU) has been initialized.

    • On WAS, the pool size is not instantiated beforehand and therefore prevents the server diagnostics from validating a Rule Execution Server before the first execution of a rule engine. The diagnostics remain useful to validate a configuration, especially in a cluster, and to check which execution units registered with the management model have been started.

    For information on message strings, see Rule Execution Server messages.


    Set the Java logging level

    In the WAS administration console, you can activate the log for the execution unit (XU) and other execution artifacts.

    WAS supports the Java logging service to log the activity of the execution stack.

    You set the log properties from the WAS administration console.

    1. Activate the XU by executing a ruleset.

    2. Open the WAS administration console.

    3. Select Troubleshooting > Logs and trace > SampleServer > Diagnostic trace.

    4. Expand the list, click com.ibm.rules.res.execution, and select All Messages and Traces.

      Use the com.ibm.rules.res.execution logger only to log messages of level SEVERE or above.

      For example, com.ibm.rules.res.execution=all On the Configuration tab, the Change log detail levels panel shows that the execution logging process is set to all

    5. Save the configuration and restart the application server.

    With a default WAS installation, the log messages are saved to the trace.log file in the logging directory that is dedicated to the server. It is not necessary to modify any parameter of the XU connection factory.

    With a default WAS on z/OS installation, the log messages are saved to the SYSOUT and SYSPRINT job output elements in the Servant address space where rule execution takes place.


    Configure the XU memory profiler

    The XU memory profiler provides information about the memory usage of the execution unit (XU). The XU memory profiler is a Java™ Agent.

    1. Open the WAS administration console.

    2. Set the rulesetUsageMonitorEnabled XU property to true.

    3. Click...

        Servers | Server Types | WebSphere application servers | servername | Server Infrastructure | Java and Process Management | Process definition | Additional Properties | Java Virtual Machine

    4. Add the following line to the Generic JVM arguments parameters:

        -javaagent:InstallDir/executionserver/lib/jrules-res-memory-agentclient.jar


    What to do next

    After you have configured the XU memory profiler, you can use it to retrieve information about how the memory is used.


    Rule Execution Server database driver issues

    Lists the known database driver issues.


    JDBC not bound

    A JDBC not bound error message is raised when an error occurs during the creation of the data source.

    Refer to the traces to locate the original cause. In the vast majority of cases one of the following is likely:

    • A directory does not exist or cannot be read or written.
    • There is a missing schema or table.
    • There are missing privileges to access the database resource.


    Provide more memory for applications

    If you experience core dumps or Java™ out-of-memory errors, you can make more memory available to WAS by increasing the maximum heap size for the Java Virtual Machine (JVM).

    To increase the WAS memory settings, go to...

      Servers | Server Types | WebSphere application servers | server_name | Server Infrastructure | Java and Process Management | Process definition | Additional Properties | Java Virtual Machine

      ...and set...

        OS Initial heap size Maximum heap size
        32-bit 512 1024
        64-bit 1024 4096


      Verify the deployment and configuration

      It is good practice to verify that Rule Execution Server is successfully deployed and configured by running the diagnostics.

      • To let a scalable number of users access resources through the Java components, JCA assigns the task of implementing connection pooling to application server vendors.

      • If the diagnostics are performed before any execution units (XU) are started, the test is passed and a message reports that no Execution Unit (XU) are initialized.

      • On WAS, the pool size is not instantiated beforehand and therefore prevents the server diagnostics from validating a Rule Execution Server before the first execution of a rule engine. The diagnostics remain useful to validate a configuration, especially in a cluster, and to check which execution units are registered with the management model.

      1. Open the Rule Execution Server console...

          http://host:PORT/res

        If security is enabled, the prefix is https://.

        To find the value of PORT:

        1. In the Integrated Solutions Console, click Servers > Server types > Websphere application servers.

        2. Select the name of your server.

        3. Under Communications, click Ports.

      2. Sign in to the Rule Execution Server console.

      3. Click the Diagnostics tab.

      4. Click Run Diagnostics.

      You see a report listing the diagnostic tests. A check mark is shown next to each test to indicate whether the test is successful. Click Expand All to show more details about the tests.


      Configure Decision Server Events on WAS

      The following sections describe how to configure Decision Server Events after installation.

      You must have installed Decision Server Events and optionally Decision Center.

      The following components are available to you in Decision Server Events:

      Component Description Default installation
      Event Capture and Replay widgets In the Event Capture widget and the Event Replay widget, you capture events from a production system, and replay a sequence of one or more of them, typically on a test system. Yes
      Event Connectors Event connectors provide data connections between the event runtime and external systems. You can configure the event connectors in Event Designer. Yes
      Event Designer A development environment based on Eclipse to design, develop, test, deploy, and monitor event applications. Event Designer is available from the Event perspective in Eclipse. Yes
      Event Runtime The event runtime is an execution platform that manages real-time business event coordination. The event runtime requires WebSphere eXtreme Scale and can be deployed and configured on WAS. Yes
      Event Tester widget The Event Tester Widget provides a way to test the event logic in a business process. This widget is aimed at testing and is used only on a test installation. Do not use it on a production installation as it might affect the performance. Yes
      Integration Components You can install integration components into the tooling of WebSphere ESB and WebSphere Message Broker to allow these products to send and receive data from Decision Server Events. No
      Samples and Tutorials Installs the projects for the samples and tutorials, and provides a server profile to run the samples and tutorials on WAS. Yes

      If you install Decision Center, the following chart widgets are also available...

        Event Chart Manager Create and edit charts. Event Chart View charts. Chart data is periodically refreshed to present a real-time view of system activities. Event Layout View legacy layouts.

      One of the key concepts in the following sections is the WAS profile, which you use for planning and configuring your Decision Server Events environment. A profile defines the runtime environment and includes all the files that the server processes in the runtime environment and that you can change. Because we create a profile, you also create an event runtime. Decision Server Events supports three types of profile:

      • Application server profile: An application server profile defines a separate stand-alone WAS application server that has its own administrative interface and enables you to make applications available to external websites or intranet websites, depending on the applications and server configurations. This profile is ideal for single server environments. For this type of profile, you can:

      • Management profile: A management profile creates a deployment manager, which is a server that manages operations for a logical group of other servers and is the central location for administering the servers and clusters in the cell. If you are setting up a network deployment environment, create this profile first. For this type of profile, you can augment only an existing WAS management profile with Decision Server Events.

      • Custom profile: A custom profile provides an empty node that does not contain an administrative console or servers. The typical use for a custom profile is to federate its node to a deployment manager. After federating the node, you can use the deployment manager to create a server or a cluster of servers within the node. For this type of profile, you can augment only an existing WAS custom profile with Decision Server Events.


      Plan your Decision Server Events environment

      There are a number of factors that you might want to consider when you decide how to configure your Decision Server Events environment. For example, decide whether to configure a stand-alone or clustered Decision Server Events environment.


      Create a Decision Server Events environment

      To create a Decision Server Events environment, you can either create your own profile or you can use the sample server provided. The sample server provides a preconfigured single server Decision Server Events environment by using embedded Apache Derby as the database provider and WAS default messaging as the messaging provider.

      In the following procedure, we create your own profile without using the preconfigured sample server.

      1. Install Decision Server Events.

      2. Create a WAS profile augmented with Decision Server Events.

      3. Follow Accessing event widgets to access the widgets.

      4. Perform any additional customization to the event runtime environment.

      You have a running Decision Server Events environment.

      To verify that your environment has been configured correctly, see Verify your Decision Server Events configuration.


      Choose a Decision Server Events topology

      You can configure Decision Server Events in single-server or clustered environment using the corresponding topology, depending on your requirements.

      • Configure a single server environment

        For simplicity and ease of deployment, you might want to configure a single server Decision Server Events environment. This topology is the simplest topology to configure and manage, but it is not highly available or scalable.

      • Configure a clustered environment

        To configure a highly available and scalable Decision Server Events environment, cluster the event runtime.

        Depending on whether you want to use WAS default messaging as your messaging provider or WebSphere MQ as the messaging provider, you can select from the following two topologies:

        • Gold Topology

          A gold topology cluster provides high availability and scalability for the event runtime, so that the topology can be configured to be resistant to server failure. Adding more servers to the cluster can improve event throughput in the event runtime, because workload is distributed between multiple cluster members.

          If the server fails, workload is redistributed to another cluster member and processing continues without any outage. The cluster uses WAS default messaging as the messaging provider for the event runtime.

        • A topology that uses WebSphere MQ as the messaging provider:

          You can cluster Decision Server Events to provide high availability and scalability for the event runtime, but by using WebSphere MQ as the messaging provider instead of by using WAS default messaging as the messaging provider.


      Customize the event runtime


      Configure a stand-alone Decision Server Events environment

      For simplicity and ease of deployment, you can configure a single server Decision Server Events environment. This topology is the simplest topology to configure and manage, but it is not highly available or scalable.


      Create a new Decision Server Events application server profile

      To create a new stand-alone Decision Server Events environment, first create a ODM Decision Server Events profile.

      During profile creation, you are asked to select the database manager which hosts the tables for the event runtime. Unless you are using Apache Derby, create this database before starting profile creation.


      Create a new profile using the Profile Management Tool

      To invoke the Profile Management Tool directly:

      • On Windows only, click...

          Start | All Programs | IBM WebSphere | IBM WebSphere Application Server | | Tools | Profile Management Tool

      • On multiplatforms, switch to...

          cd WAS_HOME/bin/ProfileManagement
          ./pmt.sh.

      To create a new application server profile augmented with ODM Decision Server Events:

      1. On the Profiles page, click Create.

      2. On the Environment Selection page, under IBM ODM, select Application server profile augmented with IBM ODM Decision Server Events.

      3. On the Profile Creation Options page, you can select one of the following options:

        • Typical profile creation: Create a profile with default WAS configuration settings.

        • Advanced profile creation

          Specify your own values or take default settings.

      4. On the Installation Location page, enter or browse for the fully-qualified location where Decision Server Events is installed or accept the default location if correct.

      5. On the Administrative Security page, select whether to enable security on WAS. If you do enable security, both administrative and application security for WAS is turned on. Supply a new user ID and password of your choice, and enter the password a second time to confirm it.

      6. On the Database Configuration page,

        1. Select a database manager from the list and specify the appropriate connection details. This database manager hosts the tables for the event runtime.

          If you select embedded Apache Derby, the repository database is created for you. In all other cases, have already created the database for the repository.

        2. If you did not select the embedded Apache Derby database, provide connection details including the fully-qualified location and name of the JDBC driver JAR file for your chosen database manager. Enter the following details for the database server:

          Database name Database hosting the Decision Server Events event runtime tables.
          Database server host name or IP address Computer hosting database server. Default is localhost.
          Database TCP/IP service port or listener port Connection port number for the database manager.
          Fully-qualified location and name of the JDBC driver file Enter the file name and location.
          User name Used by Decision Server Events to connect to the database server. This user name must have administrative privileges.
          Password Associated with the user name.

        3. If you did not select the embedded Apache Derby database, click Test Connection to validate the connection to the database. Ensure that the connection is successful before proceeding with profile creation.

      7. On the Messaging Provider Configuration page, select one of:

          WAS default messaging use default messaging provider embedded in WAS as the JMS provider.
          WebSphere MQ JMS messaging WebSphere MQ as the JMS provider.
          Do not configure a messaging provider No messaging provider is configured during profile creation. Configure JMS provider before starting Decision Server Events.

        After profile creation has completed, you can change JMS providers, or configure the JMS provider of your choice, but configure a single JMS provider before starting Decision Server Events.

        To use, or to switch to, WAS default messaging as the JMS provider, see configure WAS default messaging to be the JMS provider

        To use, or to switch to, WebSphere MQ as the JMS provider, see configure WebSphere MQ to be the JMS provider

      8. On the Profile Creation Summary page, review the information and click Create to create the new profile.

      A new application server profile augmented with ODM Decision Server Events is created.


      Create a new profile using manageprofiles.sh

      1. Run...

          cd was_install_dir/bin
          ./manageprofiles.sh

        Provide the following parameters:

        -create To create the new profile.
        -templatePath /path/to/template Location of the profile template. Provide a value for the application server profile of...

          was_install_dir/profileTemplates/wbe/default

        -wbeHome /path/to/install Installation location for Decision Server Events. Specify if you have installed Decision Server Events in a nondefault location.
        -profileName profile_name Name of the profile.
        -cellName cell_name Name of the cell that is created.
        -nodeName node_name Name of the node that is created.
        -hostName host_name Computer hosting the profile.
        -serverName server_name Server name that is created.
        -enableAdminSecurity true|false Default is false. If true, also provide -adminUserName and -adminPassword.
        -adminUserName username Required if enableAdminSecurity is enabled.
        -adminPassword password Required if enableAdminSecurity is enabled.
        -wbeDbType database_type

        • Derby_Embedded: the default for the application server profile
        • DB2_Universal
        • Derby_NetworkServer
        • Oracle
        • MS_SQL_Server

        -wbeDbName database_name Required unless -wbeDbType is Derby_Embedded.
        -wbeDbUserId database_user_name Required unless -wbeDbType is Derby_Embedded.
        -wbeDbPassword password Password for the user ID used to access the database server. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbJDBCClasspath /path/to/JDBC_class_files Path to the JDBC class path files. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbHostName host_name Host name for the database server. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbServerPort port_number DB listener port. Required unless -wbeDbType is Derby_Embedded.
        -wbeMsgingType messaging_type JMS provider to be configured.

        Default_Messaging Decision Server Events is configured to use WAS default messaging . This value is the default value.
        MQ_JMS_Messaging Decision Server Events is configured to useWebSphere MQ
        No_Messaging No JMS provider is configured.

        See:

        -wbeMqMsgingQmgrName queue_manager_name WebSphere MQ queue manager name. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingQmgrHostName host_name Host name of the WebSphere MQ queue manager. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingQmgrPort port_number MQ queue manager listener port. Required if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingTransType transport_type WebSphere MQ client transport type, either BINDINGS or CLIENT. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -enableTester true|false Default is false. Setting true installs the Event Tester runtime. Only applicable for the application server profile. Cannot be used in a production environment.
        -disableBusSecurity This parameter disables bus security for the service integration bus, WbeBus, when the bus is created.

      The profile is now created.


      Examples

      Create a new application server profile using embedded Apache Derby as the database provider, and WAS default messaging as the messaging provider.

        manageprofiles.sh -create -templatePath "ODM_HOME/WAS/profileTemplates/wbe/default"


      Augment an existing WAS application server profile with Decision Server Events

      To create a new stand-alone Decision Server Events environment from an existing WAS stand-alone environment, you can augment a WAS application server profile with ODM Decision Server Events. You can augment a profile using the Profile Management Tool or using manageprofiles.sh.

      Before you augment an WAS application server profile, ensure that all application servers in the profile are stopped.

      During the profile creation task, you are prompted to select the database manager that hosts the tables for the event runtime. Unless you are using Apache Derby, create this database before starting to create the profile.

      After augmenting, review profile security configuration. If administrative security is enabled, application security must also be enabled.


      Augment an existing application server profile using the Profile Management Tool

      To invoke the Profile Management Tool directly:

      • On Windows only, click...

          Start | All Programs | IBM WebSphere | IBM WebSphere Application Server V8.5 | Tools | Profile Management Tool

      • On multiplatforms, switch to...

          <WAS_HOME>/bin/ProfileManagement
          ./pmt.sh

      To augment an existing application server profile with ODM Decision Server Events:

      1. On the Profiles page, select an existing application server profile and click Augment.

      2. On the Augment Selection page, select Application server profile augmented with IBM ODM Decision Server Events.

      3. On the Installation Location page, enter or browse for the fully-qualified location where Decision Server Events is installed or accept the default location if correct.

      4. On the Database Configuration page,

        1. Select a database manager from the list and specify the appropriate connection details. This database manager hosts the tables for the event runtime.

          If you select embedded Apache Derby, the repository database is created for you. In all other cases, have already created the database for the repository.

        2. If you did not select embedded Apache Derby, provide connection details including the fully-qualified location and name of the JDBC driver JAR file for your chosen database manager. Enter the following details for the database server:

          • Database name: The name of the database that hosts the Decision Server Events event runtime tables.

          • Database server host name or IP address: The name of the computer where the database server is located. The default is localhost.

          • Database TCP/IP service port or listener port: The connection port number for the database manager.

          • Fully-qualified location and name of the JDBC driver file: Enter the file name and location.

          • User name: The user name used by Decision Server Events to connect to the database server. This user name must have administrative privileges.

          • Password: The password associated with the user name. Confirm the password.

        3. If you did not select the embedded Apache Derby database, click Test Connection to validate the connection to the database. Ensure that the connection is successful before proceeding with profile creation.

      5. On the Messaging Provider Configuration page, select one of:

        • WAS default messaging. Decision Server Events is configured to use the default messaging provider that is embedded in WAS as the JMS provider.

        • WebSphere MQ JMS messaging. Supply the WebSphere MQ related information and Decision Server Events is configured to use WebSphere MQ as the JMS provider.

        • Do not configure a messaging provider. No messaging provider is configured during profile creation. You must configure a single JMS provider before starting Decision Server Events.

        After profile augmentation has completed, you can change JMS providers, or configure the JMS provider of your choice, but configure a single JMS provider before starting Decision Server Events.

        To use, or to switch to, WAS default messaging as the JMS provider, see configure WAS default messaging to be the JMS provider

        To use, or to switch to, WebSphere MQ as the JMS provider, see configure WebSphere MQ to be the JMS provider

      6. If WAS administrative security is turned on in the profile, the Security Configuration page is displayed. Enter the user ID and password for the application server

      7. On the Profile Augmentation Summary page, review the information and click Augment to augment the profile.

      The existing application server profile is augmented with ODM Decision Server Events.


      What to do next

      If administrative security is enabled for the profile, also enable application security for the profile.


      Augment an existing application server profile using manageprofiles.sh

      1. cd was_install_dir/bin

      2. manageprofiles.sh

        Provide the following parameters:

        -augment Augment the existing profile.
        -templatePath /path/to/template Location of the profile template...

          was_install_dir/profileTemplates/wbe/default

        -profileName profile_name Existing application server profile to augment.
        -wbeHome /path/to/install Installation location for Decision Server Events. Specify if you have installed Decision Server Events in a nondefault location.
        -hostName host_name Computer hosting the profile.
        -adminUserName username Required if WAS administrative security is turned on.
        -adminPassword password Required if WAS administrative security is turned on.
        -wbeDbType database_type

        • Derby_Embedded: the default for the application server profile
        • DB2_Universal
        • Derby_NetworkServer
        • Oracle
        • MS_SQL_Server

        -wbeDbName database_name Required unless -wbeDbType is Derby_Embedded.
        -wbeDbUserId database_user_name Required unless -wbeDbType is Derby_Embedded.
        -wbeDbPassword password Password for the user ID used to access the database server. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbJDBCClasspath /path/to/JDBC_class_files Path to the JDBC class path files. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbHostName host_name Host name for the database server. Required unless -wbeDbType is Derby_Embedded.
        -wbeDbServerPort port_number DB listener port. Required unless -wbeDbType is Derby_Embedded.
        -wbeMsgingType messaging_type JMS provider to be configured. Valid values are:

        Default_Messaging Decision Server Events is configured to use WAS default messaging . This value is the default value.
        MQ_JMS_Messaging Decision Server Events is configured to useWebSphere MQ
        No_Messaging No JMS provider is configured. Before executing Decision Server Events, but configure a JMS provider manually.

        See:

        -wbeMqMsgingQmgrName queue_manager_name WebSphere MQ queue manager name. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingQmgrHostName host_name Host name of the WebSphere MQ queue manager. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingQmgrPort port_number MQ queue manager listener port. Required if -wbeMsgingType is MQ_JMS_Messaging.
        -wbeMqMsgingTransType transport_type WebSphere MQ client transport type, either BINDINGS or CLIENT. Required only if -wbeMsgingType is MQ_JMS_Messaging.
        -enableTester true|false Default is false. Setting true installs the Event Tester runtime. Only applicable for the application server profile. Cannot be used in a production environment.
        -disableBusSecurity This parameter disables bus security for the service integration bus, WbeBus, when the bus is created.


      Examples

      Augment an existing application server profile called AppSrv01 using embedded Apache Derby as the database provider, and WAS default messaging as the messaging provider.

      manageprofiles.sh -augment
                        -templatePath "ODM_HOME/WAS/profileTemplates/wbe/default"
                        -profileName AppSrv01

      If administrative security is enabled for the profile, also enable application security for the profile.


      Unaugment an existing application server profile

      1. Run...

          cd was_install_dir/bin
          ./manageprofiles.sh

        ...and provide the following parameters:

        -unaugment Unaugment the existing profile.
        -templatePath /path/to/template Location of the profile template...

          was_install_dir/profileTemplates/wbe/default

        -profileName profile_name Existing application server profile to unaugment.

      Decision Server Events features are removed from the profile.


      Examples

      Unaugment existing Decision Server Events from profile named WODMSrv01...

      manageprofiles.sh -unaugment 
                        -templatePath "ODM_HOME/WAS/profileTemplates/wbe/default"
                        -profileName WODMSrv01


      Customize the event runtime environment

      Before starting the event runtime for the first time, you might want to make configuration changes to some of the components in the runtime environment.


      Configure event runtime database for Decision Server Events

      The event runtime requires the use of a database. There are various configuration tasks that you might need to do to the database, depending on your environment.


      Create the event runtime database

      Decision Server Events requires a database for the event runtime. This event runtime is the shared, secured location that contains assets such as data connections, business objects, events, and actions.

      To use the Apache Derby database that is embedded in WAS as the event runtime database, the database (called event runtime) and tables are created and configured for you during the installation process. To use another supported database manager (including another installation of Apache Derby), create the event runtime database before you start the installer.

      Apache Derby is not supported in a production environment.

      To use a remote DB2 database as the database for the event runtime, install the supplied DB2 Client Support.

      1. Start the DB2 installer wizard.
      2. Select Custom Installation
      3. Select the Client support feature and clear all the other features.
      4. Complete the installation.

      The full list of supported database managers is available on the web at System requirements.

      When we create the event runtime database, record the following information:

      • Event runtime database name of your choice
      • Host name of the server where the database is located
      • Port used to access the database
      • Database user ID to be used to access the database
      • Password associated with the database user ID

      This information is used when configuring the event runtime database.

      • To install, have full administrative privileges for the event runtime database. For example, for DB2, be authorized to CONNECT, CREATETAB, and so on. For Oracle have authority to ALTER DATABASE, CREATE ANY TABLE, and so on. These full administrative privileges are only required to install Decision Server Events, not to use it. If you do not have full administrative privileges, you can still install if your Database Administrator (DBA) creates the event runtime tables in the database using the manual instructions before you run the installer. After installation, you only need read, write, and delete access as a user.

      • For all database managers except embedded Apache Derby: the database manager must be running before the installation starts and have available the JDBC .jar file for the database manager.


      Manually creating event runtime tables

      You can opt to tailor existing scripts and create the event runtime tables yourself, as a manual task. If you do not create these tables, they are automatically created for you during the startup of Decision Server Events.

      Before we create the event runtime tables, ensure that you have created the event runtime database.

      Decision Server Events supplies a copy of the scripts used to create the event runtime tables, in the InstallDir/config/db directory. The scripts are database dependant, one script for each supported database:

        DB2 db2.sql
        Apache Derby derbydb.sql
        Oracle ora.sql
        Microsoft SQL Server mssql2k.sql

      Take a copy of the appropriate script, tailor it to meet your requirements, and use it to create the tables.

      You must take a copy of the script and execute it manually. Even if you edit and save the script that is in the InstallDir/config/db directory, it is not used to create the event runtime tables.


      Deploy tables in separate databases

      By default, the event runtime tables are created in a single database, but you can deploy sets of tables in separate databases. The event runtime database stores assets (such as data connections, business objects, events, actions, and event rules) that are used by the event runtime to receive events and initiate the actions based on event rule groups.

      The event runtime consists of several sets of tables and a number of views, which can be used to report on history. They are built by running a database manager-specific script. At installation time, you specify a single database and by default, all tables, and views are located in that database. The tables are created in this database at installation time.

      To deploy sets of tables in separate databases and reference those databases:

      1. Create a database to hold the tables.

      2. Use the appropriate CREATE statements with the SQL tool for your database manager and create the tables.

        The table shows the SQL statements to create separate databases. Only partial statements are shown.

        If you are using history, always ensure that the history and asset definition tables, and the resources, are created and used in the same database.

        SQL statements to create each table.

        Table name SQL statement
        Asset definitions (maestro_asset, properties) CREATE TABLE maestro_asset
        ALTER TABLE maestro_asset
        CREATE TABLE properties
        CREATE TABLE labels
        ALTER TABLE labels
        Time delays CREATE TABLE time_based_asset
        CREATE INDEX FIRETIME_IDX
        Event Flows CREATE TABLE steps
        CREATE CLUSTERED INDEX STREAM_IDX
        CREATE TABLE csio_entry
        CREATE INDEX csio_entry_idx on csio_entry
        CREATE INDEX csio_entry_times
        User Console CREATE TABLE actions
        ALTER TABLE actions
        CREATE TABLE actions_prefs
        ALTER TABLE actions_prefs
        CREATE TABLE auth_users
        CREATE TABLE auth_groups
        History CREATE TABLE history_event
        CREATE INDEX history_e_idx
        CREATE TABLE history_action
        CREATE INDEX history_a_idx
        CREATE TABLE history_ent_obj
        CREATE INDEX history_eo_idx
        CREATE TABLE history_ent_obj_values
        CREATE INDEX history_eo_v_idx
        CREATE TABLE history_filter
        CREATE TABLE history_rule
        CREATE INDEX history_rule_idx
        CREATE TABLE history_watch_time
        CREATE VIEW as_director_events
        CREATE VIEW as_director_actions
        CREATE VIEW as_director_ent_objs
        CREATE VIEW as_director_ent_objs_values
        CREATE VIEW as_director_filters
        CREATE VIEW as_director_rules
        CREATE VIEW as_director_watch_times

      3. Create a new datasource by using WAS administrative console:

        1. Click...

            JDBC | Data sources

        2. Ensure that the scope is the same as the event runtime datasource and click New.

        3. Enter a name in the Datasource Name field, for example...

            Event Runtime History Datasource

        4. Enter a name in the JNDI Name field, for example...

            jdbc/wbe/history

        5. Click Select an existing JDBC provider and select Event Runtime JDBC Provider.

        6. Enter the database-specific properties that point to the database where the tables were created in step 2.

        7. Select an authentication alias, or create a new one with credentials for the database, then click Finish.

      4. Set the following properties to the value that you specified in JNDI Name, depending on which tables you have moved:

        Table name Property
        Asset definitions as.director.common.db.asset.instance
        Time delays as.director.common.db.timebased.instance
        Event Flows as.director.common.db.eventflow.instance
        User Console as.director.connectors.pem.instance
        History as.director.common.db.history.instance


      Deploy the event runtime in a case-sensitive database manager

      If you are using a case-sensitive database manager, event runtime table names must be changed to be all in uppercase. If the event runtime database is created in a case-sensitive database, references to table names that are defined as properties must be changed to be all in uppercase.

    • Change the value of the as.director.common.db.asset.table property from maestro_asset (all lowercase) to MAESTRO_ASSET (all uppercase).

      If you are using Properties, the properties are in the Asset Event Runtime subsection of the Common section.

    • Change the value of the as.director.common.db.timebased.table property from time_based_asset (all lowercase) to TIME_BASED_ASSET (all uppercase).

      If you are using Properties, the properties are in the Server section, in the Timebased Event Runtime Settings subsection.

      The changes are applied the next time the wberuntimeear application is restarted.


      Edit the setenv files

      You must edit the setenv files as part of the configuration steps to complete the installation.

      The setenv.sh script files are located in subdirectories of the component_dir/config directory

      When you install a product fix pack after editing the setenv files, the setenv files are overwritten. To keep your changes, create backups of the files before installing the fix pack.

      1. Edit...

          component_dir/config/was/setenv

        ...and add the appropriate values for the WAS instance on which ODM is going to run.

      2. Edit... component_dir/config/db/setenv file

    ...and add the appropriate values for the DB2 instance that is going to host the event runtime.

  • Edit...

      component_dir/config/wbe/setenv file

    ...and update the WBE_INSTALL property so that it points to the ODM product installation in the read-only file system. For example:

      WBE_INSTALL=InstallDir


    Change the event runtime messaging provider

    If you have configured the event runtime to use one messaging provider but you want to change to another messaging provider, or if you chose not to configure a messaging provider when creating or augmenting your Decision Server Events profile, do some additional configuration.


    Configure WAS default messaging to be the JMS provider

    To use WAS default messaging as the JMS provider for the event runtime, and you either did not select the JMS provider or you selected WebSphere MQ when we created or augmented the Decision Server Events profile, do some additional configuration of WAS and Decision Server Events.

    The event runtime can be configured to work with only one JMS provider: either the WAS default messaging or WebSphere MQ, but not both.

    1. Confirm settings in setenv

    2. If, when we created or augmented the Decision Server Events profile, you chose to use WebSphere MQ, but now you want to use WAS default messaging as the JMS provider instead, remove the configuration...

        cd InstallDir/config/was/
        ./configure_MQ_JMS_Messaging.sh -undo

      If when creating or augmenting the Decision Server Events profile, you did not select the JMS provider, you do not need to do this step.

    3. Complete configuration of WAS default messaging as the JMS provider...

        cd InstallDir/config/was/
        ./configure_bus.sh

      The configure_bus.sh script configures the service integration bus, WbeBus. If application server administrative security is enabled, the bus is secured. To disable bus security, supply the optional argument, -disableBusSecurity.

      To connect to the secured bus...

    4. Restart WAS.


    Configure WebSphere MQ to be the JMS provider

    To use WebSphere MQ as the JMS provider for the event runtime, and you either did not select the JMS provider or you selected WAS default messaging when we created or augmented the Decision Server Events profile, do some additional configuration of WebSphere MQ, WAS, and Decision Server Events.

    The event runtime can be configured to work with only one JMS provider: either the WAS default messaging or WebSphere MQ, but not both.

    You must have the WebSphere MQ client installed on the same computer as Decision Server Events.


    Configure WebSphere MQ

    The WebSphere MQ administrator must do the following tasks:

    1. Create the queue manager, using the crtmqm command.

    2. Start the queue manager, using the strmqm command.

    3. If you are using WebSphere MQ V7.1, publish/subscribe must be enabled. Use the ALTER QMGR command for this queue manager.

    4. Create the queues required, by running:

        runmqsc queue-manager-name < mq-install-dir\java\bin\MQJMS_PSQ.mqsc

      ...where mq-install-dir is the installation location of WebSphere MQ.

    5. If you are configuring a cluster, create the extra queues required, by running:

        runmqsc queue-manager-name <InstallDir\config\was\create_MQ_JMS_MQ_queues.mqsc

      where InstallDir is the installation location of Decision Server Events.


    Configure Decision Server Events to use WebSphere MQ as the JMS provider

    1. Determine...

      • queue manager name
      • WebSphere MQ host name and port
      • client transport type

    2. Confirm settings in setenv

    3. If, when creating or augmenting the Decision Server Events profile, you chose to use WAS default messaging, but now you want to use WebSphere MQ as the JMS provider instead, to remove the messaging configuration:

        cd InstallDir/config/was/
        ./configure_messaging.sh -undo

      If, when we created or augmented the Decision Server Events profile, you did not select the JMS provider, you do not need to do this step.

    4. Configure Decision Server Events and WAS:

      cd InstallDir/config/was 
      ./configure_MQ_JMS_messaging –q queue-manager-name
                                [–p  queue-manager-port] 
                                [–h queue-manager-host] 
                                [-s scope]
                                [-t transport] 
                                [-c channel-name]  
      

      ...where...

        queue-manager-name WebSphere MQ queue manager created when configuring installation of WebSphere MQ
        queue-manager-port Queue manager listener port. Default is 1414
        queue-manager-host Computer hosting queue manager
        scope Valid WAS scope
        transport BINDINGS or CLIENT
        channel-name Name of the server connection channel

      For example:

        ./configure_MQ_JMS_messaging –q QM_PSG \
                                     –p 1415 –h localhost 
        

      The script creates the following objects in WAS:

        Connection factories JNDI name
        Queue connection factory jms/WbeQueueConnectionFactory
        Topic connection factory jms/WbeTopicConnectionFactory
        Connection factory jms/WbeConnectionFactory

      Topics.

      Topics JNDI name
      Action topic jms/actionTopic
      Command topic jms/commandTopic
      CbeListener topic jms/WBE/CbeListener
      Durable action topic jms/durableActionTopic
      Durable event topic jms/durableEventDestination
      Event topic jms/eventDestination
      History topic jms/historyModuleDestination

      Activation specifications.

      Activation specification name JNDI name
      wbe_events jca/wbe_events
      wbe_events_durable jca/wbe_events_durable
      wbe_history jca/wbe_history
      wbe_reset_watch jca/wbe_reset_watch
      wbe_ute_receive jca/wbe_ute_receive

    5. Ensure that the names of these objects are consistent with the corresponding properties.

      If you are using Properties, these properties are in the JMS Server Settings and the Topics subsections of the JMS section.

    6. Restart WAS to apply the changes.

    Decision Server Events is now configured to use WebSphere MQ as the JMS messaging provider.


    What to do next

    Make sure that the queue names created by create_MQ_JMS_MQ_queues.mqsc are consistent with the queue names that are specified by your WebSphere MQ JMS event destination, durable event destination, and history module destination queue definitions. These queue definitions can be found in the WAS administrative console under...

      Resources | JMS | Queues

    Although the names of these resources reference topics, these resources are actually queues for clusters.

    By default, the WebSphere MQ queues are called:

    • eventQueue for the event destination
    • durableEventQueue for the durable event destination
    • historyModuleQueue for the history module destination


    Set properties

    Configuration properties for the event runtime are stored in WAS. You might want to change properties because they determine the configurable behaviour of Decision Server Events. There are three ways to set event runtime properties.

    Use different tasks depending on the platform that you are using.

    Method by platform.

    Method Platforms
    Configure properties using the WAS administrative console Multiplatforms and z/OS
    Configure properties using the wsadmin scripting tool Multiplatforms and z/OS
    Configure properties using the Properties tool Multiplatforms only


    Configure properties using the WAS administrative console

    When you configure event runtime properties (for example, if you move the event runtime to a different database manager, or you want to change to a different JMS messaging provider), you can make the changes in WAS administrative console. When you edit the value of a property, ensure that the value is appropriate and spelled correctly because it is not validated.

    1. Start the WAS administrative console.

    2. Log in to the WAS administrative console. If authentication is enabled, use a valid user ID and password. If authentication is not enabled, type any user ID and log in.

    3. In the navigation tree of the WAS administrative console, click Resources > Resource Environment > Resource environment entries.

    4. On the Resource environment entries page, click WbeSrv01 to open the Configuration page. The general properties for that entry are displayed.

    5. On the Configuration page, click Custom properties. The properties are listed.

    6. Modify the properties as required.

      If the property name is prefixed by ! (for example !as.director.common.authentication.server), the property is disabled. Edit the name field to remove the "!", then set the remaining fields.

    7. Save your changes.

    8. Restart the event runtime to apply your changes.

    When the event runtime restarts, the changes you made to the properties are applied.


    Configure properties using the wsadmin scripting tool

    When you configure event runtime properties (for example, if you move the event runtime to a different database manager, or you want to change to a different JMS messaging provider), you can make the changes using the WAS administrative scripting tool, wsadmin. You can modify the properties by using wsadmin, or you can use the supplied AdminTask object to set a single property.

    To modify multiple properties, use the wsadmin tool. To modify a single property, use the AdminTask object as follows:

    1. Start wsadmin.

    2. Run the following command to set a single property:

      • Jacl:

          wsadmin $AdminTask wbeSetProperty {-jndiName com/ibm/wbe/wbeProperties01 -propertyName propertyName -propertyValue propertyValue}

      • Jython:

          wsadmin -lang jython AdminTask.wbeSetProperty('[-jndiName com/ibm/wbe/wbeProperties01 -propertyName propertyName -propertyValue propertyValue]')

      Where propertyName is the name of the property you want to change, and propertyValue is the value that you want to set for that property.

    3. Save your changes:

      • Jacl:

          $AdminConfig save

      • Jython:

          AdminConfig.save()

    4. Restart the event runtime to apply your changes.

    When the event runtime restarts, the changes you made to the properties are applied.


    Configure properties using the Properties tool

    Settings for system properties are stored in an encrypted properties file. The file is managed through the use of the Properties tool or the WAS administrative console. When using the Properties tool, properties are displayed by folder, and most folders contain subsections that consist of groups of related properties.

    During installation, a base properties file is installed and configured to reference the event runtime database and JMS provider. Use the Properties tool to change property settings to accommodate your environment and preferences for system operation. There is no validation of the property that you have set. By default, a field holding a property values has a length of 64 characters. When you reach the limit, press ENTER and click to the end of the field to reset the focus. Properties then gives you up to five lines of 72 characters (by repeatedly pressing ENTER). Therefore, the maximum usable length is 360 characters.

    Properties provides two entry modes:

    • The Configurator wizard, which is the default entry mode, presents a series of screens containing only those properties you are most likely to want to edit.

    • The Full Configurator presents all properties and is appropriate for more customized installations. You can also add custom properties to describe certain environment-specific conditions

    Newly-configured property settings do not become operational until the next time you start the wberuntimeear application. You can make additional changes to property settings as required. Apply those changes by stopping this application and restarting it.

    1. Start Properties by invoking the properties script

      propertiesui.sh [-conntype SOAP [-host host_name] [-port port_number] | RMI [-host host_name] [-port port_number] | NONE] 
                      [-jndiName jndi_name]
      

      Where conntype specifies the type of connection to be used, the default value being "SOAP"

      A conntype of "NONE" means that no server connection is made and certain operations are performed in local mode

      host specifies the name of the host used for the SOAP or RMI connection, the default value being "localhost"

      port is the number of the port used for the SOAP or RMI connection

      jndiName is the JNDI name that is in the entry for event runtime properties, as shown under the Resource environment entries section of the WAS administrative console.

    2. Enter a user ID and password:

      • If security is enabled on WAS, enter a valid user ID and password.

      • If the user specified is not an Administrator, the user must have one of the following security roles:

        • adminsecuritymanager
        • deployer
        • configurator

      • If security is disabled on WAS, you can enter a user ID of your choice or leave the field blank. A password is not required.

    3. Modify the existing properties as required.

    4. To add a custom property:

      1. Select Full Configurator

      2. Click Edit > Add a Custom Property

      3. Click A new property and change it to the name of the custom property.

      4. Click value? and enter the value of the custom property.

      5. To remove a custom property, right-click the property name and click Delete Custom Property. The property is deleted without confirmation.

    5. Click File > Save Properties to save your changes.

    6. Restart the event runtime to apply your changes.

    When the event runtime restarts, the changes you made to the properties are applied.


    Configure event runtime to record history

    To record history, configure the event runtime to record history. Otherwise, you cannot monitor events, actions, filters, or data in real time through user-defined charts, nor can you run reports or use track events. Recording history preserves the delivery of real-time history records across system restarts. You can set the event runtime history to be persistent, or non-persistent. By default, the history is non-persistent. Non-persistent history messages that are currently being processed but have not yet been written to the history database might be lost when the event runtime restarts. To ensure that all history data is preserved when the event runtime is restarted, enable persistent history by setting history properties.

    You must configure the event runtime to record history if you are planning to:

    • Use the event widgets to monitor events, actions, filters, and data in real time, either using the Event Tester widget or through visualization of user-defined charts.

    • Run reports from Administration.

    • Use track events to count the number of events or keep running totals for thresholds and alerts.

    History is stored in a set of history tables that were created when you installed Decision Server Events.

    If you enable persistent history, there is a significant performance impact.

    1. Edit the following properties:

      as.director.server.history.enableModule Determines whether the history module is loaded when the event runtime starts. Ensure that the property value is set to true.
      as.director.server.history.enableRecording Determines whether history is recorded in the history tables. Set the property value to true to record history. Set this value to false to stop recording history.
      as.director.server.history.useJMS Determines whether history messages that are being processed but have not been written to the history database are non-persistent or persistent. Set this value to true to ensure that all history data is preserved when the event runtime is restarted. Setting this property to true has a significant impact on performance.
      as.director.bet.install Set the value to true if the Event Tester widget is installed. This setting ensures that all history records required by the tester widget are captured. This property overrides the Record this data in history option, which you can set in the Event Designer editors.

      Properties are displayed in the History Settings subsection of the Server section.

    2. You must restart the wberuntimeear application, using the WAS Network Deployment administrative console, to ensure that changes to the properties are in effect.

    3. Optional: In the Event Designer Action Editor, Event Editor, Filter Editor and Rule Editor, the Record this data in History option is selected by default. To increase product performance and reduce unused history data, you can clear this option in one or all of the editors. However, if you clear the Record this data in History setting in the editors, but the as.director.bet.install property is set to true, then the property setting overrides the editor setting, and history is recorded.


    Configure the durable event queue

    Decision Server Events uses a file system based event queue to ensure that durable events are not lost if a server fails. The default location for this property is was_install_dir/profiles/profileName /wbe/nodeName/serverName/queue_data where

    • profileName is the name of your WAS profile.
    • nodeName is the name of the WAS node.
    • serverName is the name of the WAS server.

    The location of the durable event queue can be changed using the following property:

      as.director.server.durabledirectory

    If you experience disk contention, you might want to change the location of this queue to move it to a faster disk subsystem. If you are using Decision Server Events in a cluster, ensure that each cluster member has access to the path you specify. For example, if you change the location to be a path on the E: drive every server needs access to the E: drive.

    In a clustered environment, events that were stored in this queue are not failed over to other servers in the cluster. These events are only processed when the server they were being processed on is started again.


    Configure the log size of the durable event queue

    To change the size of the durable event queue log, use the following property:

    Durable event queue size property

    Property name Default Units
    as.director.server.DurableEventQueue.size 20 MB

    The default durable event queue log size of 20 MB is suitable for most workloads. However, if you see com.ibm.wbe.objectManager.TransactionCapacityExceededException in your SystemOut.log file then you might benefit from increasing the default size for this property.


    Configure how time-delayed event rules and actions are handled

    The evaluation of events and actions is typically done as soon as possible, but you can delay the evaluation based on user-defined criteria. For example, if a server shuts down, there might be event rules and actions scheduled for evaluation while the server is down. You can configure how the event runtime handles time-delayed event rules and actions. You can tell the event runtime how to deal with queued events and actions after a shutdown. Time-delayed event rules and actions are stored as scheduled tasks in the time_based_asset table that was created in the database manager of your choice when installing. The maxtardiness property value is also evaluated when the event runtime processes any delayed event or action.

    Edit the following properties:

    Property values to set for time-delayed processing

    Property Value
    For event rules:

    as.director.server.timebased.event.maxtardiness.minutes

    The maximum amount of time, in minutes, beyond the scheduled time when a time-delayed event rule is still run.

    The default value is -1. The event runtime will evaluate all queued events or invoke all queued actions as soon as the server has started.

    For actions:

    as.director.server.timebased.action.maxtardiness.minutes

    The maximum amount of time, in minutes, beyond the scheduled time when a time-delayed action is still run.

    The default value is -1. The event runtime will evaluate all queued events or invoke all queued actions as soon as the server has started.

    If the property has a value of 0 (zero), this is equivalent to the default value of -1.

    If you are using Properties, these properties are in the Timebased Events and Actions subsection of the Server section.


    Configure event runtime to store step data in memory

    For performance reasons, you might choose to store step data in memory. In Decision Server Events, you can define complex events, where one event has a dependency on another event or action. A complex event is a set of events linked through a common context ID, using the system context, or a context definition.

    When a context is initiated, each activity in the process is stored as a step in the context table that was created during the installation, by using persistent storage.

    Storing a step in a database table entails a certain amount of database access and the context does not go away unless it is manually purged from the table, or the context is ended by a terminating condition in a context definition. If you know that your contexts generally have a short life and then disappear, you can store all steps in memory, avoiding the database access.

    In a clustered environment, if as.director.server.eventflow.persistentStepStore is set to false and Decision Server Events is using the default memory store (as opposed to an ObjectGrid cache, which can be set by using another property), then any context table information is lost on server failover, although the event processing fails over to another server. This situation is also the case on server startup: if servers are still starting, and therefore ObjectGrid is rebalancing its partitions, it is possible for the partitions to move from server to server, and therefore context table information might be lost.

    To store contexts in memory instead of a database table, add the following custom properties:

    Custom properties to be set.

    Property Value Purpose Required
    as.director.server.eventflow.persistentStepStore false Turns off persistent storage and causes step data to be stored in memory yes
    as.director.server.eventflow.cacheStepStoreTimeout.ms 5000 milliseconds (default) Determines amount of time, in milliseconds, for which an instance of step data is kept in memory no – default is 5000 ms (5 seconds)

    See Set properties for detailed information about setting up these properties.


    Configure event runtime to store context data in ObjectGrid

    The context table uses the default cache. As a potentially higher-performing alternative, you can configure the context table to use ObjectGrid. You cannot use ObjectGrid as the context table on z/OS .

    1. To use ObjectGrid as an in-memory cache for the context table, set as.director.server.eventflow.gridStepStore to true.

    2. Switch off database backing by setting as.director.server.eventflow.persistentStepStore to false.

    3. Optionally, configure ObjectGrid to provide data replication capabilities:

      1. Locate objectGridDeployment.xml in wberuntime.jar, which is in was_install_dir/profiles/profileName /installedApps/cellName/wberuntimeear.ear, where

        • profileName is the name of your WAS profile.

        • cellName is the name of the WAS cell.

      2. Modify the file to include...

        <mapSet name="mapSet" 
                numberOfPartitions="10" 
                minSyncReplicas="0" 
                maxSyncReplicas="1" 
                maxAsyncReplicas="0" 
                numInitialContainers="1">
        

      If you have configured the event runtime in a cluster, you can configure ObjectGrid to provide data replication capabilities.


    Tuning the event runtime configuration

    Some tuning of the system might lead to higher performance when processing events.

    When considering how you tune your system, there are two main areas to look at:

    • The event runtime and WAS
    • JMS messaging


    Tuning with the event runtime and WAS

    There are several tasks that you can do to tune your system by configuring the event runtime andWAS. You can select from the following tasks that might improve performance:

    • Turn off logging.

    • Turn off the recording of history, if not required.

    • Use connectors only if required.

      If events are already in Decision Server Events format, better performance might be achieved by avoiding the use of connectors. Send events directly to the event destinations and receive actions directly from the action destinations. For example, consider using the destinations...

      • jms/eventDestination
      • jms/durableEventDestination
      • jms/actionTopic
      • jms/durableActionTopic

    • Ensure that there are sufficient event rule processing threads.

      If you are unable to achieve full processor utilization on the Decision Server Events server, consider increasing the value of the property...

        as.director.server.ruleProcessorInstances

    • Tune the Decision Server Events database:

      • Ensure that the database is tuned (or auto tuned) for the workload.

        The sizes of Log File and Buffer Pool are important.

      • Consider using a remote database with fast disk subsystems for data and logs.

        Ideally place data and logs on separate devices.

    • Go to...

        Application Servers | server1 | Java and Process Management | Process Definition | Java Virtual Machine

      ...and for 32-bit OS, set...

        Initial heap 1280
        Maximum heap 1280
        Generic JVM arguments -Xgcpolicy:gencon -Xmn1024M

      For 64-bit, set...

        Initial heap size 4096
        Maximum heap size 4096
        Generic JVM arguments -Xgcpolicy:gencon -Xmn2048M

  • Increase the concurrency:

    If you are using the File System, HTTP, JDBC, JMS, or SOAP action connectors and you see messages for actionTopic or durableActionTopic, increasing the concurrency might improve the rate at which actions are processed.

    1. In the navigation tree of the WAS administrative console, click...

        Resources | JMS | Activation specifications | activation_specification

      ..and set...

        File System wbeca_file_as
        HTTP wbeca_http_as
        JDBC wbeca_jdbc_as
        JMS wbeca_jms_as
        SOAP wbeca_soap_as

    2. Modify the activation specification according to the messaging provider that you are using:

      • If you are using WAS default messaging, modify the Maximum concurrent MDB invocations per endpoint.

      • If you are using WebSphere MQ as the messaging provider, modify the value of Maximum server sessions on the Advanced properties window.


    Tuning with JMS messaging

    There are several tasks that you can do to tune your system that are specific to JMS messaging. You can select from the following tasks that might improve performance:

    • For persistent messaging, consider using fast disk subsystems for data and logs. Ideally place data and logs on separate devices.

    • If you are using WebSphere MQ as the JMS provider:

      • The key tuning parameters relate to queue manager logs, channels, and listeners and queue buffer size.

      • Consider delivering the messages in batches from the input topic to Decision Server Events.

        This method is useful for non-persistent, non-durable WebSphere MQ JMS events. The batch size is configured using the WAS administrative console...

          Servers | Application servers | server1 | Messaging | Message Listener Service | Listener Ports | wbe_events | Maximum Messages

        However, if one of the messages in the batch fails, the whole batch is put back on the queue for processing.

    • If you are using WAS default messaging as the JMS provider:

      • The key tuning parameters relate to the choice of message reliability level, activation specifications, and size of the discardable data buffer.

      • Activation specification

        Particularly for non-durable JMS events, consider delivering the messages in batches from the input topic to Decision Server Events. This method can deliver events more efficiently.

          Resources | JMS | Activation specifications | wbe_events | Maximum batch size


    Configure multiple Decision Server Events profiles to coexist

    If you have multiple profiles of Decision Server Events on one computer, configure the WebSphere eXtreme Scale catalog service for the profiles to coexist.

    If you have a Decision Server Events profile and you have created a second profile on the same computer, configure the second profile for either profile to work correctly.

    1. Start the WAS administrative console. Ensure that you connect to the new WAS profile.

    2. Click...

        System administration | WebSphere eXtreme Scale | Catalog service domains | New

      ...and enter values for the properties:

      • Name: Enter a name for the catalog service domain, for example...

          WODM Catalog Service

      • Select...

          Catalog Server Endpoint | Existing application server | your WAS server

      • Client Port: Enter a port number that is not in use. Do not use the port used by the catalog server on the first profile, which is 6601 by default. You might use 6602 for the second profile, for example.

      • Click OK, then click Save to save your changes.

    3. Restart WAS for the changes to take effect.


    Configure technology connectors on a separate computer

    Technology connectors can be run on the same computer as the event runtime, or they can be run on a separate computer or operating system.

    To run the technology connectors on a separate computer to the computer where the event runtime is installed, and you have already installed the connectors on another computer, you need to configure the connectors on the second computer to connect to the event runtime.

    In the following instructions, to differentiate between the two computers involved, the computer on which the event runtime is to be installed is referred to as the Runtime computer, and computer where the connectors operate remotely is referred to as the Connectors computer.

    Before installing a connector, make sure that you have a copy of Application Client for WAS installed on the Connectors computer. The client software must be pointing to the same instance of WAS on which the event runtime is deployed.

    If you are planning to use WebSphere MQ as the JMS provider, also have the WebSphere MQ client installed.

    To set up the event runtime and the technology connectors on separate computers:

    1. Modify the environment script on the Connectors computer to point to the WAS on the Runtime computer:

      1. On the Connectors computer, locate a directory named config, which is the home directory of Decision Server Events...

          ODM_HOME

      2. In the config directory, edit setenv.sh and set the values of the two variables in the script on the Connectors computer...

        See...

      3. Edit the setenv script.

        On the WASADMINHOST line, enter the host name for the Runtime computer

          WASADMINHOST=computer1.MyCompany.com

      4. Continue to edit the setenv script. On the WASBOOTSTRAPPORT line, enter the bootstrap port number of the Runtime computer

          WASBOOTSTRAPPORT=2809

      5. Save the setenv script

    2. On the Runtime computer, if the database server definition uses localhost as the setting for hostname (as.director.common.db.default.dbhost), modify the setting of this property to point to the full hostname of the Runtime computer.


    Configure the User Console connector to use a WAS data source

    The User Console connector accesses its tables by using data connections. If you have configured Decision Server Events to use a WAS data source when accessing the event runtime, make further configuration changes to enable the User Console connector to function. You must do this task if you are using an embedded Apache Derby database.

    Define the User Console connector.

    If you have not configured Decision Server Events to use a WAS data source when accessing the event runtime, no further configuration is required.

    If the event runtime database is an embedded Apache Derby database, create a separate database to host the tables for the User Console and then change some property settings so that the User Console connector accesses its tables in the separate database.

    If the event runtime database is hosted by any other supported database manager (including Derby Network Server, which is included in your WAS installation), you can change property settings so that the User Console connector uses the Decision Server Events data connections to connect to the User Console tables. You can still, for performance reasons, access the event runtime database by using WAS data sources.

    To change the configuration so that the User Console connector accesses its tables using the Decision Server Events data connections, and not the WAS data sources:

    1. If the event runtime database is hosted by embedded Apache Derby, create a new database for the User Console tables. The new database can be hosted by any supported database but the instructions in this step assume that you are using Derby Network Server, which is already installed as part of WAS.

      1. Start Derby NetworkServer.

          cd was_install_dir/derby/bin/networkServer
          ./startNetworkServer.sh

        Derby NetworkServer starts in a command window with the following message:

          Server is ready to accept connections on port 1527.

        Port 1527 is the default port number on which Derby NetworkServer listens for connections.

        Start the ij command environment

          cd was_install_dir/derby/bin/networkServer
          ./ij.sh

      2. In the ij command window, create a new database for the User Console tables by running the following command (all on one line):

          CONNECT 'jdbc:derby:InstallDir\derby\userconsole;create=true'; (Windows)
          CONNECT 'jdbc:derby:InstallDir/derby/userconsole;create=true'; (UNIX)

      3. In the ij command window, create the tables in the new database, by running the derbydb.sql that is located at:

          InstallDir/config/db/derbydb.sql

        The script creates all the tables required of the User Console.

    2. Configure the User Console to use the new database by setting the following properties (if you use Decision Server Events Properties, the properties are on the Connector page):

      1. If you are using Derby Network Server:

        Property values to set.

        Property Value
        as.director.connectors.pem.dbclass com.ibm.wbe.db.DerbyDB
        as.director.connectors.pem.instance InstallDir/derby/userconsole
        as.director.connectors.pem.dbport 1527
        as.director.connectors.pem.dbhost localhost
        as.director.connectors.pem.username APP
        as.director.connectors.pem.password derbyadmin

      2. In you are using another other supported database:

        Property values to set.

        Property Value
        as.director.connectors.pem.dbclass com.ibm.wbe.db.DB2DB (DB2 )

        com.ibm.wbe.db.OracleDB (Oracle)

        com.ibm.wbe.db.MssDB (SQL Server)

        as.director.connectors.pem.instance The name of the database
        as.director.connectors.pem.dbport The port on which the database is listening
        as.director.connectors.pem.dbhost The host name of the database
        as.director.connectors.pem.username The user ID that Decision Server Events uses to access the database
        as.director.connectors.pem.password The password associated with the user ID

      3. Enable each of the fields listed in the table in the previous step. You must enable fields as well as entering the property values.

      4. Ensure that you have enabled history before you continue, otherwise no data is produced for the User Console to display.

    3. Stop then restart WAS to apply the properties changes.

    4. Ensure that database is running, then start the Connectors.


    Verify your Decision Server Events configuration

    Verify the event runtime

    Check that Decision Server Events is properly installed and configured by loading the supplied verification event project and sending an event through the event runtime.

    Install and configure Decision Server Events, including configuring a JMS messaging provider.

    Ensure that you have installed Event Designer. The event runtime can be installed on a separate computer.

    If you turned on WAS security during installation, configure user authentication to the event runtime before verifying the installation.

    1. On the computer on which you have installed the event runtime, ensure that WAS is running.

    2. Check that the event runtime application has been installed and started on WAS:

      1. Start the WAS administrative console.

      2. Log in to the WAS administrative console with a user ID of your choice.

      3. In the navigation tree of the WAS administrative console, click Applications > Application Types > WebSphere enterprise applications. Ensure that the following application is listed and shown as started:

        • wberuntimeear
        • EventWidgetsEar

        Ensure that the following application is listed and shown as started if you have prepared the environment for testing:

        • wbetesterear

    3. On the computer on which you installed the event runtime, create a directory name DecisionServerTest, and make a note of the location in which we created the directory.

    4. In Event Designer, right-click in the Event Explorer view then click Import. The Import wizard opens.

    5. In the Import wizard, click Event Project from XML File > Next.

    6. Click Browse, navigate to InstallDir\connectors\validation and select the event project named installValidation.xml. Click Next. Accept the default settings for the rest of the wizard and click Finish to import the event project into your workspace.

    7. In the Event Explorer view, expand the event project, expand the Outgoing folder, and open the Outgoing action:

    8. In the Action editor, click the Connector tab:

    9. In the Folder on that computer field, replace the existing value with the complete path that points to the location of the DecisionServerTest directory that we created. Save your changes.

    10. To deploy the event project, right-click the event project in the Event Explorer view and select Deploy. The Deploy wizard opens:

    11. Select Deploy all assets and click Next.

    12. Enter the connection details for the event runtime:

      Ensure that the host name and port values are correct for the WAS instance in which the event runtime is deployed (the port value is the WC_defaulthost port, which can be determined through the WAS administrative console). Enter the user ID and password, if security is enabled.

    13. Click Finish to deploy the event project. A message is displayed indicating that the event project is deployed successfully. Close Event Designer.

    14. Start the stand-alone technology connectors.

      An example of a successful connector startup on Windows:

        C:\IBM\ODM85\connectors\bin>connectors.bat
        *********************************************************
        IBM Decision Server technology connectors (c)Copyright IBM Corp. 2003, 2012
        Version: IBM ODM 8.5
        Locale: en_GB Java version: 1.6.0
        *********************************************************
        BEER0561I: The technology connectors are waiting for wberuntimeear.
        BEER0644I: The technology connectors established communication with wberuntimeear BEER0590I: Connector runtime checkpoint: 2009-04-14 08:58:10.718
        BEER2608I: Authentication mode: None BEER2609I: Event Runtime users group: WBEUsers BEER2610I: Event Runtime administration group: WBEAdmins BEER2611W: *** WARNING: SECURITY IS NOT ENABLED ***
        BEER2612W: User maestro is granted full access to the event runtime BEER0611I: Initialization is complete BEER0670I: JNDI provider URL: corbaloc:iiop:localhost:2809
        Connectors>

    15. Send a test event to the event runtime...

      cd InstallDir/connectors/bin/
      ./cmdline.sh -uid userid 
                   -pwd password 
                   <test-event-file>
      

      userid and password are a valid user ID and password combination that grants access to WbeBus, and <test-event-file> is the complete path to where the installValidation_event.xml file is located, for example...

      cd  InstallDir/connectors/bin/
      ./cmdline.sh -uid myname \
                   -pwd mypassword \
                   ODM_HOME/connectors/validation/installValidation_event.xml
      

      A new file is created...

        DecisionServerTest/ValidationTestrandom-number.xml

      In cmdline.sh there are relative paths (/../../) to setenv.sh files. You previously modified these relative paths in the component directory, but not in ODM installation directory that the relative path references (the component directory is a copy of part of ODM installation directory). You can fix this issue in one of two ways:

      • Either, edit the setenv.sh file to include a parameter that specifies the location of the component directory.

      • Or, copy the connectors directory into the component directory.

        If you use this solution,

          cd InstallDir/connectors/bin/ ./cmdline.sh

    You have now verified the installation.


    Secure Decision Server Events

    To secure Decision Server Events, both WAS security and Decision Server Events security settings must be configured.

    The default and preferred security provider is WAS.

    If you are migrating from a previous version of Decision Server Events where you used a different security provider, you can continue to use this provider, but complete additional steps when configuring Decision Server Events and the event widgets.


    User authentication

    User authentication to the event runtime can be implemented for Decision Server Events by using WAS. This method is the default and the preferred method. User authentication controls who has access to the event runtime.

    You can permit access to the event runtime without any user authentication, though this permission does mean that anyone can access the event runtime and change assets.

    If you are migrating from a previous version of Decision Server Events where you used a different security provider, you can continue to use that security provider.


    Configure user authentication by using WAS

    To secure access to the event runtime, configure Decision Server Events to use WAS to define authorized users and groups. This method is the default and the preferred method. To enable security by using WAS, :

    • Enable WAS security.

    • Configure Decision Server Events to use WAS for user authentication

    • Map users and user groups to Decision Server Events roles.

    • Configure WAS administrative roles.

    1. Start the WAS administrative console.

    2. Enable WAS security:

      Ensure Use Java 2 security to restrict application access to local resources is selected.

    3. To configure Decision Server Events to use WAS for user authentication, change these properties:

      Properties to be changed.

      Property Value to set
      as.director.common.authentication.method AppServer

      This value is the default value for Decision Server Events but no authentication or authorization takes place unless you have also enabled security in the previous step.

      as.director.server.authentication.username A user ID that is the primary administrative user for WAS.
      as.director.server.authentication.password The password associated with the user ID.

      If you are using Properties, the properties are displayed in the Authentication minor section of the Common section.

    4. Set the user ID of the primary administrator:

      1. In the WAS administrative console, click Security > Global security.

      2. Ensure that Available realm definitions is set to Local operating system.

      3. Click Configure

      4. In the Primary administrative user name field, type the user ID used to log in to the WAS administrative console to do administrative tasks after security is enabled.

      5. Apply your changes.

    5. Configure WAS administrative roles.

      1. In the WAS administrative console, click Security > Global security > Administrative user roles > Add

      2. In the Search string field, search for the user IDs to which you want to assign the roles, and click Search

      3. In the Available field, select the user IDs to which you want to assign the roles and move them to the Mapped to role field, using the arrows.

      4. Under Role(s), click ether Operator or Administrator.

      5. Click OK and Save.

    6. Map users and user groups to Decision Server Events roles.

      Various roles can be assigned to users and groups.

      When you are using WAS as the security provider, you cannot change the role names.

      1. In the WAS administrative console, click...

          Applications | Application Types | WebSphere enterprise applications | wberuntimeear | Security role to user/group mapping

      2. From the list of the roles, select the roles that you want to map (assign) to users, click Map Users.

      3. In the Search string field, search for the user IDs to which you want to assign the roles, and click Search.

      4. In the Available field, select the user IDs to which you want to assign the roles and move them to the Selected field, using the arrows.

      5. Click OK and Save.

    7. After you have made these configuration changes, restart WAS to ensure that the changes are in effect.

    Decision Server Events is now configured to use WAS to authenticate users.


    Configure user authentication by using LDAP

    If you are migrating from a previous version of Decision Server Events where you used LDAP (Lightweight Directory Access Protocol), you can continue to use it. User authentication to the event runtime can be configured by using WAS. This method is the default and preferred method. WAS supports the use of LDAP for user registries.

    To continue using the LDAP support as provided in earlier versions of Decision Server Events, use the following steps.

    1. Use the appropriate LDAP administrative utility to create the following groups:

      Groups to be created.

      Access level Name of group to be created Example
      Administrator WBEAdmins

      If you want the admin group to reference a different name, create a custom property called as.director.common.authentication.adminGroup with a value of the group name.

      However, if you define this property, then the WBEAdmins group is no longer an admin group, and any users in that group no longer have administrative privileges (unless they are also a member of the new admin group).

      WBEAdmins
      User Choose any name, but the name must match the value of as.director.common.authentication.userGroup set in Properties. WBEUsers

    2. Change the following properties:

      Properties to be changed.

      Property Action
      as.director.common.authentication.method Select LDAP.
      as.director.common.authentication.server Replace <HOST-NAME> with the name of the server where LDAP resides.

      Multiple server names can be entered, separated by a comma. If the first server in the list is unavailable, authentication is attempted against the next and subsequent servers in the list.

      as.director.common.authentication.namecontext Remove dc=<MYDOMAIN> and replace <MYCOMPANY> with company name.
      as.director.server.authentication.member.filterEEE Enable.
      as.director.server.authentication.member.attribute Enable.
      as.director.server.authentication.userid.format Only for internal use, do not change.
      as.director.server.authentication.security.method Set to one of:

      • none (default)
      • simple
      • strong
      as.director.common. authentication.security.protocol Set to one of:

      • unspecified (default)
      • ssl
      as.director.common.authentication.userGroup Set the value to match the name of the user group defined in the Active Directory (the default is WBEUsers).
      as.director.server.authentication.username Replace admin with a user ID that is registered in Active Directory in the Administrator or User groups (set up in step 1).
      as.director.server.authentication.password Replace admin with the password associated with the user ID.

      If you are using Properties, the properties are in the Authentication minor section of the Common section.


    Configure user authentication by using Microsoft Windows Active Directory

    If you are migrating from a previous version of Decision Server Events where you used Windows Active Directory, you can continue to use it. On Windows, user authentication to the event runtime can be configured by using WAS.

    This method is the default and the preferred method.

    To continue using Windows Active Directory, use the following steps.

    1. In Active Directory, create the following groups:

      Groups to create in Active Directory.

      Access level Name of group to be created For example
      Administrator WBEAdmins

      If you want the admin group to reference a different name, create a custom property called as.director.common.authentication.adminGroup with a value of the group name.

      However, if you define this property, then the WBEAdmins group is no longer an admin group, and any users in that group no longer have administrative privileges (unless they are also a member of the new admin group).

      WBEAdmins
      User Choose any name, but the name must match the value of as.director.common.authentication.userGroup set in Properties. WBEUsers

    2. Change these properties:

      Properties to change.

      Property Action
      as.director.common.authentication.method Select Active Directory
      as.director.common.authentication.server Replace <HOST-NAME> with the name of the server where Active Directory resides.

      Multiple server names can be entered, separated by a comma. If the first server in the list is unavailable, authentication is attempted against the next and subsequent servers in the list.

      as.director.common.authentication.namecontext Replace <MYDOMAIN> with domain name and <MYCOMPANY> with company name.
      as.director.common.authentication.userGroup Set the value to match the name of the user group defined in the Active Directory (the default is WBEUsers).
      as.director.server.authentication.username Replace admin with a user ID that is registered in Active Directory in the Administrator or User groups (set up in step 1).
      as.director.server.authentication.password Replace admin with the password associated with the user ID.

      If you are using Properties, the properties are in the Authentication minor section of the Common section.


    Configure user authentication by using User Console

    Alternatively, you can use User Console to authorize users and groups by adding them to certain event runtime tables.

    To provide security of access to the event runtime, the default and preferred method is to use WAS security.

    The tasks relating to user authentication by using User Console are as follows.

    1. Enable authentication using the event runtime database:

      1. Change these properties:

        Properties to be changed.

        Property Value to set
        as.director.common.authentication.method Database
        as.director.server.authentication.username user ID
        as.director.server.authentication.password password of your choice

        If you are using Properties, the properties are in the Authentication subsection of the Common section.

      2. Stop and restart the wberuntimeear application in the WAS administrative console. The next time a Decision Server Events user interface or the event runtime is started, a valid user ID and password must be provided.

    2. Define new groups:

      1. Start User Console by logging from the common login panel at:

        http://server:port/wbe/common/login.jsp

        where server is the name of the WAS server where Decision Server Events is installed and port is the port number of WC_defaulthost of this server (typically 9080). This value can be determined from the table displayed when you use the Application Server Network Deployment administrative console, click Servers, then Application servers, click the name of the server, and then on Ports.

      2. Move the mouse pointer over the User Accounts button and select Groups from the menu to display the Groups window.

      3. Click the Add a New Group button to display the New Group window. Complete the fields and click Add. Repeat for each group you want.

      4. Click Save configuration to save your changes.

    3. Define new users:

      1. Start User Console by logging in from the common login panel at:

        http://server:port/wbe/common/login.jsp

      2. Move the mouse pointer over the User Accounts button and select Users from the menu to display the Users window.

      3. Click the Add a New User button to display the New User window. Complete the fields, including the groups to which the user belongs, and click Add. Repeat for each user you want.

      4. Click Save configuration to save your changes.

    4. Add a user to or remove a user from a group:

      1. Start User Console by logging in from the common login panel at:

        http://server:port/wbe/common/login.jsp

      2. Move the mouse pointer over the User Accounts button and select Users from the menu to display the Users window.

      3. Click the Edit button for the relevant user, to display the Edit User window.

      4. Select or clear a group as required, and click Update to complete the edit.

      5. Click Save configuration to save your changes.

    5. Disable user authentication:

      If you no longer want to do user authentication, or if Active Directory or LDAP is not available to support authentication, then you can disable the authentication.

      Change the as.director.common.authentication.method property to none.

      If you are using Properties, the property is in the Common section, in the Authentication subsection. Disabling user authentication means that anyone can access the event runtime and change assets.


    Secure access to charts

    By using WAS security, you can ensure that only authenticated users can access charts through the use of the chart widgets.

    To ensure that a user must authenticate before accessing chart widgets, follow these steps:

    1. Ensure that WAS security is enabled.

    2. Assign the user to the 'WBEDashboardUsers' role.


    Secure the service integration bus

    If you are using WAS default messaging as the JMS provider for the event runtime, secure the service integration bus to prevent unauthorized access.

    This information applies only if you are using default messaging as the JMS provider for the event runtime. If you are using WebSphere MQ as the JMS provider, see configure WebSphere MQ to be the JMS provider for more information.

    You must configure the event runtime to use default messaging as the JMS provider:

    • Either, when a management or custom profile is created or when the profile is augmented with Decision Server Events.

    • Or, at a later time

    When the event runtime is configured to use default messaging as the JMS provider, the service integration bus WbeBus and a number of messaging destinations and activation specifications are configured.

    If WAS administrative security is enabled when WbeBus is configured, the bus is secured and all authenticated users are authorized to connect to the bus. You can change the configuration of the bus to restrict access to specific user IDs.

    Use the WAS administrative console.

    1. Ensure that security is enabled for the service integration bus WbeBus.

    2. Review the users and groups in the bus connector role.

      1. Remove the special groups AllAuthenticated and Everyone if these groups are in the role.
      2. Restrict access to only those users and groups that are used to connect to the bus.

      Depending on your requirements, you can add a single user ID to the bus connector role that is shared by the components of the event runtime that connect to the bus.

    3. Review the authentication aliases used by the activation specifications to connect to WbeBus.

      See Activation specifications.

      If the service integration bus is secured when the activation specifications are configured, the activation specifications are configured to use a single authentication alias, WbeBusAlias. This alias must be configured with a user ID and password in the bus connector role.

    4. Review the authentication credentials used by the event runtime and connector components to connect to the JMS provider, which are set using the following event runtime properties:

      These properties must be configured with a user ID and password in the bus connector role.


    Configure the Decision Center consoles on WAS

    Decision Center includes two consoles:

    • Enterprise
    • Business

    Both consoles work on WebSphere Application Server V8.0 and V8.5. You must have WAS installed and running to do this configuration.

    A specific integration extension for the IBM Process Server platform is available.

    If you have rule projects created with a previous product version, refer to the Migrating topics on how to upgrade the Rule Team Server database schema.


    Step 1: Restrict database user permissions

    Skip to the next step if you do not need further restrictions.

    The database user, for example rtsdbUser, is defined by the database administrator, and has no relation to the standard Decision Center groups.

    Permissions to define on the Decision Center database:

    Database permission Operation
    Use Decision Center Create DB schema Modify DB schema Migrate DB schema
    ALTER TABLE Not required Not required Required Required
    CREATE INDEX Not required Required Required Required
    CREATE ROLE Not required Not required Not required Required
    CREATE SEQUENCE Not required Required Required Required
    CREATE TABLE Not required Required Required Required
    CREATE VIEW Not required Required Required Required
    DROP INDEX Not required Not required Required Required
    DROP SEQUENCE Not required Not required Required Required
    DROP TABLE Not required Not required Required Required
    DROP VIEW Not required Not required Required Required
    INSERT TABLE Required Required Required Required
    SELECT SEQUENCE Required Required Required Required
    SELECT TABLE Required Required Required Required
    UPDATE TABLE Required Required Required Required

    Some supported databases do not require all the above permissions.


    Step 2: Configure database connectivity

    In this set of tasks, we create a JDBC provider, a data source, and a connection pool, and do other optional tasks. We then establish and test the database connection.


    Create a JDBC provider

    1. Log in to the Integrated Solutions Console and go to...

        Resources | JDBC | JDBC Providers | Scope - Node=x, Server=y | New

    2. Select the database type, provider type, and a non-XA implementation type. For example...

      • Derby
      • Derby JDBC Provider
      • Connection pool data source

    3. Click Next. A summary opens.

    4. Click Finish.

    5. Click Save


    Create a data source and a connection pool

    If WAS is used in cluster mode, define the data source at node level in the cluster (as opposed to cluster level).

    1. In the Integrated Solutions Console, open...

        Resources | JDBC | Data sources | Node=x, Server=y | New

    2. Enter a name for the data source in the Data source name field, and in the JNDI name field, set...

        jdbc/ilogDataSource

      If several data sources are required, specify multiple JNDI names, to start the console, use URL...

        hostName:portNumber/teamserver?datasource=jndiName

    3. Click Next.

    4. In Step 2, select...

        Select an existing JDBC provider

      ...and then select the non-XA JDBC provider created earlier.

    5. Click Next.

    6. In Step 3, enter database properties specific to the data source and click Next.

      Minimum set of properties required...

      Database Properties
      DB2 Universal JDBC Driver

      databaseName Database name if driverType is set to 4, or a locally catalogued database name if driverType is set to 2
      driverType 2 or 4

      The following properties are required if driverType is 4:

      serverName TCP/IP address or host name
      portNumber TCP/IP port number

      DB2 legacy CLI-based Type 2 databaseName: for example, Sample.
      Oracle JDBC Driver URL: for example

        jdbc:oracle:oci:@sample

      Derby

      databaseName path to the location of the database files. This directory must not exist already. For example, c:\derbydata.
      Use this data source in container managed persistence (CMP) Clear this option

      You may need to configure datasource isolation to provide better concurrency experience, since Decision Center may encounter various database dead-locks if the transaction isolation level is not set to 'READ-COMMITTED'.

    7. In Step 4, click Next to accept the default values.

      Step 5 displays a summary of your settings.

    8. Click Finish.

      The connection pool is created and is associated with the data source.

    9. Click Save


    Create J2C authentication data

    This procedure uses rtsAdmin as the user ID and rtsAdmin as the password. Your user ID and password might be different, depending on the user or schema used to execute the Rule Execution Server SQL script. If you perform the procedure as described, tables are created under the rtsAdmin schema.

    For a Derby database, if the connect command does not contain the user ID, the user ID and password are the default values APP and APP. If we create the tables under the APP schema, you do not need to do this procedure.

    1. In the Integrated Solutions Console, open...

        Resources | JDBC | Data sources | data_source | Related Items | JAAS - J2C authentication data | New

    2. Set the fields Alias, User ID, and Password. For example...

      Alias RtsDerbyUser
      User ID rtsAdmin
      Password rtsAdmin

    3. Click Apply and then click Save to save directly to the master configuration.

    4. Open...

        Resources | JDBC and Data sources | data_source | Security settings | Component-managed authentication alias | alias | NodeName/RtsDerbyUser

      ...where NodeName is the name of the WAS node on which you are configuring Rule Execution Server.

    5. For Container-managed authentication alias, select...

        NodeName/RtsDerbyUser

    6. Click Apply and then click Save to save directly to the master configuration.


    Change the custom properties of your data source

    In the Integrated Solutions Console, open...

      Resources | JDBC | Data sources | data_source | Additional Properties | Custom properties.

    For example, for a Derby data source, if you have not created the database, you can set the createDatabase=create. The first database connection creates the database.


    Connecting to the database

    In the Integrated Solutions Console, open...

      Resources | JDBC | Data sources | data_source | Test connection.


    Step 3: Configure security

    Create users and groups

    If you already have suitable groups and users defined, skip this procedure and connect users to their appropriate roles when you deploy the applications. If you do not have groups and users defined, or to define new groups and users, perform the following steps.

    A federated user repository serves as the active user registry.

    Group Use Default user name and password
    rtsAdministrator Mandatory. Administrator access. rtsAdmin, rtsAdmin
    rtsConfigManager Mandatory. User configuration manager access. rtsConfig, rtsConfig
    rtsUser Mandatory. User standard access. rtsUser1, rtsUser1
    rtsInstaller Mandatory, User access to the Installation Manager. rtsAdmin, rtsAdmin
    Validator Optional custom group. Used in the Decision Center permissions tutorial. Val, Val
    Eligibility Optional custom group. Used in Decision Center permissions tutorial. Eli, Eli

    To configure a federated repository:

    1. From the console, open...

        Security | Global security

    2. If Federated repositories is already selected under Current realm definition, make sure that...

        Enable application security

      ..is selected and click Apply and Save.

      If Federated repositories is not already selected, click...

        Security Configuration Wizard

      ...and complete the wizard...

      1. In Step 1, select...

          Enable application security

        ...and click Next

      2. In Step 2, select...

          Federated repositories

        ...and click Next.

      3. In Step 3, type the name in the Primary administrative user name field, type websphere in the Password field, and click Next.

      4. In Step 4, review the security configuration summary and click Finish.

      5. Click Save to save the changes to the master configuration.

      6. Restart WAS, and then log in to the Integrated Solutions Console as the primary administrative user.

    3. Open...

        Users and Groups | Manage Groups | Create

      ...and enter rtsUser as the group name. Click Create.

    4. Click Create Like and create another group named rtsAdministrator. Click Create.

    5. Click Create Like and create another group named rtsConfigManager. Click Create.

    6. Click Create Like and create another group named rtsInstaller. Click Create. Click Close.

    7. To perform the Decision Center permissions tutorial in your own installation, create two additional groups: Validator and Eligibility.

    8. In the side panel, open...

        Users and Groups | Manage Users | Create

    9. Enter rtsUser1 as the User ID and assign this new user to a group. To do so:

      1. Click Group Membership. The page that enables you to select a group opens.

      2. Click Search. The list of existing groups is displayed.

      3. Select the rtsUser group and click Add.

      4. Click Close.

    10. Enter a given name and surname for rtsUser1, then enter the rtsUser1 password, and click Create.

    11. Click Close.

    12. Create another user named rtsAdmin with password rtsAdmin, and assign this user to the rtsAdministrator and rtsInstaller groups.

    13. Create another user named rtsConfig with password rtsConfig, and assign this user to the rtsConfigManager group.

    14. Optional: Create a user named Val with password Val, and add the user to the rtsUser, Validator, and Eligibility groups. You can skip this step if you do not intend to perform the Decision Center permissions tutorial.

    15. Optional: Create another user named Eli with password Eli and add the user to the rtsUser and Eligibility groups. You can skip this step if you do not intend to perform the Decision Center permissions tutorial.

    16. Restart the application server.


    Update the security policies

    If you enable Java 2 security on WAS, override the global security policies of the application server so that the deployed application can access the MBean server.

    If you enable Java 2 security in the Global Security window of the Integrated Solutions Console, update the was.policy file that is packaged in the Decision Center EAR file.

    The was.policy file is in...

      InstallDir/teamserver/applicationservers/WebSphere<version_number>/META-INF/jrules-teamserver-WAS<version_number>.ear

    The EAR file is a compressed file. You must open it to extract the files that must be changed, and then replace the files in the EAR. Use Ant commands to repackage the EAR file.

    Update the was.policy file to give read and write permissions on each directory containing published RuleDocs. For example:

      permission java.io.FilePermission "<path to my ruledoc folder>${/}-", "read, write, delete";

    If you use Java 2 security but do not update the was.policy file, users cannot synchronize RuleDocs to the file system.


    Set custom properties for Decision Center security

    Location Property and value Description
    Application servers | server1 | Session management | Custom properties InvalidateOnUnauthorizedSessionRequestException = true Prevents authentication errors if the same user ID accesses Business console and Enterprise console at the same time,
    Global Security | Custom properties com.ibm.websphere.security.setContextRootForFormLogin = true Prevents a WAS cookie from pointing to the incorrect application if Business console and Enterprise console are used on the same application server,


    Step 4: Deploy the Decision Center EAR file

    Declare custom groups

    Default groups...

    • rtsUser
    • rtsConfigManager
    • rtsAdministrator
    • rtsInstaller

    To add custom groups, including Validator and Eligibility

    To use the Decision Center permissions mechanism, upload groups to the database.

    To add your custom groups to the Decision Center deployment descriptor:

    1. Make a backup of...

        InstallDir/teamserver/applicationservers/WebSphere<version_number>/jrules-teamserver-WAS<version_number>.ear

    2. Extract the files...

        jar xvf jrules-teamserver-WAS<version_number>.ear

    3. Add each custom group as a role in the section...

        SECURITY - ROLE

      ...of...

        teamserver.war/WEB-INF/web.xml

      For example:

      <security-role>
          <role-name>Validator</role-name>
      </security-role>

    4. If you are configuring Decision Center for WAS V8.0 or V8.5, add the groups similarly in...

        decisioncenter.war/WEB-INF/web.xml

    5. Add each custom group to...

        META-INF/application.xml

    6. Repackage the EAR.


    Deploy the EAR

    When deploying the Decision Center EAR file, the process sets the persistence locale. After you have saved a rule to the database, you are no longer allowed to change the persistence locale. To install Decision Center in a language other than English, take note of the instructions provided in Set the persistence locale.

    If you redeploy the Decision Center EAR file, the redeployment has the following consequences:

    • The class loading sequence is lost.

    • All users, such as rtsUser1, rtsAdmin, lose their role, even though they belong to the correct group. When you sign in to the Decision Center console, a message is displayed, such as rtsUser1 does not have the correct role.

    To deploy the EAR file:

    1. From the Integrated Solutions Console, click...

        Applications | New Application | New Enterprise Application | Browse | ODM_INSTALL/teamserver/applicationservers/WebSphere8/jrules-teamserver-WAS.ear | Next | Detailed - Show all installation options and parameters | Choose | Generate Default Bindings | Next

    2. If a security warning is displayed, click Continue.

    3. In Step 1, click Next to accept the default settings.

    4. In Step 2, select the target server and the WAR files and click Next. Keep the default setting if you only have one server.

    5. For Step 3 to Step 8, click Next to accept the default settings.

    6. In Step 9, map security roles to users and groups.

      1. Select a check box next to a role in the table and click Map groups.

      2. Click Search in the middle of the page to display the groups.

      3. Map the group to the role that you are editing by moving that role to the Selected column.

      4. Click OK and repeat for all the roles.

      5. To follow the Decision Center permissions tutorial in your own installation, map the two custom groups: Validator and Eligibility.

      After completion asignments are shown as in the following table. If you have groups or users, you can map those to the existing role instead....

      Role Mapped groups
      rtsUser rtsUser
      rtsAdministrator rtsAdministrator
      rtsConfigManager rtsConfigManager
      rtsInstaller rtsInstaller
      Validator Validator
      Eligibility Eligibility

    7. If the application server is WAS V8.0 or V8.5, click Next for Step 10 and Step 11 to accept the default settings.

      A summary is displayed.

      If WebSphere eXtreme Scale is also installed, additional settings are displayed as Step 12 in the side panel of the Integrated Solutions Console.

    8. Click Finish.

    9. Click Save to save your workspace changes to the master configuration.


    Change the class loading sequence

    The Decision Center application does not support the default parent first configuration.

    To change the class loading sequence:

    1. In the console, open...

        Applications | Application Types | WebSphere enterprise applications | ILOG Rule Team Server | Modules | Manage Modules | teamserver | Class loader order menu | Classes loaded with local class loader first (parent last) | OK

    2. Click decisioncenter and repeat the same action.

    3. Click Save

    4. Open...

        Applications | Application Types | WebSphere enterprise applications

      ...and select the check box next to...

        ILOG Rule Team Server ...

      ...then click Start to start the application.


    Step 5: Verify the deployment of the Decision Center Enterprise console

    Start the application server, and then use your web browser to open the Decision Center Enterprise console.

      http://setgetweb.com:port/teamserver

    Sign in with rtsAdministrator rights. For example: rtsAdmin/rtsAdmin


    Step 6: Complete the configuration

    Complete from the Decision Center Enterprise console

    Installation Settings wizard overview

    The Installation Settings wizard opens automatically when you launch the Decision Center console to complete an installation. You can also open the Installation Settings wizard by clicking...

      Configure | Installation Settings Wizard

    To access the Installation Settings wizard, have both administrator privileges and the rtsInstaller role.

    Use the Installation Settings wizard to...

    Action Description
    Configure the database Mandatory when you complete the configuration with a database on a distributed platform.
    Set up message files Mandatory during the installation only if you have some custom rule model extension files.
    Set up groups Set up the same groups declared in the application server if you want to use the Decision Center security and permissions mechanisms.
    Change the persistence locale Perform this step if the persistence locale is different from the locale en_US.
    Change configuration parameters Optional. You will change some configuration parameters when customizing Decision Center.

    After completing the installation, Decision Center is ready to use, but does not contain rule projects. If you open Decision Center and there are no rule projects, a message in the Configure tab informs you that no project has been found and that you should either publish a rule project by using Rule Designer or contact the administrator. If you see this message, publish a rule project from Rule Designer. If you have rule projects created with a previous product version, upgrade the Decision Center database schema.


    Step 1: Configure the database

    You use the Installation Settings wizard to configure the database. You store the extensions to the Decision Center rule model in two XML files:

      Model description *.brmx
      Initialize enumerations and hierarchies *.brdx

    1. When the Installation Settings wizard opens in Decision Center, click Next.

    2. Select one of the extension files:

      • Default extensions (already selected)
      • Custom extensions (brmx/brdx)
      • Custom extensions (Zip)

    3. Click Generate SQL to generate the script that creates the database tables based on the contents of your rule model files.

    4. After generating the script, select the check box...

        Execute the SQL script

      ...and then click Next.


    Step 2: Set up message files

    Message files contain the display text associated with the extensions to the rule model contained in the .brmx and .brdx files.

    For example:

      status=Status
      effectiveDate=Effective Date
      expirationDate=Expiration Date
      new=New
      defined=Defined

    The contents of the message files must respect the ISO-LATIN-1 standard.

    You can find the default message file...

      ODM_INSTALL/teamserver/bin/defaultextensionmessages_<LOCALE>.properties

    If you use the default rule model when creating your database, the default message file is automatically sent to the database. To upload your own message files, use the Installation Settings wizard as explained below.

    You must have a message file for each locale that you use. Message files are identified by their locale.

    To declare a message file in the Installation Settings wizard:

    1. Click New.

    2. Enter a locale.

    3. Browse to the location of the message file for this locale.

    4. Click Apply.

    If Decision Center supports this locale, the Installation Settings wizard assigns a locale code so that you can identify it.

    Click Next to access Step 3: Set up groups.


    Step 3: Set up groups

    In addition to creating groups in the application server when you set up security access, use the Setup Groups page in the Installation Settings wizard to upload groups to the database.

    You do this step only if you want to use the Decision Center project access and permission mechanisms. You have to have added all the groups that you want to see in the available list when enforcing project security or setting permissions in Decision Center.

    In Decision Center, the groups are the roles in the application server, not the groups defined in the user registry. Decision Center uses the group information to verify whether a user belongs to a role in the application server.

    Using the Setup Groups page in the Installation Settings wizard, upload the default groups for rtsUser and rtsConfigManager, and any custom groups (Validator and Eligibility if you want to do the permissions tutorial) as follows:

    1. Click New.

    2. Type the group name.

    3. Click Apply.

    4. When you have added all the groups, proceed in one of the following ways:

      • Click Next if you want to set a different persistence locale, or configuration parameters.

      • Click Finish if you do not want to change these settings.

    You do not have to upload the rtsAdministrator or rtsInstaller group. The administrator group has access to everything, and an installer user must belong to another group.


    Step 4: Set the persistence locale

    The persistence locale determines the language in which you store rules in the Decision Center database.

    You set the locale when deploy the Decision Center EAR file to the application server. As a consequence, you store the rules in the database in the locale of the Decision Center application.

    Changing the persistence locale does not change the language in which Decision Center displays rules. Changing it in Decision Center is necessary only to match the locale of Rule Designer when synchronizing your rule projects, and to access the tutorials in your locale.

    You must not change the persistence locale after you have saved a rule to the database.

    To set the persistence locale:

    1. Enter a locale in the Locale field.

    2. Click Apply.

    3. Do one of the following actions:

      • Click Next if you want to set the configuration parameters.

      • Click Finish if you do not want to change these settings.


    Step 5: Set configuration parameters

    Many tasks related to customizing Decision Center require you to add or remove configuration parameters.

    Decision Center uses the following configuration parameters to generate complete URLs in permalinks:

    • teamserver.server.port: the port number

    • teamserver.server.isSecure: true if the connection is secure

    • teamserver.server.hostname: the name of the host.

    You generate these parameters when you sign in to the Decision Center console for the first time after configuring the database. Use the Installation Settings wizard to change these parameters at any time.

    The following table gives a description of the main configuration parameters available in...

      teamserver.war/WEB-INF/lib/teamserver-model-XXX.jar/ilog/rules/teamserver/preferences.properties

    Parameter Used to
    teamserver.<extractorValidator>.class Specify a ruleset extractor validator class to use for the given extractorValidator name. The class must implement the IlrExtractorValidator interface. After you define this class, specify this name as the extractor validator to use when defining a ruleset extractor.
    teamserver.build.path

    Define the location of the IRL cache in the file system. Compute the path as follows:

    • Use this property with the name of the user who launched the server as the root for the cache (<build.path>_username).

    • If it is not defined, use the system property java.io.tmpdir and add rtscache. For example...

        <temp dir>/rtscache_username

    • If the system property is not defined, use the server directory and add rtscache. For example...

        <server dir>/rtscache_username

    teamserver.brl.verbalizers List of locales for which a BAL verbalizer is defined.
    teamserver.brl.verbalizer.<locale> Verbalizer class for the given locale. The class must implement the interface...

      ilog.rules.vocabulary.verbalization.IlrVerbalizer

    The parameters in the table include the teamserver prefix, which is not in the preferences.properties file. You must include the prefix when setting configuration parameters in the Installation Settings wizard.

    To set configuration parameters:

    Use the Set configuration parameters page in the Installation Manager wizard to create, modify, or delete configuration parameters.

    1. Do one of the following actions:

      • To create a new parameter, click New.

      • To change an existing parameter:

        1. Select the check box next to the parameter.

        2. Click Modify to change the parameter, or click Delete to remove the parameter.

    2. Click Apply to implement your changes.

    3. Do one of the following actions:

      • Click Previous if you want to make changes to previous settings.

      • Click Finish. The Installation log opens with a summary of the operations that you performed in the Installation Settings wizard.

    4. Click OK to finish.

    You now have to sign in to the Decision Center console. Continue with the section Publishing a project.


    Complete the configuration using Ant tasks

    These tasks perform the same configuration steps as the Installation Settings wizard in the Decision Center console.


    Set up the Ant tasks environment

    To run Decision Center Ant tasks, first set up the appropriate environment variables.

    When preparing to run Ant tasks, make sure that the following conditions are met:

    • You must have version 1.7.1 (or later) of Ant set up on your system. If Ant is not installed or your version is older than version 1.7.1, set up your environment to use the correct version of Ant.

      To test your current version of Ant, type the following command in a Windows Command Prompt or UNIX shell: ant -version

      You can download Ant from the Apache web site, or you can use the Ant 1.7.1 distribution packaged at...

        INSTALL_HOME/shared/tools/ant

    • Set WAS environment variables, including the WAS_HOME, WAS_LOGGING, and WAS_CLASSPATH...

        WAS_HOME/profiles/profile_name/bin
        . ./setupCmdLine.sh

    Communication between the Ant tasks and Decision Center supports the HTTP or HTTPS communication protocols.

    To set up your environment to use Ant:

    1. Set the ANT_HOME environment variable to INSTALL_HOME/shared/tools/ant.

    2. Add the directory INSTALL_HOME/shared/tools/ant/bin to your PATH environment variable.

    The Decision Center Ant tasks are defined in...

      <WODM_InstallDir>/teamserver/bin/build.xml

    ...and executed by commands of the form:

      ant <taskName> <parameters list>

    To execute these Ant tasks, use the same JVM version and vendor as the one used by the application server.

    Ant task parameters start with -D. Use them to set values such as the following ones:

    • -Dserver.url=server_url

      Specifies the URL of the target application server.

    • -DdatasourceName=data_source_name

      Specifies the JNDI name of the data source to use for the task. The default value is jdbc/ilogDataSource).


    Example

      ant execute-schema -Dserver.url=<protocol://host:port>/teamserver/ -DdatasourceName=jdbc/ilogDataSource -Dfile=my_sql_file.sql

    The <protocol://host:port> URL is defined in...

      <installDir>/teamserver/bin/teamserver-anttasks.properties

    If your browser is not running on the same host as the application server, replace localhost with the address of the machine. If your web application is mapped to a host on a port that is different from the port number shown, change the port number to your host port number.

    The file ODM_INSTALL/teamserver/bin/teamserver-anttasks.properties defines the value of some common parameters and others that depend on the application server used. You do not have to include these parameters in your Ant task command if they are properly defined in this file.

    The content of the teamserver-anttasks.properties file is as follows:

      # Default properties
      # ------------------------------------
      rtsAdmin.login=rtsAdmin
      rtsAdmin.password=rtsAdmin

      protocol=http
      server.host=localhost
      server.port=9080
      server.url=${protocol}://${server.host}:${server.port}/teamserver

      datasourceName=jdbc/ilogDataSource

      outputFile=output.sql

      languagePackPath = .
      languagePackOutputPath = ./generated

      persistenceLocale =
      selector =
      branch =
      override = false


    Create the database schema

    You can create the database schema in a single operation using the set-extensions Ant task or choose to create it step by step.


    Create the schema using the set-extensions Ant task

    For convenience, you can create the database schema using the set-extensions Ant task.

    Extensions to the Decision Center rule model are stored in two XML files. One of the files contains the model description itself (usually, the .brmx extension is used), and the second one contains data to initialize enumerations and hierarchies (usually, the .brdx extension is used). Use Ant tasks to load the rule model from the two XML files and build the SQL script required to get the proper database schema.

    For convenience, you can run the set-extensions Ant task, which runs gen-create-schema + execute-schema + upload-extensions + upload-roles, with these parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • -DextensionModel=<model file>

      The model description (.brmx extension).

    • -DextensionData=<data file>

      The model data description (.brdx extension).

    • [-DdbSchemaName=<database schema name>]

      An optional parameter that can be used to specify the database schema name. Decision Center uses the database user name as the schema name if this parameter is not specified. However, some databases allow for a given user to access several schemas, and the default schema is not always named as the user.

    • [-Droles=<role list>]

      An optional parameter that uploads the list of roles to Decision Center. This list is specified as "role1 role2". For example:

        ant upload-roles -Droles="rtsUser rtsConfigManager Eligibility Validator"

    Alternatively, you can create the database schema step by step, which is useful if you want to look at the generated SQL schema.

    To execute these Ant tasks, use the same Java™ Virtual Machine version and vendor as the one used by the application server.


    Create the schema using a step-by-step sequence

    To look at the generated SQL schema, you can create it step-by-step.


    Create the database schema script

    You can create the database schema script using the gen-create-schema Ant task. To create the SQL script required to create or update the database schema, run the gen-create-schema Ant task with these parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • -DextensionModel=<model file>

      The model description (.brmx extension).

    • -DextensionData=<data file>

      The model data description (.brdx extension).

    • [-DdbSchemaName=<database schema name>]

      An optional parameter that can be used to specify the database schema name in which the Decision Center tables are stored. Decision Center uses the database user name as the schema name if this parameter is not specified. However, some databases allow for a given user to access several schemas, and the default schema is not always named the same as the user.

    • [-DoutputFile=<SQL file>]

      The name of the file that stores the generated SQL script. If this parameter is not given, the task creates a file named output.sql in the directory defined as basedir in build.xml.

    For example:

    ant gen-create-schema -DextensionModel=my_model_file.brmx -DextensionData=my_data_file.brdx -DoutputFile=my_sql_file.sql

    The task connects to the given data source from the application server. The task checks if this data source points to an existing Decision Center database. If a database does not exist, the task builds the SQL script to create a fresh database schema to store the model. If a database does exist, the task builds the SQL script required to update the existing database schema.


    Executing the database schema script

    You execute the database schema script.

    To execute the SQL script that we created, run the execute-schema Ant task with these parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • [-Dfile=<SQL file>]

      The name of the file to execute, which corresponds to the script we created. If this parameter is not given, the task attempts to execute a file named output.sql in the directory defined as basedir in build.xml.

    For example:

    ant execute-schema -Dfile=my_sql_file.sql


    Uploading the database schema extension

    You upload the database schema extension.

    To store the rule model description in the database schema, run the upload-extensions Ant task with these parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • -DextensionModel=<model file>

      The model description (.brmx extension).

    • -DextensionData=<data file>

      The model data description (.brdx extension).

    ant upload-extensions -DextensionModel=my_model_file.brmx -DextensionData=my_data_file.brdx

    The description is stored in the database so that Decision Center applications can load it when they start. It is also used by gen-create-schema to get the current model description to run a diff with the new schema.

    In a cluster, restart the servers and close all current sessions.


    Uploading a list of roles or groups to the database

    In addition to creating groups in the application server when you set up security access, upload groups to the database.

    You must perform this task only if you want to use the Decision Center project access and permissions mechanisms.

    Add all the groups that you want to see in the available list when enforcing project security or setting permissions in Decision Center. Create the default groups for rtsUser and rtsConfigManager, and upload your custom groups.

    You do not have to upload the rtsAdministrator group or the rtsInstaller group. The Administrator group has access to everything and an Installer user must belong to another group.

    To store in the database the list of roles or groups to be used by the application, run the upload-roles Ant task with the following parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • -Droles=<role list>

      where <role list> is the list of roles or groups to upload to Decision Center, specified as "group1 group2".

    ant upload-roles -Droles="rtsUser rtsConfigManager Eligibility Validator"

    To execute these Ant tasks, use the same Java™ Virtual Machine version and vendor as the one used by the application server.


    Removing a database schema

    You can create an SQL script to remove (drop) a database schema using the gen-drop-schema Ant task.

    To remove a database schema...

    1. Create the SQL script required to remove the database schema.

    2. Execute the SQL script that we created.


    Create the SQL script

    To create the SQL script required to delete a database schema, run the gen-drop-schema Ant task with the following parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • -DextensionModel=<model file>: The description of the database schema to remove.

    • [-DdbSchemaName=<database schema name>]

      Use an optional parameter to specify the database schema name. If you do not specify this parameter, Decision Center uses the database user name as the schema name. However, in some databases, users can access several schemas and the default schema is not always named as the user.

    • [-DoutputFile=<SQL file>]

      The name of the file that stores the generated SQL script. If you do not specify this parameter, the task creates a file named output.sql in the directory defined as basedir in build.xml.

    ant gen-drop-schema -DextensionModel=my_model_file.brmx -DoutputFile=my_sql_file.sql


    Run the SQL script

    The task connects to the given data source from the application server. It reads the model description given in the parameters, and generates the SQL script required to remove the existing schema. Because many database tables are linked through foreign keys, these tables must be removed in a specific order and the script generation handles these constraints.

    To execute the SQL script that we created, run the execute-schema Ant task with these parameters:

    • -Dserver.url=server_url

    • -DdatasourceName=data_source_name

    • [-Dfile=<SQL file>]

      The name of the file to execute, which corresponds to the script that we created. If you do not specify this parameter, the task attempts to execute a file named output.sql in the directory defined as basedir in build.xml.

    ant execute-schema -Dfile=my_sql_file.sql


    Defining and uploading message files

    You can define and upload message files to Decision Center using the upload-messages Ant task.

    Message files contain the display text associated with the extensions to the rule model contained in the .brmx and .brdx files. For example:

    status=Status
    effectiveDate=Effective Date expirationDate=Expiration Date new=New
    defined=Defined

    The default messages file is provided in: ODM_INSTALL/teamserver/bin/defaultextensionmessages_<LOCALE>.properties

    The contents of the messages files must conform to the ISO-LATIN-1 standard.

    You must have a messages file for each locale that you use. Upload the messages file to Decision Center by running the upload-messages Ant task with these parameters:

    • -Dserver.url=server_url
    • -DdatasourceName=data_source_name
    • -Dlocale=<locale>
    • -DmessageFile=<message file>

    ant upload-messages -Dlocale=en_US -DmessageFile=mymessages.properties


    Configure the users of the Business console

    If you use the built-in governance mode, you can configure the users of the Business console by running an Ant task.

    Maintain the list of users to keep it consistent with the users that are defined in the application server.

    The default way to configure the users is to add them to the Decision Center database by running the upload-users Ant command. The command uploads the names that are in an XML file.

    Use the following format for the names:

    <Users>
     <User><LoginId>user1</LoginId></User>
     <User><LoginId>user2</LoginId></User>
    </Users>

    For an example user file, see...

      InstallDir/teamserver/tutorials/fileusers.xml

    Specify the following parameters for the upload-users command:

    -DuserFilePath=path_to_the_XML_file
    -DserverURL=server_url
    -Dusername=username
    -Dpassword=password
    -DdatasourceName=datasource


    Example

      ant upload-users -DuserFilePath=C:\my_path\my_users.xml -DserverURL=my_url -Dusername=rtsAdmin -Dpassword=rtsAdmin -DdatasourceName=my_datasource


    Set the persistence locale

    The persistence locale is used to determine the language in which rules are stored in the Decision Center database.

    The persistence locale is set when deploy the Decision Center archive to the application server, which means that the rules in the database are stored in the locale of the Decision Center application.

    Changing the persistence locale does not change the language in which rules display in Decision Center. Changing the persistence locale in Decision Center is necessary only to match the locale of Rule Designer when synchronizing your rule projects, and to access the tutorials in your locale.

    You must not change the persistence locale after you have saved a rule to the database.

    To set the persistence locale by running an Ant task:

    1. Open the InstallDir/teamserver/bin/teamserver-anttasks.properties file, which defines the value of some common parameters.

    2. Add your locale to the persistenceLocale property and save the teamserver-anttasks.properties file.

      For example: persistenceLocale = fr_FR

    3. Run the Ant task using the form: ant taskName parameters_list

      Alternatively, you can add the parameter to the command line. For example: ant taskName -DpersistenceLocale=fr_FR


    Adding or removing configuration parameters

    Many tasks related to customizing Decision Center require configuration parameters to be added or removed.

    The following configuration parameters, used to generate complete URLs in permalinks, are generated the first time you sign in to Decision Center after configuring the database. Use the Installation settings wizard to set these beforehand or change them afterwards:

    • teamserver.server.port

      The port number.

    • teamserver.server.isSecure

      True if the connection is secure.

    • teamserver.server.hostname

      The name of the host.

    The following table gives a description of the main configuration parameters available in...

      teamserver.war/WEB-INF/lib/teamserver-model-XXX.jar/ilog/rules/teamserver/preferences.properties

    Parameter Use
    teamserver.<extractorValidator>.class Specify a ruleset extractor validator class to use for the given extractorValidator name. The class must implement the IlrExtractorValidator interface. After this class has been defined, specify this name as the extractor validator to use when defining a ruleset extractor.
    teamserver.build.path Define where the cache of the IRL is located on the file system. The path is computed as follows: first, use this property with the name of the user who launched the server as the root for the cache (<build.path>_username). If it is not defined, use the system property java.io.tmpdir and add rtscache (for example, <temp dir>/rtscache_username). If the system property is not defined, use the server directory and add rtscache (for example, <server dir>/rtscache_username).
    teamserver.brl.verbalizers List of locales for which a BAL verbalizer is defined.
    teamserver.brl.verbalizer.<locale> Verbalizer class for the given locale. The class must implement the IlrVerbalizer interface.

    The following Ant tasks can be used to add or remove configuration parameters:

    set-config-param Set configuration parameter for a given user. If the user not specified, set a global parameter.

    • -Dserver.url=server_url
    • -DdatasourceName=data_source_name
    • [-Duser=username]
    • -Dkey=parameter_key
    • -Dvalue=<parameter value>

    For example:

    ant set-config-param -Dkey=locale -Dvalue=en_US

    remove-config-param Drop configuration parameter for a given user. If user is not specified, drop global configuration parameter.

    • -Dserver.url=server_url
    • -DdatasourceName=data_source_name
    • [-Duser=username]
    • -Dkey=parameter_key

    print-config-param Print global parameters. If username, print for user. If no key is specified, all keys are printed.

    • -Dserver.url=server_url
    • -DdatasourceName=data_source_name
    • [-Duser=username]
    • -Dkey=parameter_key


    Repackaging the Decision Center archive

    You can repackage the Decision Center archive using an Ant task.

    Add new .jar files to the Decision Center archive by running the repackage-ear or repackage-war Ant task with these parameters:

    • -DtargetEar=<target ear> or -DtargetWar=<target war>

    • -DsourceEar=<source ear> or DsourceWar=<source war>

    • -DdescriptorsDir=<descriptors directory>: A directory that is copied into the META-INF directory of the target EAR (not mandatory).

    • -DadditionalJars=<"myjar1.jar,myjar2.jar, myjarn.jar">: Additional .jar files to store in the lib directory of the target archive (not mandatory).

    • -DtmpDir=<directory>: A directory that can be specified to store temporary files (not mandatory).

    • -DwebResourcesDir=<web resources directory>: A directory that is copied into the WAR library (not mandatory).

    • -Dconsole=both|enterprise|business: Specifies whether to repackage the Business or Enterprise WAR files. The default is both.

    This task does not use the server.url and datasourceName parameters. If you have customized Decision Center package the custom .jar files before you repackage the Decision Center archive using this task.


    Additional steps to configure the Decision Center Business console

    The search function in the Decision Center Business console is based on the Solr search engine. You must configure the engine to provide this functionality.


    Use a remote Solr search engine

    You set up the search function in Decision Center Business console to work with a remote instance of the Apache Solr search engine.

    The search function in Decision Center Business console uses an embedded instance of the Apache Solr search engine. Alternatively, you can have the search function work with a remote instance of the search engine, which you can run on another computer, or the same computer but in a dedicated web application.

    To configure the search function to run with a remote instance of the Solr search engine:

    1. Install the Apache Solr search engine on another computer, or as part of a dedicated web application on your computer. (For information on installing the Solr server, visit the Apache Solr web site.)

    2. Locate the decisioncenter-solr-home.zip file in the Decision Center teamserver folder on your computer. (The Decision Center installation program placed the folder on your computer.)

    3. Unzip the file in a directory in the remote instance of the Solr server.

    4. Configure the home directory of the remote Solr server to use the location of the unzipped configuration files (see documentation on the Apache Solr web site).

    5. Configure the Decision Center preferences.properties file to point to the URL of the Solr server.


    Set parameters for the Solr search engine

    Configure the search function in the Decision Center Business console to run with the Apache Solr search engine.

    Decision Center Business console provides a function for searching rule projects. When you install this feature, it uses an embedded instance of the Apache Solr search engine. Alternatively, you can have the search function run with a remote instance of the search engine, which you can install on another computer, or the same computer but in a dedicated web application (see Use a remote Solr search engine).

    There are three parameters to set for the search engine:

    Parameter Description
    search.SearchProvider
    SolrEmbedded Select the embedded Solr search engine.
    SolrRemote Select a remote instance of the Solr search engine.
    search.SolrEmbeddedDataDir Direct the index of the embedded version (SolrEmbedded) to a specific directory on the Decision Center.
    search.SolrRemoteUrl Use with SolrRemote to provide the URL of the remote Solr search engine.

    You set the configuration parameters for the search engine within the preferences.properties file for Decision Center.

    The following table provides examples for setting the parameters in preferences.properties to work with the Solr search engine:

    Solr server Parameter settings

    External server

    (The URL of the external server depends on the installation. For this example, the remote address of the search engine is http://mysearchserver:8983/solr.)

    Set the preferences.properties file as follows:

    search.SearchProvider=SolrRemote
    search.SolrRemoteUrl=http://mysearchserver:8983/solr

    Embedded server (In this example, you store the index in the c:/temp/DC-SearchIndex directory on your computer.)

    Set the preferences.properties file as follows:

    search.SearchProvider=SolrEmbedded
    search.SolrEmbeddedDataDir=c:/temp/DC-SearchIndex

    If you do not specify a directory for search.SolrEmbeddedDataDir, Decision Center stores the search index in a temporary directory. When the server stops running, it also stops using the temporary directory. When the server restarts, it creates a new temporary directory, and completely reindexes the repository.

    If you specify a directory for search.SolrEmbeddedDataDir, the directory and its content persist across server restarts, and the server does not reindex the repository with each restart.


    Additional steps to configure Decision Validation Services

    Optionally, you can deploy, configure, and test Decision Validation Services to complement your Decision Center configuration on WAS.

    Before following the instructions to deploy and configure Decision Validation Services, install the following elements:

    1. Install Rule Designer (Optional).
    2. Install Rule Execution Server and Decision Center, and configure both of these applications.

    On WAS, Decision Validation Services uses the default Work manager wm/default to run simulations and tests in managed threads. Therefore, make sure that it is defined in the application server where you configure Decision Validation Services.


    What steps to follow

    The following table summarizes the steps to configure Decision Validation Services.

    Step Required

    Step 1: Create Decision Warehouse database resources

    If you have used the Rule Execution Server console to create database resources, you do not have to perform this task.

    Optional

    Step 2: Deploy the Decision Validation Services archive

    This archive is the default SSP archive packaged with the installer.

    Optional. Do this step if you want to check the availability of the feature. You can also use the default archive if you have an XML XOM in which case the SSP archive does not have to be repackaged.
    Step 3: Checking the availability of Decision Validation Services Optional
    Step 4: Package Decision Validation Services using Ant Optional
    Step 5: Redeploy the Decision Validation Services archive X


    Step 1: Create Decision Warehouse database resources

    Use SQL scripts to create a dedicated schema in the database.

    If set the Rule Execution Server persistence to datasource or jdbc and you intend to use Decision Warehouse to store your test execution results, create a dedicated schema in the database containing these tables and views. To do so, you can use the provided SQL scripts, located...

      ODM_INSTALL/executionserver/databases

    A readme file in this directory provides additional information about the scripts. The script that creates the Decision Warehouse database schema is named...

      trace_db_name.sql

    The Installation Settings wizard in the Rule Execution Server console creates all the required tables for Rule Execution Server and for Decision Warehouse. If you are configuring Decision Validation Services and you have already run the Installation Settings wizard to create the tables, you do not have to create database resources manually. However, if you did not use the wizard to create database resources, run the script to create the Decision Warehouse database schema.

    When you use DB2, the scripts that create the Rule Execution Server database tables are written for databases that use automatic storage.

    • BP32K is the buffer pool that is expected in SYSCAT.BUFFERPOOLS. If BP32K is not there, you can use the existing buffer pool or create a new buffer pool named BP32K. Use the following command to query SYSCAT.BUFFERPOOLS for the existing buffer pool:

        Select * from SYSCAT.BUFFERPOOLS

      Otherwise to create a buffer pool named BP32K:

        CREATE BUFFERPOOL BP32K SIZE 2000 PAGESIZE 32K

    • You must update the trace_db2.sql script and select the custom option in the Installation Settings wizard to run it. Modify the following line in the script to specify storage for the table space:

        CREATE TABLESPACE RESDWTS PAGESIZE 32K BUFFERPOOL BP32K;

      Here is an example of the table space specification in the script:

      CREATE TABLESPACE RESDWTS PAGESIZE 32K  MANAGED BY Database USING [ FILE 'C:\DB2\Container.file' 640 ] BUFFERPOOL  BP32K;

    • You might have to further modify the script based on your database settings.

    If you completed this task as part of the Rule Execution Server configuration, you do not have to do this a second time. It is included here solely for completeness.

    If you use Command Editor to run the scripts, log in with the credentials that you use for the data source for Rule Execution Server.

    Use any tool that can handle SQL to import and run the SQL scripts.

    Database Database tool
    IBM DB2 DB2 command line processor
    Derby ij command line processor
    MySQL mysql command line processor
    Oracle sqlplus command line processor
    Postgre SQL Postgre SQL command line tool
    SQL Server Query Tool
    Sybase isql command line processor

    To access the database, the database user must have the following credentials:

    • A user ID and a password

    • Complete privileges on the tables and view of the schema (create, insert, delete)

    • Create index privileges

    • On Oracle, create trigger and create sequence privileges

      When using an Oracle database, run all the scripts in the SQL Plus client.

    Install a database client for the database that you use.

    The default CLOB size might not be sufficient for the FULL_EXECUTION_TRACE field in the EXECUTION_TRACES table. You might need a size qualifier if SQL raises exceptions with reason code...

      <Lob-Value>


    Deploy the Decision Validation Services archive

    This procedure deploys the default SSP archive packaged with the installer. Deploy the default SSP EAR to check the availability of the feature and to test rules if you have an XML XOM. An XML XOM is included in the ruleset archive inside a RuleApp, and therefore the SSP EAR does not have to be repackaged to include the XOM.

    The archive must be deployed on the same server as the XU.

    1. Open the Integrated Solutions Console and open... Applications | Websphere Enterprise Applications | Install | Local file system

      Browse to the following file...

        InstallDir/executionserver/applicationservers/WebSphere8/jrules-ssp-WAS8.ear

      ...and then click Next.

    2. Select the check box...

        Detailed - Show all installation options and parameters

      Expand Choose to generate default bindings and mappings and select the check box Generate Default Bindings. Click Next.

    3. Click Continue to accept the security warning.

    4. In Step 1 through Step 8 click Next to accept the default settings.

    5. In Step 9 if you have activated security select resAdministrators and click Map groups.

    6. Click Search.

    7. Select the resAdministrators group. To do this, click the group name under Available, then click the arrows to move it to the Selected column.

    8. Click OK to return to the Map security roles to users or groups page.

    9. Repeat Steps 8 to 11 for the resDeployers group, selecting resDeployers.

    10. Click Next.

    11. Click Finish. After the installation has completed click Save directly to the master configuration.

    12. In the side panel, open Applications  > Application Types > WebSphere enterprise applications, and click jrules-ssp-WAS7.

    13. Click Manage Modules.

    14. Click Scenario Service Provider.

    15. Under General Properties, for Class loader order select Classes loaded with local class loader first (parent last).

    16. Click OK.

    17. Click OK and Save directly to the master configuration.

    18. In the side panel, open Applications  > Application Types > WebSphere enterprise applications.

    19. In the Enterprise Applications page select the check box next to jrules-ssp-WAS8 and click Start to start the application.


    Step 3: Checking the availability of Decision Validation Services

    A specific testing URL is designed for you to check the rule session type, DAO factory class for trace persistence, the class used to cache the Decision Validation Services job, and the pool size for asynchronous execution.

    To check the availability of Decision Validation Services:

    1. Enter the URL http://<host>:<port>/testing in a web browser.

    2. Log in to the (Scenario Service Provider) SSP application using a Rule Execution Server role.

      The application displays a home page, which contains information about the SSP server.

    Version

    The version of Decision Server used.

    Patch level

    The patch level of Decision Server used.

    License information

    The type of license of this version.

    RuleSession

    The RuleSession type (POJO or J2SE).

    DAO Factory Class

    The DAO (Data Access Object) Factory class used to persist the trace into the data warehouse.

    Job store class

    The name of the class used to persist the Decision Validation Services job into a cache to free the memory during long computations.

    Job pool size

    The size of the pool for the asynchronous execution.

    Started since

    The time and date when the SSP started.

    Jobs currently running

    The About screen provides information about the jobs currently running after you run Decision Validation Services in Decision Center:

    • A Job ID is listed in the table when a user clicks Run in Decision Center.

    • The Created column records the date and time when each job is initialized.

    • The Status column shows the number of scenarios that have already been tested compared to the total number of scenarios.

    • The Start time records the time when a resource is allocated for the job.

    • The Parts column records the number of parts in the job:

      • A job that is not executed in parallel has one part.

      • A job that is executed in parallel has one or more parts.

    • The End time records the time when the execution of the job is complete, that is, all of the scenarios in the job have been tested.

    The report for the job is automatically downloaded by Decision Center at the end of the execution. If the scenario suite is run in the background, the user downloads the report by viewing the list of scenario suites, and then clicking the report link when it becomes available. After the report is viewed, the job is removed from the table. The job remains in the table until the report is downloaded.


    Step 4: Package Decision Validation Services using Ant

    You can configure Decision Validation Services archives by using an Ant task. This section is for users installing on Windows and other supported distributed platforms only.

    You can configure Decision Validation Services archives by running the ssp-setup Ant file.

    1. Define the Ant task in your build file using Ant element...

        <taskdef>

      ...in one of the following ways...

      • Define the task at the top level, or within a specific target:

          <taskdef resource="res-tasks.properties" classpath="${InstallDir}/executionserver/lib/jrules-res-setup.jar"/>

      • If the JAR file is available in your system, you can use:

          <taskdef resource="res-tasks.properties"/>

    2. Use the...

        lt;ssp-setup> Ant task to update an SSP artifact to your specific configuration and XOM.

      • Run the Ant task in one of the following ways:

        • From the command line: Execute Ant in the required directory, followed by the name of the build file if necessary.

        • From Eclipse: Right-click the Ant file and click Run.


    Step 5: Redeploy the Decision Validation Services archive

    How to redeploy the Decision Validation Services archive.

    This step shows you how to redeploy the Decision Validation Services archive. The archive must be redeployed on the same server as the XU. Use this procedure to redeploy the default SSP archive packaged with the installer or any subsequent deployment of a repackaged archive. Redeploy the default SSP EAR if you want to check the availability of the feature. You can also redeploy the default SSP EAR and use this to test your rules if you have an XML XOM. An XML XOM is included in the ruleset archive inside a RuleApp, and therefore the SSP EAR does not have to be repackaged to include the XOM.

    To redeploy an SSP archive (an archive has already been deployed):

    1. Open the Integrated Solutions Console.

    2. In the side pane, open Applications and click Websphere Enterprise Applications.

    3. Select the deployed SSP application in the side pane and click Uninstall.

    4. Click OK to confirm uninstallation of the SSP application.

    5. Click Save

    6. Follow the previous procedure in Step 2: Deploy the Decision Validation Services archive to deploy the new SSP.


    Troubleshooting

    In case of problems or poor performance, you can allocate more memory to the applications.


    Configure ODM on Java SE


    Configure Rule Execution Server on Java SE

    On the Java™ SE platform, the execution unit (XU) is deployed as a simple Java Standard Edition JAR file. This deployment implements a lightweight J2C container, which uses the ODM pooling infrastructure. The resource is scoped to a client application.


    Before you configure Rule Execution Server on Java SE

    Some limitations affect the installation of Rule Execution Server on Java™ SE.

    On Java SE platforms, if the management stack is not used on the same Java virtual machine (JVM) and the same JMX MBean server, instances of the execution unit (XU) can connect to a TCP/IP server so that you can monitor and manage them through the Rule Execution Server console.

    Typically, you install Rule Execution Server in the following steps:

    1. Set the class path for Java SE.

    2. Change the persistence mode. If necessary, create your database and SQL table and JDBC access with JNDI lookup.

    The following limitations apply to rule sessions:

    • The execution unit (XU) is not shared. Therefore, it consumes more memory.

    • Connection pools are configured only through the ra.xml deployment descriptor.

    • Java SE supports only rule sessions are available, but supports no EJBs or message-driven rule beans (MDB) execution components. This restriction has the following consequences:

      • No remote call to Enterprise JavaBeans (EJB) from the client
      • No support of Java Message Service (JMS)
      • No transaction support: implement your own transaction management logic as EJB does.


    Set the class path for Java SE

    You must configure Rule Execution Server for Java SE by setting its class path in your Ant script.

    1. Set the executionserver.home property:

        <property name="executionserver.home" value="InstallDir/executionserver"/>

    2. Import the classpath-executionserver.xml file:

        <import file="${executionserver.home}/lib/classpath-executionserver.xml"/>

    3. Set the path for the executionserver.j2se.classpath property.

      The executionserver.j2se.classpath property defines all the JAR files that are necessary to execute Rule Execution Server on Java™ SE.


    Change the persistence mode

    Change the persistence mode.

    To change the persistence mode, modify the resource adapter descriptor file, then add it to your class path.

    The deployment descriptor includes comments to help you configure the file to your needs. The properties to change to modify persistence are:

    • persistenceType

    • persistenceProperties

    For information on creating archives configured with a persistence type, refer to the ressetup.xml Ant script.

    1. To change the execution stack from the default file persistence modify the resource adapter descriptor file ra.xml located in:

      InstallDir/executionserver/bin

    2. After you have configured this file, add it to your class path. At run time, ra.xml overrides the default_ra.xml file provided in jrules-res-execution.jar.


    Database driver issues

    The JDBC Not Bound error message is issued when an error occurs during the creation of the data source.

    Refer to the traces to locate the original cause. In the vast majority of cases one of the following is likely:

    • A directory does not exist or cannot be read or written to (Derby).
    • There is a missing schema or table.
    • There are missing privileges to access the database resource.


    Verify your configuration of Decision Center

    You can start using Decision Center after you have deployed the Decision Center archive.


    Publishing a project

    After completing the configuration, Decision Center is ready to be used but does not contain a rule project. You have to publish a rule project from Rule Designer. To carry out the tutorials found in the Decision Center online help, you have to publish the following rule projects from Rule Designer:

    • loanvalidation-rules (with loanvalidation-xom)
    • loanvalidation-rules-dependent
    • squery-loanvalidation-rules (with squery-loanvalidation-xom)

    To open Rule Designer, click Start > All Programs > IBM > package_group > Rule Designer.

    To import the projects for the Decision Center tutorials:

    1. In Rule Designer click File > Import > General > Existing Projects into Workspace, and click Next.

    2. Click Select root directory, browse to...

        InstallDir/studio/tutorials/shared

      ...and click OK.

    3. Select the projects and click Finish.

    4. Then publish them to Decision Center.


    Publishing the projects for the Decision Center tutorials to Decision Center

    After importing a project for Decision Center, you publish them to the server.

    To publish projects to the Decision Center:

    1. In Rule Designer, right-click the loanvalidation-rules rule project, and click Decision Center > Connect.

    2. Complete the Decision Center Configuration dialog as follows. The warning message Connection not established displays until you establish the connection.

      User name rtsAdmin
      Password rtsAdmin
      URL http://setgetweb.com:<port>/teamserver

      If your browser is not running on the same host as the application server, replace localhost with the address of the machine. If your Web application is mapped to a host on a port that is different to the port number shown, change the port number to your host port number.

      Data source Leave this field empty.

      • If security is enabled, use https://setgetweb.com:port/teamserver.

      • If you are working with the Decision Center Business Console, the default URL is http://setgetweb.com:port/decisioncenter.

    3. Click Connect.

      The connection is established when the warning message closes and the Project configuration area becomes active.

    4. In the Project configuration area, check that Create a new project on Decision Center is selected, and then click Finish.

    5. The Synchronize Complete - Decision Center Participant dialog opens when the publishing process is complete. Click OK to close this dialog.

    6. A dialog opens asking you if you want to change to Team Synchronizing perspective. Click Yes.

      An empty Synchronize view opens, indicating that the projects in Rule Designer and Decision Center are the same. This means that your rules are now published to Decision Center.


    Open the Decision Center Enterprise console

    To open Decision Center console...

      http://setgetweb.com:port/teamserver

    If security is enabled...

      https://setgetweb.com:port/teamserver

    Default the data source is...

      jdbc/ilogDataSource

    To specify a different data source, pass as a request parameter in the URL...

      http://setgetweb.com:7001/teamserver?datasource=jdbc/serverextendedbrm.

    Default locale is English. To specify a locale...

      http://setgetweb.com:<port>/teamserver?locale=es

    This assumes message files are localized.

    If you sign in with another locale in the URL and want to change the locale afterward, click Options in the top banner. This saves the locale and restores it the next time you sign in.

    If you open Decision Center but no database exists, you automatically access the Installation Settings wizard with only the Install tab available.

    After completing the installation, Decision Center is ready to use but does not contain a rule project. When you open Decision Center at this point, you see the Configure tab with a message that Decision Center cannot find a project, and you should publish a rule project with Rule Designer or contact your administrator.

    If you see this message, you have to publish a rule project from Rule Designer.

    This message also has a link to Run diagnostics.


    Run the Decision Center Enterprise console diagnostics

    You can verify that the Decision Center Enterprise console has been successfully deployed and configured by running the diagnostics.

    1. Sign in to the Decision Center Enterprise console.

    2. Click the Configure tab.

    3. Click Diagnostics.

      You see a report showing all the diagnostic tests that have just been run. A check mark is shown next to each check. Click Expand All to show details about all checks.


    Open the Decision Center Business console

    To open the Decision Center Business console...

      http://setgetweb.com:port/decisioncenter

    If security is enabled, use...

      https://setgetweb.com:port/decisioncenter

    Default data source is...

      jdbc/ilogDataSource

    To specify a different data source, it as a request parameter in the URL...

      http://setgetweb.com:7001/decisioncenter?datasource=jdbc/serverextendedbrm

    Default locale of the sign-in page is English. To specify a locale parameter...

      http://setgetweb.com:<port>/decisioncenter?locale=es

    This assumes message files are localized.

    To change locale after signup, click Options in the top banner. This saves the locale and restores it the next time you sign in.


    Configure Rule Execution Server in shared mode

    You can configure Rule Execution Server so that client applications can share the same deployed execution unit (XU) resource.

    The execution object model (XOM) in the database contains only dynamic classes, that is, classes that do not necessarily map to Java™ classes on a one-to-one basis.

    Both Java and EJB rule sessions work with XOMs that contain EJBs, that is, rules that use EJB objects.

    1. Configure the application for the operational environment by modifying the deployment descriptor.

    2. Change or redirect the bindings used in the execution components to the real JNDI names of the application servers.

      Java EE applications use JNDI as the "switchboard" for making connections between loosely coupled components. Java EE components use JNDI to find other components that they want to use, such as EJB components, and to find resources, such as JDBC and JMS connections. You define interconnections between Java EE components by declaring them in the deployment descriptor of the component. The container automatically binds the objects at the specified place in the namespace and ensures that all resource dependencies between components are satisfied before deploying the components.

      You can map the names used inside the execution components to real JNDI names.

    3. Verify that the contents of the Java EE application EAR or WAR file are

      well formed and comply with the Java EE specification.

    4. Deploy the EAR file or WAR file onto the Java EE server.


    What to do next

    In the following figure, the components shown in green are not provided by ODM. Therefore, you need to develop those components. The Java EE rule session types are available and configure these components so that they integrate with the execution unit (XU).

    The XU is deployed on the application server and shared by all the applications deployed to the server. It works in a similar way to installing a device driver on an operating system, in that the application server is globally enhanced with ruleset execution capabilities. You can easily upgrade, start, stop, and monitor the XU using the application server management console or other tools. You must deploy the XU onto all the nodes of a cluster.


    Configure Rule Execution Server in scoped mode

    You can configure Rule Execution Server so that it is scoped to a single Java™ EE application. In this use case, Rule Execution Server is scoped exclusively to a single application. The execution unit (XU) is deployed within a single application. With this deployment option, you can deploy multiple applications to the same server.

    If you package the Rule Execution Server XU resource archive (RAR) file in your enterprise application (EAR), applications that use a previous version of ODM or multiple applications that use the current version of ODM, or both, can coexist in the same Java Virtual Machine (JVM).

    1. Write and compile the source code, including the basic tasks of the client, and your business logic.

    2. Specify the deployment descriptors.

    3. Package the .class, .jsp, and .html files, deployment descriptors, and the Rule Execution Server .rar file into a Java EE application EAR file. Do not modify the RAR.

    4. Declare the RAR module inside the application.xml file, as follows:
      <application>
          ....
          <module>
              <connector>jrules-res-xu-<appserver>.rar</connector>
          </module>
          ....
      </application>

      Use the class IlrPOJOSessionFactory as you do to deploy the XU to a server.

      It is also possible to package the rule session JAR in the same Java EE application EAR file. In this case, the application uses the local EJB binding and you do not have to define the JNDI name in the application server EJB descriptor file (ejb-jar.xml). The global JNDI tree is used to resolve external references, but it is not necessary to resolve a JNDI name relative to the component environment java:comp/env.

      If your descriptor contains <ejb-local-ref>, the JNDI lookup uses the value defined in attribute...

        <ejb-link>

      ...to find the EJB. There is no confusion with other EJBs deployed in other EAR files and no issue with mixed class loaders.

      In the deployment phase of the EAR file, create a Java 2 connection factory (J2C). This step is necessary to add the JNDI name of the resource adapter.

      If you package a rule session factory inside an application EAR, you can remove the JNDI definitions from the rule session JAR.


    Configure Rule Designer in Eclipse

    During the installation of ODM in Installation Manager, you can extend an existing Eclipse. If you have not done so at installation time, you can use the update sites provided in the distribution to extend the Eclipse environment by adding the Rule Designer plug-ins.

    1. Define the variable to the Decision Server installation directory. Edit...

        ECLIPSE_HOME/configuration/config.ini

      ...and add the IBM_DS_HOME property

      The installation directory contains the components for Decision Server such as executionserver and studio.

      For example...

        IBM_DS_HOME=C:/Program Files/IBM/ODM801

      You can copy this property from the configuration/config.ini file provided with the installation of Decision Server.

    2. Start Eclipse

        Window | Open Perspective | Java | Help | Install New Software.

    3. Add the sites to install:

      1. In the Install wizard, next to the Work with field, click Add.

      2. In the Add Repository dialog, click Archive.

      3. Browse to...

          InstallDir/studio/update-sites

      4. Click Open, and select designer-base-update-site.zip.

      5. In the Name field, enter a name for the site, and then click OK.

        This might take a few seconds.

      6. Proceed the same way to add the rule-designer-update-site.zip update site.

    4. In the Work with field, select...

        All Available Sites

    5. Expand the Business rules and events category, and select both...

      • IBM Decision Server Designer Base
      • IBM Decision Server Rule Designer

    6. Click Next.

      Eclipse calculates the dependencies and requirements.

    7. In the Install dialog, click Next, select I accept the terms of the license agreement, and click Finish.

      The installation may take a few seconds to complete. If a security warning about the validity of the software opens, click OK to proceed with the installation.

    8. Click Restart Now if you are prompted to restart Eclipse.

    You can also install the following update sites the same way. These update sites are optional:

    • IBM Decision Server Rule Designer Samples:
      • rule-designer-samples-update-site.zip

    • IBM Decision Server Scorecard Modeler:
      • scorecard-update-site.zip

    • IBM Decision Server COBOL management update sites:
      • cobol-importer-license-update-site.zip
      • cobol-importer-update-site.linux.zip (for installation on Linux)
      • cobol-importer-update-site.win32.zip (for installation on Windows)
      • cobol-update-site.zip

    You can check what you have installed by clicking...

      Help | Install New Software | What is already installed?

    For Rule Designer in an Eclipse environment that uses a non-English locale:

    • The Eclipse messages remain in that language.
    • If Rule Designer provides the verbalizer for the language, you can create rule artifacts in this language. If not, rule artifacts created are in English.
    • Rule Designer messages appear in the non-English locale if it is supported, otherwise they appear in English.
    • To change the locale so everything is in English, add property osgi.nl=en_US property to Eclipse_Install/configuration/config.ini file, then restart Rule Designer.


    Change the JVM used by Rule Designer

    On Windows, by default the ODM installer installs the IBM JVM with Rule Designer. You can select a different JVM during or after installation. On UNIX, select a JVM during installation.

    You can change the JVM used by Rule Designer on an existing installation of ODM. The Rule Designer shortcut runs Eclipse using the JVM specified in...

    You can also use the -vm and -vmargs in the command line of the eclipse.exe file.

    To run on Sun Hotspot Virtual Machines, Rule Designer needs a PermGen size of at least 128 MB. Use the --launcher.XXMaxPermSize parameter.