This chapter describes the Oracle Communications Services Gatekeeper Native UCP communication service.
The Native UCP communication service exposes the UCP Short Message Service Center EMI-UCP standard interfaces.
The communication service acts as a Short Message Terminal (SMT) that connects to a Short Messaging Service Center (SMSC) over TCP/IP.
For the exact version of the standards that the UCP communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
The Native UCP service can:
Connect to a specified SMSC address.
Open a session with the SMSC.
Send acknowledgments to the SMSC.
Send acknowledgments to the application.
Send a mobile-terminated SMS message to destination addresses.
Deliver a mobile-originated SMS message.
Deliver a delivery notification associated with a previously sent mobile-terminated SMS message.
All Native UCP components are deployed in the network tier.
The core module of the Native UCP communication service is a Native UCP Protocol Server Service deployed as an Oracle WebLogic Server Service. The Native UCP Protocol Server Service:
Receives UCP data from the socket.
Constructs the UCP protocol data unit (PDU).
Associates the current PDU with the correct application instance.
Invokes the plug-in.
There is also a Native UCP managed plug-in module, as well as the Native UCP plug-in instances.
In addition, Native UCP uses the Connection Information Manager service to create and manage a credential map to support each plug-in instance. For information about the Connection Information Manager, see the discussion about managing and configuring native UCP connection information in Services Gatekeeper System Administrator's Guide.
The entire Native UCP Service is deployed in the network tier, so applications using it must connect directly to the network tier. The network and any firewall should be configured to allow connection to the ports defined for the Native UCP Service.
There is no failover between network tier servers. Redundant SMSCs and redundant network cards are required to support high-availability features.
To optimize system utilization, the application and the SMSC should load balance the requests among all network tier servers.
Hitless upgrade is not supported for the Native UCP communication service. To upgrade you must restart the server.
Plug-in instances establish connections to Services Gatekeeper using facilities provided by the Protocol Server Service. They also use the Protocol Server Service to open a session and to send requests to the SMSC. The Protocol Server Service creates a new socket connection for each session management operation of subtype "open session" that is sent.
The Native UCP Protocol Server Service uses the Connection Information Manager´s getConnectInfo operation to get the connection information for a particular plug-in instance. When a plug-in instance sends a Native UCP PDU to the Protocol Server Service passing its plug-in instance ID, a connection ID is returned. This connection ID identifies the SMSC connection on which the request was sent.
A server-side connection connects an application to Services Gatekeeper, which is the server in this context.
A client-side connection connects an SMSC to Services Gatekeeper, which is a client in this context.
Native UCP has no unbind operation. There are no receiver, transceiver, or transmitter connection types. If a connection is lost, the Protocol Server Service automatically closes one connection to the SMSC for the current application instance. See "Multiple Connections" for more information.
The Protocol Server Service performs network credential mappings based on a credential map set up in the Connection Information Manager.
A user/password combination is associated with a credential ID that is stored in the Connection Information Manager. See the Connection Information Manager´s createOrUpdateUserPasswordCredentialEntry operation. The credential ID is associated with a plug-in instance and an application instance in an entry in the Connection Information Manager's credential map. See the Connection Information Manager's createOrUpdateCredentialMap operation.
For detailed information on how to configure the connection information and the credential map, see the discussion about managing and configuring native UCP connection information in Services Gatekeeper System Administrator's Guide.
Windowing and Transaction Numbers
To maximize throughput, Native UCP supports windowing on both the application-facing and network-facing interfaces. This provides a way to specify the amount of data that can be transmitted to and from the network without receiving an acknowledgment.
On the server side, Native UCP creates a transaction number (TRN) allocation table using default values. These are used by server-side connections sending deliver_short_message and deliver_notification requests to an application.
On the client side, Native UCP creates a transaction number allocation table using values configured in the Connection Information Manager. Configure the client-side windowing behavior by setting the parameters listed in Table 29-1 using the Connection Information Manager´s addXParamToCredentialEntry operation. For information about this operation, see the discussion on managing and configuring connection information in Services Gatekeeper System Administrator's Guide.
Table 29-1 UCP Windowing Parameters in ConnectionInfoManager
| Parameter | Description | Default |
|---|---|---|
|
windowSize |
Maximum number of unacknowledged transactions allowed between a plug-in instance and an SMSC |
100 |
|
maxWaitAcquireTimeout |
Maximum time in milliseconds that a request can wait while trying to allocate a transaction number |
3000 |
|
allocationTimeout |
Maximum time in milliseconds that an allocated transaction number can be held while the plug-in or the SMSC is waiting for an acknowledgment |
5000 |
|
maxQueueSize |
Maximum number of threads that can wait for a transaction number to be allocated |
5 |
Behavior When the Window is Exceeded
If Services Gatekeeper tries to allocate a TRN when all the TRNs have been allocated and none is old enough to be cleaned up and maxWaitAcquireTimeout has expired, an exception is thrown causing Services Gatekeeper to respond with a NACK.
Behavior When TRNs Are Not Released
When a TRN is allocated, values that have already been allocated are checked to see whether they have expired. Entries older than allocationTimeout are cleaned and automatically released. An error is logged, but no alarm is generated. No NACK is triggered for a request that was originally associated with the expired TRN.
An application instance can establish multiple TCP connections to Services Gatekeeper. Multiple application instances, those with different application instance names, cannot share a connection to the SMSC.
If one connection between an application instance and an SMSC is dropped, Services Gatekeeper does not automatically close associated application instance connections as long as there are other SMSC connections available for that same application instance. If all connections to the SMSC for a particular application instance are dropped, Services Gatekeeper terminates all of that application instance's connections.
When an application instance sends an open session operation on a new connection, the Protocol Server Service tries to establish a connection to the underlying SMSCs and then to open the session. It does not automatically establish connection pools to the underlying SMSCs. It establishes additional connections only when an application instance establishes multiple connections with Services Gatekeeper.
Because an application may establish multiple connections, a request sent from the Protocol Server Service to a plug-in includes a server-side connection identifier. This identifier is then included when the plug-in uses the Protocol Server Service to send acknowledgments back to the application. Acknowledgments must be sent on the same connection as the corresponding request. Delivery reports can be sent on a different connection.
To maximize throughput, Native UCP supports windowing on both the application-facing and network-facing interfaces. This provides a way to specify the amount of data that can be transmitted to and from the network without receiving an acknowledgment.
On the server side, Native UCP creates a transaction number (TRN) allocation table using default values. These are used by server-side connections sending deliver_short_message and deliver_notification requests to an application.
On the client side, Native UCP creates a transaction number allocation table using values configured in the Connection Information Manager. Configure the client-side windowing behavior by setting the parameters listed in Table 29-2 using the Connection Information Manager´s addXParamToCredentialEntry operation. For information about this operation, see the discussion about managing and configuring native UCP connection information in Services Gatekeeper System Administrator's Guide.
Table 29-2 UCP Windowing Parameters in ConnectionInfoManager
| Parameter | Description | Default |
|---|---|---|
|
windowSize |
Maximum number of unacknowledged transactions allowed between a plug-in instance and an SMSC |
100 |
|
maxWaitAcquireTimeout |
Maximum time in milliseconds that a request can wait while trying to allocate a transaction number |
3000 |
|
allocationTimeout |
Maximum time in milliseconds that an allocated transaction number can be held while the plug-in or the SMSC is waiting for an acknowledgment |
5000 |
|
maxQueueSize |
Maximum number of threads that can wait for a transaction number to be allocated |
5 |
If Services Gatekeeper tries to allocate a TRN when all the TRNs have been allocated and none is old enough to be cleaned up and maxWaitAcquireTimeout has expired, an exception is thrown causing Services Gatekeeper to respond with a NACK.
When a TRN is allocated, values that have already been allocated are checked to see whether they have expired. Entries older than allocationTimeout are cleaned and automatically released. An error is logged, but no alarm is generated. No NACK is triggered for a request that was originally associated with the expired TRN.
Applications are authenticated on receipt of the openSession PDU, after which the connection is associated with the authenticated identity.
Subsequent requests on the connection trigger an identity assertion associating the request with the identity that was authenticated with the receipt of the open session PDU. A consequence of this behavior is that an application can continue to send messages after the password has been changed. To force a new authentication, close the connection.
Table 29-3 describes the mapping between the Native UCP authentication parameters and the Services Gatekeeper parameters.
Table 29-3 Authentication Parameters
| Native UCP Parameter | Services Gatekeeper ConnectionInfoManager Credential Parameter |
|---|---|
|
originating address (OAdC) |
application instance name |
|
password |
password |
The password is stored in the Connection Information Manager. No password information is stored by the Protocol Server Service or by the plug-in.
The availability and retry behavior of the Protocol Server Service is as follows.
If there is no acknowledgment from the network, the UCP Protocol Server Service does not start any timers per request, does not perform any retries, and does not report an acknowledgment back to the application.
The only exception to this behavior is when the wait on an openSession request exceeds the configured Native UCP OpenSessionTimeout maximum. See the OpenSessionTimeout field for more information.
If the Protocol Server Service receives an exception when calling the submit_short_message operation, it sends a NACK to the application.
If the underlying SMSC does not receive an acknowledgment from Services Gatekeeper, the SMSC should resend the request.
If a message is sent to an application but no acknowledgment is returned from the application, the UCP Protocol Server Service does not start any per request timers, does not perform any retries, and does not send back an acknowledgment to the application.
If the Protocol Server Service receives an exception when calling the deliver_short_message or deliver_notification operation, it sends a NACK to the SMSC.
Delivery reports do not have to be sent on the same server that sent the original delivery request, even in a geo-redundant setup. In a clustered configuration, if the server that submits an SMS fails, another server can handle the delivery report for that SMS.
Native UCP automatically tries to re-establish a dropped connection when an initial openSession attempt or an established session fails. The number of retries attempted is configured by the maxReconnectAttempts attribute and the number of milliseconds between retries by the timeBetweenReconnectAttempts attribute.
The retry behavior is as follows:
Initial openSession failure: When an application sends the initial open session request, Services Gatekeeper sends one open session request to each SMSC that matches the current configuration in terms of plug-ins, routes, SLAs, and so on. If one of the SMSCs responds with an ACK, Services Gatekeeper returns an ACK to the application.
For all SMSCs that Services Gatekeeper cannot connect to or receive an acknowledgment from, it tries to re-establish a connection. Specifically, retry is triggered in the following cases:
Services Gatekeeper receives a NACK in response to the open session request.
The socket to the SMSC cannot be set up.
The socket is closed before the acknowledgment is received.
The timeout period, configured by the OpenSessionTimeout attribute, expires before an acknowledgment is received.
Established session failure: If the client-side connection is dropped and the Services Gatekeeper application instance associated with the dropped connection still has other working connections, Services Gatekeeper sends an open session request to each SMSC that matches the current configuration, following the same procedure as described above for an initial openSession failure.
Use the dumpOngoingClientConnectionsRetryInfo and stopOngoingClientConnectionRetry operations to manage connections that are in the retry state.
Native UCP provides heartbeat support by sending UCP operation "31" (SMT alert) requests at regular intervals. This prevents firewalls and the SMSC from closing an idle connection.
Heartbeat support for Native UCP server-side connections has the following characteristics:
In response to a UCP operation type "31"(SMT Alert), the corresponding acknowledgment is sent.
There are no timeouts associated with heartbeats.
Services Gatekeeper does not close any connections because of missing heartbeat requests.
Heartbeats received on server-side connections are not forwarded to client-side connections.
There are no configuration attributes associated with server-side heartbeat functions.
Heartbeat support for Native UCP client-side connections has the following characteristics:
Heartbeats are not enabled by default for a client-side connection.
Heartbeats are enabled by setting the heartbeatInterval parameter in the Connection Information Manager. This parameter defines the interval, in milliseconds, between UCP operation type 31 requests. The value is configured with the addXParamToCredentialEntry method of the ConnectionInfoManager MBean.
For information about this operation, see discussion on managing and configuring connection information in Services Gatekeeper System Administrator's Guide.
Services Gatekeeper does not close any client-side connections because of missing acknowledgments on heartbeat requests.
Received client-side heartbeat acknowledgments are not forwarded to server-side connections.
For information about the application interface for the Native UCP communication service, see the discussion about Native UCP Interfaces in Services Gatekeeper Application Developer's Guide.
The Native UCP communication service generates event data records (EDRs), charging data records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service
For general information, see Appendix A, "Events, Alarms, and Charging."
Table 29-4 lists IDs of the EDRs created by the Native UCP communication service.
When there are multiple SMSCs, it is possible that EDR data generated for open session requests may contain the wrong data for some of the EDRs because EDR data is stored in the current context.
Table 29-4 EDRs Generated by Native UCP
| EDR ID | Description |
|---|---|
|
402001 |
application-initiated openSession to the SMSC |
|
402002 |
application-initiated submitSM to the SMSC |
|
402003 |
application-initiated ACK to the SMSC |
|
402004 |
application-initiated NACK to the SMSC |
|
402010 |
network-triggered deliverSM to the application |
|
402011 |
network-triggered deliveryNotification to the application |
|
402012 |
network-triggered ACK to the application |
|
402013 |
network-triggered NACK to the application |
Table 29-5 describes Native UCP-specific fields included in the Native UCP EDRs.
Table 29-5 Native UCP-Specific EDR Fields
| EDR Parameter | Description |
|---|---|
|
UCP_isOperation |
|
|
UCP_opType |
UCP operation type; for example, 51 for a submit_short_message request |
|
UCP_trn |
UCP transaction number; see "About UCP_trn/UCP_mappedTrn" |
|
UCP_mappedTrn |
mapped transaction number; see "About UCP_trn/UCP_mappedTrn" |
|
UCP_sourceConnID |
source connection ID; for the connection that received the PDU |
|
UCP_outgoingConnID |
outgoing connection ID for the connection on which the PDU was sent |
|
UCP_adc |
AdC parameter in the UCP PDU |
|
UCP_oadc |
OAdC parameter in the UCP PDU; see "About UCP_oadc" |
|
UCP_scts |
Service Center Timestamp (SCTS) parameter in the UCP PDU |
Transaction numbers must be mapped in the following cases:
When sending a submit_short_message operation (51) to the SMSC and receiving the corresponding acknowledgment
When sending a deliver_notification operation (53) to the application and receiving the corresponding acknowledgment
When sending a deliver_short_message operation (52) to the application and receiving the corresponding acknowledgment
A UCP_mappedTrn is required in the following circumstances because pooled connections create the possibility of sending conflicting or overlapping transaction numbers were they not mapped:
When a submit_short_message request is sent:
UCP_trn holds the original transaction number as received by the application.
UCP_mappedTrn holds the transaction number that was used in the request to the SMSC.
When the acknowledgment for the submit_short_message request is received:
UCP_trn holds the original transaction number, which is then used to forward the acknowledgment to the application.
UCP_mappedTrn holds the transaction number that was included in the acknowledgment from the SMSC.
The UCP_oadc parameter used in a deliver_notification operation (53) identifies the recipient of a message that was previously sent by the submit_short_message operation (51).
The UCP_oadc parameter normally contains the large account/originator number.
The Native UCP communication service generates charging data records (CDRs) under the following conditions:
After a mobile-originated SMS UCP PDU has been processed by the plug-in.
After a mobile-terminated SMS UCP PDU has been processed by the plug-in.
When an ACK is received.
The CDR includes the service center timestamp (SCTS). The ACK is correlated with submit_short_message using the connection identifiers and the transaction number (TRN).
When a delivery report for a mobile-terminated SMS message is received.
The CDR includes the SCTS for correlation with submit (and submit ACK) using SCTS and AdC and OAdC parameters.
Table 29-6 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counter.
This section describes the properties and workflow for the Native UCP communication service.
Native UCP relies upon facilities in Services Gatekeeper Connection Information Manager to create and store connection and credential information for a UCP plug-in instance. For information about this manager, see discussion on managing and configuring connection information in Services Gatekeeper System Administrator's Guidee.
Plug-in instances are associated with application instances and authentication credentials through the createOrUpdateCredentialMap operation in the Connection Information Manager.
There can be only one application instance per large account.
The work manager is registered when the managed plug-in is started. Settings in the Native UCP managed plug-in provide the IP address and port where the plug-in registers its work manager. These settings apply to all the Native UCP plug-in instances. If these settings are changed, a restart is required.
Table 29-7 lists the technical specifications for the UCP protocol server service.
Table 29-7 Native UCP Protocol Server Service Properties
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To manage the object, select domain_name , then OCSG, then server_name, then Container Services, and then UCPService. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng InstanceName=UCPService Type=oracle.ocsg.protocol.ucp.management.UCPServerMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Exposes this interface to applications |
EMI-UCP 5.1 |
|
Deployment artifacts |
oracle.ocsg.protocol.ucp_6.0.0.0.jar, oracle.ocsg.protocol.ucp_api_6.0.0.0.jar |
Table 29-8 lists the technical specifications for the Native UCP managed plug-in.
Table 29-8 Native UCP Managed Plug-in Properties
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To manage the object, select domain_name, then OCSG, then server_name, then Communication Services, and then oracle.ocsg.native_ucp_sms |
|
MBean |
Domain=com.bea.wlcp.wlng AppName=native_ucp_sms#6.0.0 InstanceName = oracle.ocsg.native_ucp_sms Type = oracle.ocsg.plugin.nativefacade.ucp.management.NativeUCPManagedPluginMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Supported Network Interface |
UCP v5.1 |
|
Supported Application Interface |
UCP v5.1 |
|
Deployment artifact |
wlng_nt_native_ucp_sms.ear |
Table 29-9 lists the technical specifications for the plug-in instance.
Table 29-9 Native UCP Plug-in Instance Properties
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To manage the object, select domain_name, then OCSG, then server_name, then Communication Services, then plugin_instance_id in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng AppName=native_ucp_sms#5.1.0 Instance Name=same as the network protocol instance_id assigned when the plug-in instance is created Type=oracle.ocsg.plugin.nativefacade.ucp.management.NativeUCPPluginMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Supported network interface |
UCP v5.1 |
|
Supported application interface |
UCP v5.1 |
|
Supported character sets |
7-bit GSM charset + Unicode (16-bit UCS2) |
|
Supported address scheme |
tel |
|
Deployment artifact |
wlng_nt_native_ucp_sms.ear |
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Configure the listen address and the listen port in the Native UCP managed plug-in MBean, NativeUCPManagedPluginMBean. All the Native UCP plug-in instances use these fields.
listenAddress
listenPort
See "Reconfiguring Native UCP Listen Ports" if you need to change these values.
[Optional] Configure the Native UCP address routing interceptor if there is a possibility of multiple SMSCs owning the same address. This ensures that messages sent to the same address are sent to the same SMSC. It also ensures that all message segments for a concatenated SMS message are sent to the same SMSC.
This interceptor is not enabled by default.
To enable it, edit the interceptor chain to include the NativeUCPAddressRouting class:
Open the config.xml file that is bundled in the interceptors.ear file in the Services Gatekeeper installation.
This is the file in which the interceptor chain is defined.
Locate the RoundRobinPluginList routing interceptor in the file. The line looks like this:
<interceptor class="com.bea.wlcp.wlng.interceptor.RoundRobinPluginList" index="1000"/>
Add the NativeUCPAddressRouting class interceptor immediately before the RoundRobinPluginList routing interceptor. The line for the NativeUCPAddressRouting interceptor looks like this:
<interceptor class="com.bea.wlcp.wlng.interceptor.NativeUCPAddressRouting" index="950"/>
The resulting interceptor chain should look like this:
... <interceptor class="com.bea.wlcp.wlng.interceptor.FilterPluginListUsingCustomMatch" index="800"/> <interceptor class="com.bea.wlcp.wlng.interceptor.RemoveOptional" index="900"/> <interceptor class="com.bea.wlcp.wlng.interceptor.NativeUCPAddressRouting" index="950"/> <interceptor class="com.bea.wlcp.wlng.interceptor.RoundRobinPluginList" index="1000"/> <interceptor class="com.bea.wlcp.wlng.interceptor.InvokeServiceCorrelation" index="1100"/> ...
The interceptor verifies that the request it is intercepting is a Native UCP request before it modifies the plug-in list. If it is not a Native UCP request, the list is not modified.
Perform steps 1 through 5 in the Connection Information Manager. The operations and attributes used in these steps are described in the discussion about managing and configuring connection information in Services Gatekeeper System Administrator's Guide.
Create one or more Native UCP plug-in instances. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in service ID described in the "Properties for Native UCP Plug-in Instance" section.
Set up the network connection mapping for the plug-in instance using the Connection Information Manager.
createOrUpdateLocalHostAddress
createOrUpdateRemoteHostAddress
createOrUpdateListenAddress
Set up the network credential mapping. This associates a user and password with a credential ID. Use the following operation:
createOrUpdateUserPasswordCredentialEntry
Create or update the credential map for the plug-in instance. This entry associates the credential ID with the application instance ID and the plug-in instance ID. Use the following operation:
createOrUpdateCredentialMap
Add any connection-specific parameters needed to support windowing and heartbeats. See "Windowing and Transaction Numbers" and "Heartbeat Support" for more information. Use the addXParamToCredentialEntry method.
Configure the retry behavior for the Native UCP Protocol Server Service with the MaxReconnectAttempts and TimeBetweenReconnectAttempts fields.
Configure the timeout limit for the plug-in instance with the OpenSessionTimeout field.
If required, create and load a node SLA. For details see the discussion on defining global node and service provider group node SLAs and managing SLAs in Services Gatekeeper Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
The listen port and address is used by the Native UCP plug-in upon startup to register a work manager in the UCP Protocol Server Service.
To reconfigure the listen port and listen address:
In the Connection Information Manager, create the new listen address and port using the createOrUpdateListenAddress operation.
Remove the old listen address and port using the Connection Information Manager's removeListenAddress operation.
View the new listen address configuration using the Connection Information Manager's getAllListenAddress operation.
In the Native UCP Managed Plug-in, change the listenAddress and listenPort attributes to match the new values that you just configured in the Connection Information Manager. See the listenAddress and listenPort fields for more information.
Register the work manager at the new port using the reRegisterWorkManager operation. See the reRegisterWorkManager method for more information.
Services Gatekeeper cannot accept new server-side connections on the new ports until you restart the ports using the restartPorts operation. See the restartPorts method for more information.
Using thelistUCPServersString method in the Native UCP Protocol Server Service, view the currently running listen ports.
Using the restartports method, close and restart all current listening ports. This closes all server-side and client-side connections.
Using the listUCPServersString, verify that Native UCP is listening on the new ports.
Using thedumpServerSideconnectionsInfo method, verify that applications are reconnecting on the new listen ports.
Using the dumpClientSideConnectionsInfo method, verify that connections to the SMSCs have been re-established.
This section describes the attributes and operations for configuration and maintenance:
Scope: Cluster
Unit: Not applicable
Format: Integer
Specifies the maximum number of reconnect retries permitted.
Table 29-10 MaxReconnectAttempts Values
| Value | Meaning |
|---|---|
|
-1 |
retry forever; no maximum |
|
0 |
no retries |
|
< 0 |
maximum number of retries |
|
-1 |
retry forever; no maximum |
See "Attribute: TimeBetweenReconnectAttempts" and "Client-Side Retry Handling" for information about how dropped connections are handled.
Scope: Cluster
Unit: Milliseconds
Format: Integer
Specifies the time, in milliseconds, between reconnect attempts.
See "Attribute: TimeBetweenReconnectAttempts" and "Client-Side Retry Handling" for information about how dropped connections are handled.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the UCP protocol string.
This value must match a protocol string defined for a listen address in the Connection Information Manager.
Scope: Server
Closes a client-side connection between Services Gatekeeper (the client in this relationship) and an SMSC.
After this method is used to close a client-side connection, no retries are attempted on the closed connection.
Does not implicitly close any server-side connections.
Use "Operation: dumpClientSideConnectionsInfo" to see information about the open client-side connections
Signature:
closeClientSideConnection(pluginInstanceID: String, ocsgUser: String, connectionID: String)
Scope: Server
Closes a server-side connection between an application and Services Gatekeeper (the server in this relationship).
Does not implicitly close any client-side connections
Use "Operation: dumpServerSideConnectionsInfo" to see information about the open server-side connections.
Signature:
closeServerSideConnection(pluginInstanceID: String, ocsgUser: String, connectionID: String)
Scope: Server
Lists information for all the current client-side connections. These are the connections between Services Gatekeeper and SMSCs.
Dumped information includes pluginInstanceID, ocsgUser, and connectionID for all current connections.
Signature:
dumpClientSideConnectionInfo()
Scope: Server
Lists current client-side connections that are experiencing periodic retry attempts.
The following sample output shows a dump for a connection that has already performed seven retries and is configured to perform an infinite number of retries ("Attribute: MaxReconnectAttempts" = -1), with 60 seconds between retry attempts ("Attribute: TimeBetweenReconnectAttempts"= 60000):
<pluginInstance id="native_ucp_sms_plugin_2"> <user name="1234567"> <connection max_retries="-1" current_retries="7" retry_interval="60000" id="c_localhost:9887_tmp_8237645"/> </user> </pluginInstance>
Signature:
dumpOngoingClientConnectionsRetryInfo()
Scope: Server
Lists information for all the current server-side connections. These are the connections between Services Gatekeeper and applications.
Dumped information includes pluginInstanceID, ocsgUser, and connectionID for all current connections.
Signature:
dumpServerSideConnectionInfo()
Scope: Server
Lists the currently running UCP servers as a comma-separated list of strings in the format host:port.
Signature:
listUCPServersString()
Scope: Server
Restarts the Native UCP listen ports.
This operation must be performed if users of the Native UCP Protocol Server Service have reregistered their work managers at new ports. See the reRegisterWorkManager method for more information.
The new ports must have been configured in the Connection Information Manager MBean for the UCP protocol. See the createOrUpdateListenAddress and removeListenAddress operations in managing and configuring connection information in Services Gatekeeper System Administrator's Guide.
This operation abruptly terminates all ongoing traffic and closes all server-side and client-side connections.
Signature:
restartPorts()
Scope: Server
Stops ongoing retry attempts for the specified connection.
Use "Operation: dumpOngoingClientConnectionsRetryInfo" to see information about the current client-side connections that are in the retry state.
See "Client-Side Retry Handling" for more information.
Signature:
stopOngoingClientConnectionRetry(pluginInstanceID: String, ocsgUser: String, connectionID: String)
Table 29-13 stopOngoingClientConnectionRetry Parameters
| Parameter | Description |
|---|---|
|
pluginInstanceID |
Instance ID of the plug-in instance that is trying to reconnect |
|
ocsgUser |
User name used to connect |
|
connectionID |
Connection ID the request was sent on |
|
pluginInstanceID |
Instance ID of the plug-in instance that is trying to reconnect |
For descriptions of the attributes and operations of the NativeUCPManagedPluginMBean and NativeUCPPluginMBean MBeans, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference.