Skip to main content
Version: 7.2405.x.x LTS

Message types

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

TypeElementsDescription
AbstractRequestclientExtIdExtID of the client. Applies to all messages. Limits the scope of any operation to the specified client. Alternatively, clientName can be used.
clientIndependentIf 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.
clientNameThe name of the client. Alternatively, clientExtId can be used.
contextArbitrary context name / value pairs (currently unused).
detailDegree of detail of the result. 0: low; 1: medium; 2: high
detailLevelsDefine 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)maxRecursionDepthThe maximal depths for recursive queries.
numRecordsskipRecordsParameters 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, ...
sortingThe 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.
sortByFieldThe 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, cred_Extid, vascoCRSupported, vascoROSupported
  • 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.
sortOrderThe 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.
technicalFilterAllows 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)maxRecursionDepthThe maximal depth for recursive queries.
AbstractHistoryGet (extends AbstractGet)dateFromdateToOnly 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
actorExtIdExtId of the user that did the operation.
typeOfOperationType of the operation (INSERT, UPDATE, DELETE).
numRecordsskipRecordsSame as in AbstractQuery.
versionFromversionToFilter for version range. Return only versions greater or equal versionFrom and smaller or equal versionTo.