OCNCC OSD Operation Nodes
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
required For the In OCNCC, this would be the Operation Set name as configured in the Open
Services Development screens. ExamplesOSD Action
Generic Operation OSD action, the Action field must be given. This
provides a reference to the WSDL that NCC has generated.
http://sms/wsdls/TELCO/Prepaid/BuyPrepaidPack
required For the In OCNCC, this would be the Operation name as configured in the Open Services
Development screens. ExamplesOSD Operation
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.
BuyPrepaidPack
optional For the ExamplesOSD Parameters
Generic Operation OSD action, the Parameters field may be given to
provide value for inputs to the OSD action.{
"CC_Calling_Party_Id": "64210635462"
}
optional For the ExamplesOSD Result Tests
Generic Operation OSD action, the Result Tests field may be given
to request tests are performed on OSD results.[
{
"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. 
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: 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. 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). 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.Generic 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: 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. 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). 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 “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: 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. 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). 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 “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: 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. 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). 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 “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. Click on the grey box to the left of the field to access additional controls: 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. 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). 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
644401010,6422010101
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: Click on the grey box to the left of the field to access additional controls: 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.OSD Fields of Unknown Types
{
"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
}
]
}