Miscellaneous scenario definition attributes include:

  • COUNT — to define the cardinality of a message or field

  • ALIAS — to track a value across messages

  • AUTO — to auto-generate the value of a field

  • EXCLUSIVE — to match only specified child elements.

  • IGNORE_ORDER — to ignore order of child elements.

  • ROW_SELECTION — to change row selection strategy.

  • MULTI_LINE — to use multiple lines in scenario file for multi-line field values.

COUNT

The COUNT attribute defines the cardinality of a field — how many times it can exist. The default value is 1.

SomeMessage {
  field1 (COUNT 1..*) "a value"; // One or more times
  field2 (COUNT 0..*) "a value"; // Any number of times
  field3 (COUNT 0..1) "a value"; // At most one time
  field4 (COUNT 0) "a value";    // Must be absent
  field5 (COUNT 1) "a value";    // Must be present exactly once (the default)
}

ALIAS

A scenario commonly needs to track a certain value across messages, where a field in a new message takes the value of a field in a previous message. This is expressed using the ALIAS attribute.

InitialDP {
  callingPartyNumber (ALIAS caller) "123456";
}
SomeLaterMessage {
  someCallerField (ALIAS caller);
}

In the above example, the value of the someCallerField field must be the same value as the callingPartyNumber field which preceded it.

Warning Aliases are globally scoped with respect to the scenario. In the above example, all elements with (ALIAS caller) must have the same value as each other, regardless of where they are defined in the scenario.

AUTO

Some fields support auto-generation, which you can use by adding the AUTO attribute to the element. An example of a field supporting auto-generation is the invokeId field of many operations in CAPv3, INAP and MAP; below is a sample usage.

InitialDPRequest
...
{
  invokeId
  (AUTO);
  ...
}

In the above example, the value of the invokeId is auto-generated.

Re-using a generated value

The generated value can still be aliased and used later in the scenario definition. In the example below, the invokeId value is auto-generated for a request, and reused in the invokeId field of the result message.

SendRoutingInfoForSMRequest
(DIALOG d1, DIRECTION A_TO_B)
{
  invokeId
  (AUTO, ALIAS SendRountingInfoForSMInvokeID) ;
  argument
  ..
}
...
SendRoutingInfoForSMResult
(DIALOG d1, DIRECTION B_TO_A)
{
  invokeId
  (ALIAS SendRountingInfoForSMInvokeID) ;

EXCLUSIVE

You use the EXCLUSIVE attribute on a structured field or message element, to specify matching only listed child elements (so that received elements not in the given child list cause a failed match).

When the simulator sees a sub-field that is not specified in the scenario definition, and the EXCLUSIVE attribute is set on the parent field, this will cause a failed match. If the EXCLUSIVE attribute is not set, the field will be ignored.

Tip To define particular sub-fields as absent, set the COUNT attribute to "0" (zero ) for these sub-fields.

IGNORE_ORDER

You use the IGNORE_ORDER attribute on a structure field, to ignore the order of child elements when matching messages.

Currently this attribute is only applicable to array types, such as ASN.1 "SEQUENCE OF" types.

ROW_SELECTION

You can optionally use the ROW_SELECTION attribute on a table element to specify a different row selection strategy. Note that this only applies to value generation for outgoing messages where no value is provided for a field by other means.

Currently supported values are random or sequential. If unspecified, random row selection will be used.

Warning When using sequential row selection for a table, all values in each column should be unique and the first selection from the table should not have a value specified by any other means. If a scenario instance’s first selection from the table specifies a value that causes more than one row to be selected, then a subsequent selection with no value specified will cause a generation error.

MULTI_LINE

Used on field elements. Specifies that the Scenario Editor should not escape newlines when writing the field value. Instead the resulting lines of the string value have additional indentation added at the start equivalent to the indentation of the field element.

When scenario files are read, spaces following any un-escaped newline character are removed up to the amount of the indentation of the field element. This is particularly useful for http response bodies, making the scenario file easier to read and diff for humans.

    Message-Body {
      text_plain_UTF-8 "<?xml version=\"1.0\" encoding=\"UTF-8\"?><xcap-caps xmlns=\"urn:ietf:params:xml:ns:xcap-caps\">\n  <auids>\n    <auid>xcap-caps</auid>\n    <auid>simservs.ngn.etsi.org</auid>\n  </auids>\n  <namespaces>\n    <namespace>urn:ietf:params:xml:ns:xcap-caps</namespace>\n    <namespace>urn:ietf:params:xml:ns:xcap-error</namespace>\n    <namespace>http://uri.etsi.org/ngn/params/xml/simservs/xcap</namespace>\n    <namespace>urn:ietf:params:xml:ns:common-policy</namespace>\n    <namespace>urn:oma:xml:xdm:common-policy</namespace>\n  </namespaces>\n</xcap-caps>";
    }

and

    Message-Body {
      text_plain_UTF-8  (MULTI_LINE) "<?xml version=\"1.0\" encoding=\"UTF-8\"?><xcap-caps xmlns=\"urn:ietf:params:xml:ns:xcap-caps\">
        <auids>
          <auid>xcap-caps</auid>
          <auid>simservs.ngn.etsi.org</auid>
        </auids>
        <namespaces>
          <namespace>urn:ietf:params:xml:ns:xcap-caps</namespace>
          <namespace>urn:ietf:params:xml:ns:xcap-error</namespace>
          <namespace>http://uri.etsi.org/ngn/params/xml/simservs/xcap</namespace>
          <namespace>urn:ietf:params:xml:ns:common-policy</namespace>
          <namespace>urn:oma:xml:xdm:common-policy</namespace>
        </namespaces>
      </xcap-caps>";
    }

are equivalent

Previous page Next page