...
The definition of this API is:
| Web Service | Type | Description | Req? | Val? |
<sp:UpdateUserRequest>
|
|
|
|
|
|
| | <userId>?</userId> | string(50)
| The User ID for the user to be updated. The User ID must already exist in the ServiceOptimizer database. | 
|
|
|
| Optional section containing the details of updates to the user to be made. |
| | | |
|
|
|
| <name>?</name> | string(50) | If supplied, the value will be used as the new name of the user. |
| | | |
|
|
|
| <enabled>?</enabled> | Boolean | If supplied, the value will be used as the new value that defines if the user is permitted to use ServiceManager. |
| | | |
|
|
|
| <profile>?</profile> | string(10) | If supplied, the value will be used as the new value for the user profile for the user. The user profile must exist in the ServiceOptimizer database |
|
|
| <authentication>?</authentication>
| AuthType
| If supplied, the value will be used as the new value that defines how the user's login will be authenticated. Either |
INTERNAL or SECURED or LDAP. If LDAP, then the user's login will be authenticated using the configured external LDAP server; otherwise, authentication will be performed by ServiceScheduling. See password below. |
| | | |
|
|
|
| <password>?</password> | string(50) | If supplied, the value will be used as the new value for the user's password, if the authentication is set to INTERNAL. Ignored if authentication is LDAP. |
| | |
|
|
|
| <unitType>?</unitType> | UserUnitType | If supplied, the value will be used as the new value for the user's unit type. This can be ROOT, BRU, DRU or FRU. |
| | |
|
|
|
| <respUnit>?<respUnit> | string(8) | If supplied, the value will be used as the new value for the user's RU. If unitType is ROOT, respUnit must be the top level RU, and will default to this if omitted. If unitType is BRU, respUnit must be an BRU reference. If unitType is DRU, respUnit must be an DRU reference. If unitType is FRU, respUnit must be an FRU reference. |
| | | | | |
| Optional section containing the details of updates to user roles and formal parameters. The <role> section may be repeated zero or more times, as required. |
| | | |
|
|
|
| <action>?</action> | RoleAction | One of ADD, UPDATE or REMOVE. - When
ADD, the <role> section will result in the defined role (and supplied formal parameters, if any) being added to the user. - When
UPDATE, the <role> section will result in any current formal parameters for the defined role being deleted from the user, and replaced with the supplied formal parameters (if any). - When
REMOVE, the <role> section will result in the defined role (and any associated formal parameters) being deleted from the user.
Required for each <role> section supplied. | |
| | |
|
|
| <id>?</id> | int | A valid role. Required for each <role> section supplied. | | |
| |
| Optional section containing the details of updates to user formal parameters. The <formalParameter> section may be repeated zero or more times, as required. Each supplied <formalParameter> section will be attempted to be matched against the required parameters defined by the supplied role <id> in the current <role> section. Only when the <formalParameter>'s <parameterType> and <parameterName> match a required parameter will the formal parameter be added - supplying a <formalParameter> section that does not match a defined formal parameter of the supplied role will result in an error. So, for example, if the supplied role <id> defines that FRU(FRU_ID.F).Team.Oper is a formal parameter, then in the <formalParameter> section: - The
<parameterType> must be FRUID; - The
<parameterName> must be "F"; and - The
<value> must be a single value for parameter F.
Note that multiple values may be supplied for the same <parameterType> and <parameterName> by supplying a separate <formalParameter> section for each value. If you provide the same parameterName, type and value multiple times this will result in a error. The <formalParameter> section is ignored when the <action> is REMOVE. |
| | | | <parameterType>?</parameterType> | ParameterId
| One of FRUID, OPERID or TEAMID. - When
FRUID, the supplied formal parameter <value> will be used where the supplied role defines a formal parameter of the FRU_ID parameter type with name <parameterName>. - When
OPERID, the supplied formal parameter <value> will be used where the supplied role defines a formal parameter of the OPER_ID parameter type with name <parameterName>. - When
TEAMID, the supplied formal parameter <value> will be used where the supplied role defines a formal parameter of the TEAM_ID parameter type with name <parameterName>.
Required for each <formalParameter> section supplied. | | |
| |
|
|
| <parameterName>?</parameterName> | string(20) | The name of the formal parameter. Required for each <formalParameter> section supplied. | | |
| | |
|
|
| <value>?</value> | string(50) | The value for the formal parameter, being: - the FRU reference of the FRU;
- the Operative reference of the Operative; or
- the Team name of the Team
as required (based on the <parameterType> value). Alternatively, the wildcard value of "*" (without quotes) can be used, to mean either all FRUs, all Operatives, or all Teams (depending on the <parameterType>). Required for each <formalParameter> section supplied. | | |
| |
|
|
| <assignmentType>?</assignmentType> | AssignmentType
| One of EQ or NEQ. Defines if permission should be given based on the role's formal parameter matching (EQ), or not matching (NEQ). Required for each <formalParameter> section supplied. | |
| | | | | | | |
| Optional, additional formalParameter sections, as required. |
| | | | | | | | |
| Optional, additional <role> sections, as required. |
|
| | Examples
Assume that a new user has been created using the Integration ServiceOptimizer Create User SOAP API, and that this user's ID is 45.
...
