This configuration setting provides the specific URL of the SPML web service for use in the SPML test front-end.
On the installation medium, copy the VI.SPMLTestFrontend.exe and VI.SPMLTestFrontend.exe.config files from the QBM\dvd\AddOn\SPML\Testfrontend directory into the One Identity Manager installation directory.
To declare the configured web service in the test front-end, change the VI.SPMLTestFrontend.exe.config file.
You can then start the VI.SPMLTestFrontend.exe file.
It is possible with the SPML test front-end to test and analyze SPML web service functionality. The front-end is used exclusively to analyze the SPML web service and test the functionality.
NOTE: Long term usage of the front-end for controlling the SPML Web Service is not planned.
To test the SPML web service functions
Start the SPML test front-end using the VI.SPMLTestFrontend.exe file.
Select the SPML web service function to test from the Choose Request list.
The corresponding XML queries are displayed in the SPML Request (XML) text field.
You can edit the XML request before sending it to the SPML Web Service. Always check the predefined section of the XML request and modify the schema defined in the target system for SPML support. The predefined sections are supposed to provide help for formulating SPML compliant requests.
Set the Increment request IDs automatically option if the request ID passed to the XML queries should be incremented. This option is disabled by default and the given request ID is used.
Send the query to the SPML web service using the Access button.
The result is displayed in the SPML Response (XML) text field.
If a new object is added in the target system, its key is added to the Known Objects list. An iterator is returned if a search is carried out with a limited result set and the result list cannot be returned in its entirety. This iterator is added to the list of known iterators (Known Iterators). The search can be continued with this iterator.
You will find detailed error messages in the log file. This is stored in the directory that you specified in the LogDirectory option in the SPML web service configuration file.
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.
You can select which agent type takes over the processing of internal tasks when you use the to install or update a database.
Database Agent Service: Internal tasks are processed by the Database Agent Service. Ensure that the Database Agent Service is installed and configured. The Database Agent Service is deployed through the One Identity Manager Service plugin.
IMPORTANT: This is an EXPERIMENTAL function. The performance impact on production systems has not been determined. Therefore this feature is not yet covered by support. However, you are welcome to try it (preferably in non-production systems) and if you have any feedback, send it to OneIM.Beta@oneidentity.com.
SQL Server Agent: The internal tasks are processed by the SQL Server agent. This creates the required database schedules. Ensure that the SQL Server agent is started.
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.
|
Setting |
Development environment | Test environment | Live environment |
|---|---|---|---|
|
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 the 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 test environments and development environments because several databases may be located on a server. If it is necessary to change the settings for test environments or development environments 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.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center
