Testing OCNCC OSD Operations

The IN Tester system can be used to test operations that have been configured to be available through the Oracle Communications NCC "Open Services Development" (OSD) interface.

The IN Tester, once configured, will retrieve all available OSD operations from the OCNCC platform and create a test flow node for each operation. Each operation can then be tested through its own test flow node.

Due to the number of operations generally avaiable, all OSD operation nodes are grouped under a single button in the test flow designers available flow node list.

A special Generic Operation node is available as well. This node can be used to define an operation not automatically picked up from the OCNCC platform. This in particular ensures that when removing OSD operations from OCNCC tests do not become broken.

As every OSD operation is almost entirely customised through the OCNCC control plan editor, the inputs and expected outputs from each operation is also custom. The semantics for each field is therefore unique to the operation.

Each input and output has a unique type, which is documented here.


Test Fields for the Generic Operation

OSD Action

required

For the Generic Operation OSD action, the Action field must be given. This provides a reference to the WSDL that NCC has generated.

In OCNCC, this would be the Operation Set name as configured in the Open Services Development screens.

Examples

  • http://sms/wsdls/TELCO/Prepaid/BuyPrepaidPack

OSD Operation

required

For the Generic Operation OSD action, the Operation field must be given. This provides a reference to the operation within the WSDL referenced by the "Action" field.

In OCNCC, this would be the Operation name as configured in the Open Services Development screens.

Examples

  • BuyPrepaidPack

OSD Parameters

optional

For the Generic Operation OSD action, the Parameters field may be given to provide value for inputs to the OSD action.

Examples

{
    "CC_Calling_Party_Id": "64210635462"
}

OSD Result Tests

optional

For the Generic Operation OSD action, the Result Tests field may be given to request tests are performed on OSD results.

Examples

[
    {
        "name": "Result_Code"
        , "type": "xs:int"
        , "value": "31"
    }
]

Field Types for Generated OSD Nodes

Note that this example node is unlikely to be representative of any node in your environment.

Generic String

The OSD operation parameter type of "Generic String" will accept any string of characters. The exact requirements for what is put in this field will depend entirely on the OSD operation type.


Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.

  2. For output fields against which tests are run, it is possible to perform a number of types of tests:

    • It is possible to test that the response includes the field, and the value of the field matches.

    • It is possible to ignore the field and its value.

    • It is possible to test that the field does not exist in the response at all (i.e. does not exist even as an empty value).

  3. In all three cases the test can:

    • Be treated as a warning - allowing the test flow to continue even if the result is not equivalent to that expected.

    • Be treated as an abort condition - ending the test if the value returned does not match.

This second test approach is useful when testing for result codes where a subsequent action would be invalid if a result code did not indicate success.

Numeric String

The OSD operation parameter type of "Numeric String" will accept any string of numeric characters (usually a phone number). The exact requirements for what is put in this field will depend entirely on the OSD operation type.


Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.

  2. For output fields against which tests are run, it is possible to perform a number of types of tests:

    • It is possible to test that the response includes the field, and the value of the field matches.

    • It is possible to ignore the field and its value.

    • It is possible to test that the field does not exist in the response at all (i.e. does not exist even as an empty value).

  3. In all three cases the test can:

    • Be treated as a warning - allowing the test flow to continue even if the result is not equivalent to that expected.

    • Be treated as an abort condition - ending the test if the value returned does not match.

This second test approach is useful when testing for result codes where a subsequent action would be invalid if a result code did not indicate success.

Boolean

The OSD operation parameter type of "Boolean" may be left out, set or unset. The appropriate SOAP boolean value is used internally. The exact requirements for what is put in this field will depend entirely on the OSD operation type.


Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.

  2. For output fields against which tests are run, it is possible to perform a number of types of tests:

    • It is possible to test that the response includes the field, and the value of the field matches.

    • It is possible to ignore the field and its value.

    • It is possible to test that the field does not exist in the response at all (i.e. does not exist even as an empty value).

  3. In all three cases the test can:

    • Be treated as a warning - allowing the test flow to continue even if the result is not equivalent to that expected.

    • Be treated as an abort condition - ending the test if the value returned does not match.

This second test approach is useful when testing for result codes where a subsequent action would be invalid if a result code did not indicate success.

Integer

The OSD operation parameter type of "Integer" supports whole numbers (negative and positive). The exact requirements for what is put in this field will depend entirely on the OSD operation type.


Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.

  2. For output fields against which tests are run, it is possible to perform a number of types of tests:

    • It is possible to test that the response includes the field, and the value of the field matches.

    • It is possible to ignore the field and its value.

    • It is possible to test that the field does not exist in the response at all (i.e. does not exist even as an empty value).

  3. In all three cases the test can:

    • Be treated as a warning - allowing the test flow to continue even if the result is not equivalent to that expected.

    • Be treated as an abort condition - ending the test if the value returned does not match.

This second test approach is useful when testing for result codes where a subsequent action would be invalid if a result code did not indicate success.

Number List

The OSD operation parameter type of "Number List" supports one or more whole numbers, in order, in a comma-separate list. To define more than one number, separate the numbers with a comma. The exact requirements for what is put in this field will depend entirely on the OSD operation type.

  • 644401010,6422010101

Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.

  2. For output fields against which tests are run, it is possible to perform a number of types of tests:

    • It is possible to test that the response includes the field, and the value of the field matches.

    • It is possible to ignore the field and its value.

    • It is possible to test that the field does not exist in the response at all (i.e. does not exist even as an empty value).

  3. In all three cases the test can:

    • Be treated as a warning - allowing the test flow to continue even if the result is not equivalent to that expected.

    • Be treated as an abort condition - ending the test if the value returned does not match.

This second test approach is useful when testing for result codes where a subsequent action would be invalid if a result code did not indicate success.

OSD Fields of Unknown Types

OSD fields which are not known by the IN Tester GUI are available for editing and viewing through a generic field type that allows users to enter the raw JSON required for the field.

The exact requirements for what is put in this field will depend entirely on the OSD operation type. Note that in every case, the field value will need to be valid JSON.

Examples

The following example shows how a "Recharge List" of one item may be defined:

{
    "Recharge_List": [
        {
            "Balance_Type_Name": "General Cash",
                "Recharge_Amount": -10000,
                "Balance_Expiry_Extension_Period": 7,
                "Balance_Expiry_Extension_Policy": 1,
                "Balance_Expiry_Extension_Type": 0,
                "Bucket_Creation_Policy": 0
        }
    ]
}

Click on the grey box to the left of the field to access additional controls:

  1. For input fields (fields sent in the OSD request) it is possible to flag them such that they are not included in the OSD request at all.

    Fields flagged in this way are not included in the OSD request at all. This is different to including them as an empty value.