This configuration setting provides the specific URL of the SPML web service for use in the SPML test front-end.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="VI.SPML.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<applicationSettings>
<VI.SPML.Properties.Settings>
<setting name="SPMLTestFrontend_SPMLService_AESPMLService" serializeAs="String">
<value>http://<Servername>:<Port>/<web service name>/AESPMLService.asmx</value>
</setting>
</VI.SPML.Properties.Settings>
</applicationSettings>
</configuration>
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
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.
The result is displayed in the text field SPML Response (XML).
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 executing scheduled tasks. The DBQueue Processor processes tasks in the DBQueue. The DBQueue Processor uses several slots for executing tasks in parallel.
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 DBQueue Processor configuration settings are controlled by the staging level. If you modify the database staging level, the configuration settings are changed.
Setting | Database Staging Level | ||
---|---|---|---|
Development Environment | Test environment | Live Environment | |
Maximum DBQueue Processor runtime | 20 minutes | 40 minutes | 120 minutes |
Maximum number of slots for DBQueue Processor | 5 | 7 | Maximum number of slots according to the hardware configuration |
The DBQueue Processor configuration settings are configured for normal operations and must not be modified normally. 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 testing or development environments for reasons of performance, you must modify the following configuration parameter settings in the Designer.
Configuration parameter | Meaning |
---|---|
QBM | DBQueue | CountSlotsMax |
This configuration parameter specifies the 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 |
This configuration parameter regulates the maximum runtime of the central dispatcher. Tasks on slots currently in use are still processed when the timeout expires. Then the slot database schedules are stopped and the central dispatches exits. The lowest permitted value for runtime is 5 minutes; the maximum permitted value is 720 minutes. |
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy