Message types

The following table shows the format of the input message (in this case UserQuery, the input argument to the queryUsers operation).

Type	Elements	Description
AbstractRequest	clientExtId	ExtID of the client. Applies to all messages. Limits the scope of any operation to the specified client. Alternatively, clientName can be used.
	clientIndependent	If it is true, the operation will not be restricted to one client.Currently, only the operation "queryUsers" supports "clientIndependent=true". For further details, see the chapter Device password.
	clientName	The name of the client. Alternatively, clientExtId can be used.
	context	Arbitrary context name / value pairs (currently unused).
	detail	Degree of detail of the result. 0: low; 1: medium; 2: high
	detailLevels	Define the detail level of specific objects: profileDetailLevel propertyDetailLevel applicationDetailLevel credentialDetailLevel certificateDetailLevel mobileSignatureDetailLevel samlFederationDetailLevel unitDetailLevel userDetailLevel userLoginInfoDetailLevel (not in use at the moment) roleDetailLevel authorizationDetailLevel authorizationDataroomDetailLevel clientDetailLevel policyDetailLevel templateDetailLevel enterpriseRoleDetailLevel defaultDetailLevel: If one of the above is not set, the default level is applied. The detail levels above are defined by an enum with the levels: EXCLUDE: The specific object is excluded from the response. LOW: include only primary object information (excl. subobjects). MEDIUM: The response contains all object attributes and the subobjects. HIGH: like MEDIUM, but includes the technical fields.
AbstractQuery(extends AbstractRequest)	maxRecursionDepth	The maximal depths for recursive queries.
	numRecordsskipRecords	Parameters for partial result sets.Example: query for user with loginId "*", then iteratively retrieve records in batches of 1000:numRecords=1000, skipRecords=0numRecords=1000, skipRecords=1000,numRecords=1000, skipRecords=2000, ...
	sorting	The element is used for the sorting. Multiple sorting elements can be defined per query. The priority of the sorting depends on the order of the elements in the query. The following parameters have to be defined for each sorting: fieldName, order. The fieldName corresponds to the field of the complex value types that is used for sorting. For the supported fields see sortByField. The order corresponds to the ordering of the response. Possible values are "ASC" for ascending sort, and "DESC" for descending sort. The sorting element allows more control over the sort order than sortByField and sortOrder. Additionally, it is assured that the sort order is deterministic.
	sortByField	The sorting element is preferred over sortByField and sortOrder. The field that is used for the sorting. The sort parameter corresponds to the name of the complex value types. The following names are supported: queryUsers: loginId, name, firstName, telephone, email, state, clientName, ctlModDat queryUnits: extId, name, displayName, displayAbbreviation, hname, clientName, ctlModDat queryCredentials: user, userId, subject, issuer, fingerprint, issuer_name_id, subject_name_id, state, validFrom, validTo, ctlModDat queryProfiles: name, description, user_name, user_firstname, unit_name, clientName, status, ctlModDat queryClients: name, displayName, ctlModDat queryRoles: name, application, description, applicationDisplayName, ctlModDat queryPolicies: name, description, type, ctlModDat queryTemplates: docType, eventType, tmplColl, precedence, ctlModDat queryEnterpriseRoles: name, description, displayName queryApplication: name, url, description, displayName, ctlModDat The field cannot be used together with the sorting element.
	sortOrder	The sort order of the result. Possible values are "ASC" for ascending sort, and "DESC" for descending sort. Always specify the sortOrder if sortByField is set.
	technicalFilter	Allows filtering of the result based on the technical fields. The search criteria are: ctlCreDatFrom, ctlCreDatTo, ctlModDatFrom, ctlModDatTo. "CreDat" stands for creation date, "ModDat" for modification date. These refer to technical database fields of a row. They are thus well suited for improved provisioning tasks. The parameter must be a valid XML date (w3c dateTime). Example: 2011-06-09T13:00:00+02:00 Changes applied to properties of a certain entity also result in updates to the technical fields of that entity. Therefore, queries using the technical filter include changes on an entity itself as well as its properties. Limitation: The technicalFilter is currently only evaluated for the methods "queryUsers", "queryProfiles", "queryRoles" and "queryCredentials" of the SOAP admin interface.
AbstractGet (extends AbstractRequest)	maxRecursionDepth	The maximal depth for recursive queries.
AbstractHistoryGet (extends AbstractGet)	dateFromdateTo	Only return events that are in the time range. The parameter must be a valid XML date (w3c dateTime).Example: 2011-06-09T13:00:00+02:00
	actorExtId	ExtId of the user that did the operation.
	typeOfOperation	Type of the operation (INSERT, UPDATE, DELETE).
	numRecordsskipRecords	Same as in AbstractQuery.
	versionFromversionTo	Filter for version range. Return only versions greater or equal versionFrom and smaller or equal versionTo.