TR-369 Training - Using allow_partial and required_parameter flags

Flexible create, update, and delete with allow_partial

There are three USP messages that are used to change the state of an Agent’s service elements: Add, Set, and Delete. Since these messages can be used for a number of different use cases, they contain mechanisms to ensure that the Controller is able to configure service elements through the Agent in a way that guarantees the state it is trying to achieve. These mechanisms include the allow_partial and required_parameter flags in these messages.

The elements of Add, Set, and Delete messages operate directly on an Object or Object Instance Path. This sets the scope of each part of the message in a context that proceeds from specific to general. As the processing of the message succeeds or fails in each context, the success or failure is passed up through processing to determine whether an update to a particular object fails, or if the message itself fails and throws an error.

Required parameters

Whether or not a given object succeeds in being created or updated is partly determined by the required_parameter flag. This flag is set on parameters that the Controller wants updated or configured upon the object’s creation. If a required parameter fails to be configured for any reason, the operation on that particular object will also fail.

Error, or Response?

The allow_partial flag determines whether or not a message should fail if any of the individual objects that were requested to be created, updated, or deleted fail to do so. If set to false, the Controller wishes the Agent to apply no changes if any of the changes it requested fail. In these cases, the Agent returns an error in response to the Add, Set, or Delete message.

If the allow_partial flag is set to true, the Controller wishes the Agent to make any changes it can, even if some of them fail. This rarely results in an Error response from the Agent, favoring instead a Response message that contains detailed information about which operations succeeded or failed.

The behavior of allow_partial and required parameters is outlined in detail in the messages section of the USP spec, with a helpful table that explains the different permutations of allow_partial, required_parameters, and the response behavior of the Agent:

allow_partial Required Parameters Required Parameter Failed Other Parameter Failed Response/Error Oper_status of Object Contains param_error
True/False No - No Response oper_success No
True/False No - Yes Response oper_success Yes
True/False Yes No No Response oper_success No
True/False Yes No Yes Response oper_success Yes
True Yes Yes - Response oper_failure Yes
False Yes Yes - Error N/A Yes

Build your USP/TR-369 solution

Test against an automated, scriptable USP Controller with thousands of pre-defined test cases.

Learn more

Develop your solution even faster with comprehensive automated test cases and a scriptable USP Controller.