This Service is used to modify a Subscription.
Illegal request values for parameters that can be revised do not generate errors. Instead the Server will choose default values and indicate them in the corresponding revised parameter.
Changes to the Subscription settings shall be applied immediately by the Server. They take effect as soon as practical but not later than twice the new revisedPublishingInterval.
Table 90 defines the parameters for the Service.
Table 90 – ModifySubscription Service Parameters
|requestHeader||RequestHeader||Common request parameters (see 7.33 for RequestHeader definition).|
|subscriptionId||IntegerId||The Server-assigned identifier for the Subscription (see 7.19 for IntegerId definition).|
|requestedPublishingInterval||Duration||This interval defines the cyclic rate at which the Subscription is being requested to return Notifications to the Client. This interval is expressed in milliseconds. This interval is represented by the publishing timer in the Subscription state table (see 18.104.22.168). The negotiated value for this parameter returned in the response is used as the default sampling interval for MonitoredItems assigned to this Subscription.If the requested value is 0 or negative, the Server shall revise with the fastest supported publishing interval.|
|requestedLifetimeCount||Counter||Requested lifetime count (see 7.8 for Counter definition). The lifetime count shall be a minimum of three times the keep keep-alive count.When the publishing timer has expired this number of times without a Publish request being available to send a NotificationMessage, then the Subscription shall be deleted by the Server.|
|requestedMaxKeepAliveCount||Counter||Requested maximum keep-alive count (see 7.8 for Counter definition). When the publishing timer has expired this number of times without requiring any NotificationMessage to be sent, the Subscription sends a keep-alive Message to the Client. The negotiated value for this parameter is returned in the response.If the requested value is 0, the Server shall revise with the smallest supported keep-alive count.|
|maxNotificationsPerPublish||Counter||The maximum number of notifications that the Client wishes to receive in a single Publish response. A value of zero indicates that there is no limit.|
|priority||Byte||Indicates the relative priority of the Subscription. When more than one Subscription needs to send Notifications, the Server should de-queue a Publish request to the Subscription with the highest priority number. For Subscriptions with equal priority the Server should de-queue Publish requests in a round-robin fashion.A Client that does not require special priority settings should set this value to zero.|
|responseHeader||ResponseHeader||Common response parameters (see 7.34 for ResponseHeader definition).|
|revisedPublishingInterval||Duration||The actual publishing interval that the Server will use, expressed in milliseconds. The Server should attempt to honour the Client request for this parameter, but may negotiate this value up or down to meet its own constraints.|
|revisedLifetimeCount||Counter||The lifetime of the Subscription shall be a minimum of three times the keep-alive interval negotiated by the Server.|
|revisedMaxKeepAliveCount||Counter||The actual maximum keep-alive count (see 7.8 for Counter definition). The Server should attempt to honour the Client request for this parameter, but may negotiate this value up or down to meet its own constraints.|
Table 91 – ModifySubscription Service Result Codes
|Bad_SubscriptionIdInvalid||See Table 182 for the description of this result code.|