Installation
Note: The installation instructions that follow assume that the Oracle Utilities Network Management System Web Gateway component has been installed. Refer to the Oracle Utilities Network Management System Installation Guide for complete instructions.
Installation Overview
The Oracle Utilities Network Management System MultiSpeak Adapter is delivered as five files:
• $NMS_BASE/dist/install/nms-multispeak.ear.base: NMS MultiSpeak adapter application.
• $NMS_BASE/sdk/java/lib/multispeak-4.1.0.jar: Java classes generated from MultiSpeak 4.1.0 WSDLs.
• $NMS_BASE/sdk/java/lib/nms-multispeak-sdk-1.12.0.1.0.jar: Java classes needed to build custom plugins.
• $NMS_BASE/sdk/java/docs/nms-multispeak-docs.zip: Documentation (javadoc) for classes included into multispeak-4.1.0.jar and nms-multispeak-sdk-1.12.0.1.0.jar archives.
• $NMS_BASE/sdk/java/samples/nms-multispeak-plugins.zip: Java project, which can be used as a starting point for building custom plugins for SCADA components of the NMS MultiSpeak adapter.
The
nms-install-config script is used to apply adapter configuration changes and create the
nms‑multispeak.ear file, which can be deployed to the Oracle WebLogic Server (see
“Software Configuration” for configuration instructions).
Deploying the nms‑multspeak.ear file on the same server as the cesejb.ear file is not supported; however, both managed servers do need to be in the same Oracle WebLogic Server domain.
Adapter Installation Instructions for Oracle WebLogic Server
Topics in this section:
Create a Managed Server (Optional)
To simplify creation of a new managed server, you may clone an existing Oracle Utilities Network Management System managed server.
1. Log in to the WebLogic Server Administration Console.
Note: The URL for WebLogic will be http://hostname:port/console where hostname represents the DNS name or IP address of the Administration Server, and port represents the number of the port on which the Administration Server is listening for requests (port 7001 by default).
2. Click Lock & Edit.
3. In the Domain Structure tree, expand Environment, then select Servers to open the Summary of Servers page.
4. Select an Oracle Utilities Network Management System server in the Servers table and click Clone.
5. Click the link to the cloned server, select the General tab, change the Listen Port and SSL Listen Port to unique values.
Configure Data Source for the Adapters Managed Server
You may configure a new JDBC data source or add the adapter managed server as a target to an existing Oracle Utilities Network Management System read/write data source.
Note: See "Configure Database Connectivity" in the Oracle Utilities Network Management System Installation Guide for information on creating JDBC data sources.
1. In the Domain Structure tree, expand Services, then select Data Sources.
2. In the Data Sources table, click the data source name (either a new data source or an existing read/write NMS data source) to open the Settings for JDBC_Data_Source_Name page.
3. Select the Targets tab.
4. Add the adapter managed server to the list of targets.
5. Click Save.
Enabling Support for Plain HTTP
By default the adapter is configured to only accept incoming requests over HTTPS. To enable support for plain HTTP, add or uncomment the line in $NMS_CONFIG/jconfig/build.properties file:
option.no_multispeak_force_https
Then build new nms-multispeak.ear by running:
nms-install-config --java
Authentication Methods
By default the adapter is configured to use Basic HTTP Authentication for incoming web service requests. If credentials from the MultiSpeak message header should be used instead, add or uncomment the line in $NMS_CONFIG/jconfig/build.properties file:
option.no_multispeak_http_auth
Then build new nms-multispeak.ear by running:
nms-install-config --java
Notes:
• This parameter has no effect on JMS transport mechanism. It cannot use Basic HTTP Authentication mechanism.
• When Basic HTTP Authentication is not used, the configuration parameter "config.message_credentials_required" allows skipping authentication when credentials are not present in the message.
The adapter authorizes incoming web service requests by checking that caller that has the 'NmsWrite' role in WebLogic Server.
Deploy the Adapter
1. In the left pane of the Administration Console, select Deployments.
2. In the right pane, click Install.
3. In the Install Application Assistant, locate the nms-multispeak.ear file.
4. Click Next.
5. Select Install this deployment as an application.
6. Click Next.
7. Select the servers and/or clusters to which you want to deploy the application.
Note: If you have not created additional Managed Servers or clusters, you will not see this assistant page.
8. Click Next.
9. Set the deployed name of the application to: nms-multispeak.
10. Click Next.
11. Review the configuration settings you have specified.
12. Click Finish to complete the installation.
Clustered Deployment
When MultiSpeak Adapter is deployed on a WebLogic cluster, the web service front end is active on all cluster nodes. However, the node that processes a request differs for different components of the Adapter.
For AVL components the node which received the request will process it, which balances the load between the cluster nodes.
For AMR and SCADA components there is a single "active" node that does the processing. All requests received by different nodes are forwarded to the "active" node. If the "active" node fails one of the remaining nodes will become "active" automatically. When this happens the AMR and SCADA adapter components will go through an initialization process on the node that has become "active". For the SCADA component this also means that it will start a new synchronization sequence with the SCADA system(s).
Note: clustered deployment assumes that there is a software or hardware load balancer present to direct incoming web service request to different nodes of the cluster.
JMS Transport Mechanism
• The JMS transport mechanism is based on the SOAP over JMS specification.
• Two JMS queues are used per communication channel (one for requests and another for responses) to simulate synchronous communication.
• Each individual request is synchronous. The system places the message on the request queue and waits for a reply to arrive on the response queue.
• TextMessage or BytesMessage JMS message classes can be used. In both cases message must be a valid MultiSpeak message.
• Requests and responses are connected through JMSCorrelationID JMS header.
• In the request message, the JMS header JMSReplyTo must contain the queue where response message should be sent.
• SOAP protocol versions 1.1 and 1.2 are supported.
• There is no support for accessing a WSDL over JMS.
The following table describes how JMS message properties, specific to SOAP over JMS, are being used:
Configuring JMS Support
Incoming Data Flows
Support for accepting incoming requests over JMS in NMS MultiSpeak adapter is controlled by changing value of the config.multispeak_jms property in $NMS_CONFIG/jconfig/build.properties file.
Possible values:
• none: JMS support is disabled
• single: single JMS queue for all incoming data flows
• scada: separate JMS queue for each incoming SCADA data flow (for backward compatibility value 'multiple' has the same effect as 'scada')
• amr: separate JMS queue for each incoming AMR data flow
• avl: separate JMS queue for each incoming AVL data flow
Note: 'scada', 'amr', and 'avl' can be specified together.
By default JMS support is disabled.
After modifying the $NMS_CONFIG/jconfig/build.properties file, regenerate the nms-multispeak.ear with the new configuration by executing:
nms-install-config -–java
JNDI names of JMS connection factory and queue(s) used for incoming data flows are fixed.
Connection Factory
nms-amr/ConnectionFactory
Queues
Single Queue Mode
In single queue mode, all incoming requests are sent to the same JMS queue: nms-amr/queue/OA.
Multiple Queues Mode
When multiple incoming queues are used each incoming MultiSpeak data flow uses its own JMS queue.
List of JMS queues and associated MultiSpeak operations:
• nms-amr/queue/OAPingURL
PingURL
• nms-amr/queue/OAGetMethods
GetMethods
• nms-amr/queue/OAStatusChangedNotificationByPointID
SCADAStatusChangedNotification
SCADAStatusChangedNotificationByPointID
• nms-amr/queue/OAStatusChangedNotificationByPointIDSync
StatusChangedNotificationByPointID
• nms-amr/queue/OAAnalogChangedNotificationByPointID
SCADAAnalogChangedNotification
SCADAAnalogChangedNotificationByPointID
• nms-amr/queue/OAAnalogChangedNotificationByPointIDSync
AnalogChangedNotificationByPointID
• nms-amr/queue/OATagChangedNotificationByPointID
SCADATagChangedNotification
SCADATagChangedNotificationByPointID
• nms-amr/queue/OATagChangedNotificationByPointIDSync
TagChangedNotificationByPointID
• nms-amr/queue/OAInitiateStatusReadByPointID
InitiateStatusReadByPointID
• nms-amr/queue/OAHighlightObjectInDisplay
HighlightObjectInDisplay
• nms-amr/queue/OAInitiateTagReadByPointID
InitiateTagReadByPointID
• nms-amr/queue/OAODEventNotification
ODEventNotification
• nms-amr/queue/OAFormattedBlockNotification
FormattedBlockNotification
• nms-amr/queue/OAMeterChangedNotification
MeterChangedNotification
• nms-amr/queue/OAAVLChangedNotification
AVLChangedNotification
Outgoing Data Flows
The JMS connection factory for outgoing data flows is defined in the CES_PARAMETERS database table.
• The JMS queues used for outgoing messages are configured via the following database tables:
• SCADA_LINKS and SCADA_LINK_OPS for the SCADA component.
• AMR_LINKS and AMR_LINK_OPS for the AMR component.
The AVL component does not have outgoing data flows.