Setting up cache notification

Edit the .conf.yaml configuration file to enable cache notification so that the cache is notified of events that occur in WebSphere® Service Registry and Repository (WSRR).

About this task

WSRR publishes notification events by using WebSphere Application Server. Cache notification allows the cache to subscribe to these events.

To set the WSRR parameters, you must edit the WSRRConnectorProvider entries in the ConnectorProviders section of the node.conf.yaml or server.conf.yaml configuration file. When you create a new integration node or a new independent integration server, the .conf.yaml configuration file contains the following subset of the WSRR parameters. All the other WSRR parameters have default settings which generally do not need to be changed. If you need to change any of the other WSRR parameters, you must add them to the .conf.yaml configuration file.


ConnectorProviders:
    #WSRRConnectorProvider:    # Requires the optional WSRR component install
    #endpointAddress: 'https://host:9443/WSRR8_0/services/WSRRCoreSDOPort'   # WSRR server endpoint url
    #needCache: true                                                         # enable WSRR cache
    #predefinedCacheQueries: ''                                              # semicolon-separated XPath querys to initialize WSRR cache at start-up
    #enableCacheNotification: false                                          # enable WSRR cache notification
    #locationJNDIBinding:  'iiop://host:2809'                                # WSRR cache WAS JMS provider JNDI bindings url

To enable cache notification, complete the following steps to change the relevant properties in the .conf.yaml configuration file, and to add a user ID and password if you are connecting to a secure WebSphere Application Server. Any properties that you set for the integration node, in the node.conf.yaml file, are inherited by the integration servers that it owns. However, you can change any of the integration server properties by modifying them in the appropriate server.conf.yaml file. For more information about configuring integration servers that are managed by an integration node, see Configuring an integration server by modifying the server.conf.yaml file.

Procedure

Set the enableCacheNotification property value to true in the .conf.yaml configuration file:

enableCacheNotification: true # The default value is false. Select true to enable IBM® App Connect Enterprise WSRR Cache Notification.

Set the locationJNDIBinding property to the value that you require for your WSRR server in the .conf.yaml configuration file:

For example:

locationJNDIBinding: 'iiop://host_name:2809/' # The URL to the WebSphere Application Server JMS provider JNDI bindings. The default value is iiop://host_name:2809/

When you use WebSphere Application Server Version 8.0 or later, the default IIOP secure setting is SSL-Required. Therefore, if you connect to your server without changing this option to SSL-Optional, you must configure the sas.client.props and the ssl.client.props files in the following way:

sas.client.props

- Set com.ibm.ssl.alias=AnotherSSLSettings
- Set com.ibm.CORBA.loginSource=properties

ssl.client.proprs

-- Use the AnotherSSLAlias template that is already in the file, but comment ou the DefaultAlias Keystore and Truststore information to prevent it affecting the current configuration
-- Comment out the KeyStore part of the 'another SSL Alias' because the TrustStore is the only one that is required:
- Set com.ibm.ssl.enableSignerExchangePrompt=false in all scenarios

Set the secureJNDIPropertiesFiles property in the .conf.yaml file to point to the directory where your .props files are stored.
For example:
```
secureJNDIPropertiesFiles: 'C:\SSLPropsFiles' #  The directory where your .props files are stored. For example C:\SSLPropsFiles.
```

If you are connecting to a secure WebSphere Application Server, you must use a user ID and password. To set the user ID and password complete one of the following steps:

Optional: Set the user ID and password by using the mqsisetdbparms command:
1. If the integration node is running, stop it by using the mqsistop command.
2. Issue the mqsisetdbparms command to set up your user ID and password.
  For example:
```
mqsisetdbparms INODE -n jms::DefaultWSRR@jms/SRConnectionFactory 
-u userid -p password
```
  where:
  -n specifies the name of the data source
  (in this case, jms::DefaultWSRR@jms/SRConnectionFactory is used.
  You can also use wsrr)
  -u specifies the user ID to be associated with this data source
  (in this case, userid)
  -p specifies the password to be associated with this data source
  (in this case, password)
3. Restart the integration node by using the mqsistart command.
Optional: Set the user ID and password by using the mqsicredentials command:
1. If the integration is running, stop it by using the mqsistop command.
2. Issue the mqsicredentials command to set up your user ID and password.
  For example:
```
mqsicredentials --work-dir --create --credential-type jms --credential-name wsrr@jms/SRConnectionFactory --vault-key 12345abcde --username jmsvaultuser --password jmsvaultpwd 
-u userid -p password
```
  where:
  --work-dir specifies path to the work directory that is used by an independent integration server.
  --credential-type specifies the resource that requires credentials for access.
  (in this case, jms)
  --credential-name specifies the vault key that is used to access the vault where the credential is stored.
  --vault-key specifies the vault key that is used to access the vault where the credential is stored.
  --username specifies the user ID to be associated with this resource.
  --password specifies the password to be associated with this resource.
3. Restart the integration node by using the mqsistart command.