Required permissions
To process filter expressions with relational comparison operators, the user account used requires the ApiServer_SCIM program function. Exceptions are the equals test (eq) and the presence of a value (pr). This applies to both filters in the URL parameter filter and when using the Path filter in patch operations.
If certain users are allowed to handle filter expressions, you can assign the permissions to the users through permissions groups.
-
The QBM_ApiServer_SCIM permissions group is provided for non role-based login. This group owns the program function. Add the system users to the permissions groups. Administrative system users automatically obtain these permissions groups.
-
The QER_4_ApiServer_SCIM permissions group is provided for role-based login. This group owns the program function. The permissions group is linked to the Base roles | API Server SCIM filter application role. Add the identities to the application role.
Base URL requests
The SCIM 2.0 specification provides optional requests for the SCIM service provider base URL. These requests can contain a filter expression if required. This is mainly used to search for objects when their endpoint is not known exactly and so the search must be across endpoints.
The SCIM plug-in supports these requests. In the filter, only logical OR operations and the comparison operators eq, sw, ew as well as co are allowed, which must reference the Resourcetype metadata.
Example:
https://<servername>.<domainname>/ApiServer/scim/v2?filter=(meta.Resourcetype eq “Locality”) or (meta.Resourcetype sw “D”)
The result can contain a list of objects of different types, but the number of returned elements must not exceed 10,000 for load and performance reasons. Otherwise an error message of type tooMany is returned. The search condition should be refined and the result should be more restricted.
Endpoint URL requests
The SCIM 2.0 specification provides for optional filter, attributes, count, and startIndex parameters for requests to the endpoints defined by /ResourceTypes. Requests with the ID of a concrete object (the URL contains the id of the object) can have the excludedAttributes and attributes parameters. The SCIM plug-in supports these parameters.
Endpoint requests return a list of all elements (or all elements matching the filter). This allows the SCIM client to initiate index-based paging by specifying the desired number of records per page ( count and startIndex parameters).
Example: Endpoint request
http://<servername>.<domainname>/ApiServer/scim/v2/Person
Example: Request the first 100 elements of an endpoint with paging
http://<servername>.<domainname>/ApiServer/scim/v2/Person?startindex=1&count=100
Example: Endpoint request with filter
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"
Example: Endpoint request with filter and output of two additional properties
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"&attributes=ExitDate,TechnicalEntryDate
Example: Endpoint request for an object
http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8
Example: Endpoint request for specific properties of an object
http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8?attributes=cn,members
The tasks queued in the DBQueue are the result of triggering, modifications to configuration parameters (for example, changes to a configuration parameter concerning inheritance) or running scheduled tasks. The DBQueue Processor processes tasks in the DBQueue. The DBQueue Processor uses several slots for running tasks in parallel. Internal tasks are processed by the Database Agent Service. Ensure that the Database Agent Service is installed and configured.
Detailed information about this topic
You use the staging level of the One Identity Manager database to specify whether the database is a test database, development database, or a live database. A number of database settings are controlled by the staging level.
If you change the database's staging level, the following settings are configured.
Table 185: Default settings for development, test, and production databases
|
Maximum DBQueue Processor runtime |
20 minutes |
40 minutes |
120 minutes |
|
Maximum number of slots for the DBQueue Processor |
5 |
7 |
Maximum number of slots according to the hardware configuration |
The DBQueue Processor default configuration settings are configured for normal operation and do not normally need to be modified.
If several databases are operating in a managed instance in Azure SQL Database, you can fix the number of slots. In the Designer, adjust the following configuration parameters.
-
QBM | DBServerAgent | CountSlotAgents: Exact number of slots. If the configuration parameter is set, the given number of slots are always set up. There is no internal calculation of the number of slots based on the hardware configuration. Changing the server's configuration has no effect. The value 15 is recommended.
NOTE: This configuration parameter is not recommended for implementing a database on an SQL Server. For implementing a database on an SQL Server, it is standard practice to use the hardware configuration to determine the slots.
The configuration settings are reduced for testing or development because several databases may be located on a server. If it is necessary to change the settings for testing or development for reasons of performance, you must modify the following configuration parameter settings in the Designer.
-
QBM | DBQueue | CountSlotsMax: Maximum number of slots to be used.
Use this configuration parameter to reduce the number of slots if required. Values lower than 5 are not permitted.
Exception: Enter a value of 0 for using the maximum number of slots available based on the hardware configuration.
-
QBM | DBQueue | KeepAlive: Maximum runtime of the central dispatcher. Tasks on slots currently in use are still processed when the timeout expires. Then the slot are stopped and the central dispatcher exits.
The lowest permitted value for runtime is 5 minutes; the maximum permitted value is 720 minutes.
Related topics
If errors occur during initialization of the DBQueue Processor, messages are written to the application log. You can use the results display in the Microsoft Management Console, for example, to view the application log.
Use the QBM | DBServerAgent | CreateNotification configuration parameter to configure in which cases error messages are written to the application log. In the Designer, you can modify the configuration parameter as required.
Permitted values are:
-
0: No logging.
-
1: Only success messages are logged.
-
2: Only error messages are logged.
-
3: All messages are logged.
