Subscription Publish Min 05

Support at least 5 Publish Service requests per Session. This number has to be supported for at least half of the minimum required sessions. Support, as a minimum, the number of Publish requests per session as the size of the NotificationMessage retransmission queue for Republish.


Questions? Contact us
Generated: 21/11/2021 at 17:21:20 p.m.
Subscription Publish Min 05 - 7 Test Cases
Test Case Id Test Type Keywords Test Case Description Test Requirements Expected Result

001

CTT Publish()  Call Publish() 5 times for a session.
These calls will be done asynchronously so the server queue`s them.
Per Subscription Publish Min 05 conformance unit.
All service and operation level results are Good.
The results are issued at the applicable time, i.e. the RevisedPublishingInterval.

002

CTT Unavailable  Create 5 subscriptions: 1 for events, and the remainder for monitoring regular [scalar] nodes.
Step #
Action
Expected Result(s)

1

All calls are successful.

2

Write to all trigger value(s) and all scalar nodes and then call Publish 5 times (once per subscription).

Each publish notification (per subscription) contains event(s) and data-change notifications.

3

Repeat the above step multiple times.

003

CTT Unavailable  Create half as many sessions as are claimed to be supported; e.g. create 5-sessions if the Server claims to support 10. Check the CTT for a setting that defines the max # of Sessions.
Step #
Action
Expected Result(s)

1

All calls are successful.

2

For each session, create 5 subscriptions along with at least monitored item for each.

All calls are successful.

3

Call Publish once per subscription, per session (e.g. 5-sessions with 5-subscriptions = 25 Publish calls).

All calls are successful.

004

CTT Unavailable  Create 5 subscriptions and in each create 2 MonitoredItems where one is Server.Notifier (events) and the other a scalar variable type (data).
Step #
Action
Expected Result(s)

1

All calls successful.

2

In a loop, write a value to the Variable and also to a node that will invoke any kind of Event. Call Publish twice.

Each Publish response will receive data and event notifications.

005

CTT Republish()  Create a subscription and add monitored items (reporting).
In a loop of 2: (a) write a value; (b) wait; (c) Publish (do not acknowledge)
Call Republish to retrieve the previous notification messages
All ServiceResults are Good.
All Publish calls yield data changes.
Republish either (a) returns data changes; (b) returns BadMessageNotAvailable. republish must return AT LEAST ONE data-change.

006

CTT Create a subscription that is monitoring a static node. Call Publish.
Step #
Action
Expected Result(s)

1

<p> All calls are successful. Initial data-change received.</p>

2

<p> Queue-up multiple Publish calls while specifying a RequestHeader.TimeoutHint that is smaller than the subscription keepAlive.</p> <p> Note: No data is changing so keep-alives are all that can be expected.</p>

<p> Initial Publish responses may contain keep-alives (depending on timeout settings); otherwise Service result is BadTimeout and no data is returned.</p>

Err-001

CTT Publish()  Queue the maximum number of Publish() requests allowed by the server.
Queue an additional Publish() call.
ServiceResult = Bad_TooManyPublishRequests.