Using DirX Identity Web Admin

This selection displays information about the C++-based Server’s SOAP services.The JMX service handles all requests for maintenance; the Java-based Server uses it to send maintenance requests to the C++-based Server and to receive the response information.The SPML connector service handles all messages to and from the connector service.

Each SOAP service selection displays the following information:

The Server State page allows you to control the Java-based server state and provides the following sections:

The Overview page displays the most important parameters. Follow the link (underlined text strings) to display details. The information displayed is:

The server writes snapshots of this page in HTML format as separate files (snapshot-timestamp-counter.html) onto disk into the folder install_path\logs\overview. Use the parameter Maximum No. of Overview Files in the tab Status and Auditing of the Java-based Server object in the Connectivity view group of the DirX Identity Manager to control the maximum number of files.

Each time you open or refresh the Overview page, a snapshot file is written. Use the Autorefresh feature to write pages regularly, for example each 5 minutes. This action allows you to view the server history later on. Click the link at the top of the table to view the list of overview files.

Adaptors listen for incoming events and pass them to the JavaSpace for processing. Adaptors exist for external and internal events, including:

Provisioning dispatchers read messages for provisioning target systems and dispatch them either to the appropriate target system-specific queue or to the respective default queue (for example, domain*.dxm.request.provisiontots._default*).

For each of the provisioning queues, the detail page shows the number of messages that have been received, how many of them could not be dispatched due to an error, how many have been dispatched and whether to the default or to a target system-specific queue.

Listeners specific to a target system read and process messages for that target system. If there is no target system, the messages apply to the connected directory. The listeners are started only on the dedicated servers. The number of listeners per queue depends on the configuration of the connected directory.

For each target system, the detail page shows the listeners for three queues (dxm.request.provisiontots, dxm.request.workflow.provisioning, dxm.setpasswordrequest) with the following counters:

The queue names are suffixed with a target system identifier. It is built using the attributes type, cluster and domain of the target system in lower case: type.cluster.domain. For a target system that is part of a cluster, the domain part is empty and the target identifier is built as type.cluster. For more information on this topic, see the chapter “Managing DirX Identity Servers” → “Distributed Deployments and Scalability” → “Separating Traffic for Selected Target Systems” in the DirX Identity Connectivity Administration Guide.

The resolution adapter is a JMS adapter that is responsible for resolving users. It listens to JMS messages in the queue domain*.dxm.request.user.resolve*.

The WebAdmin detail page allows you to monitor the adapter and shows the following fields, mostly counters. Note that the adapter registers a number of listeners at the queue. This is configured in the domain configuration entry.

This section shows detailed information about the internal state of the server.

If no error activity is configured for a workflow or a failed request cannot be processed by the workflow, the request is placed in the Dead Letter Queue. This part of the Java-based Server administration interface allows you to view the failed requests and responses and to delete them or to process them again.

Web Admin displays a message that indicates whether the adaptor is running or suspended. Click Suspend or Resume to control the adaptor.

The first section of properties shows the status of the queue:

The next two items let you control the maximum number of requests in this queue:

Click Save to save the changes and Reset to discard the changes and to re-set all values to the most recently saved values.

You can view, process, or delete stored requests. Define a filter to get a part of the stored requests:

Use Reset filter to reset the filter.

Use Search requests to generate a list of requests and determine what the errors are. See "Handling the Search Result" below for details.

If you are able to remove the reason for the error - for example, by changing the configuration or re-starting the target system - you can alternatively click Process requests. The handler removes the entries from the queue and sends them to the workflow dispatcher, which selects appropriate workflows to process the requests again.

The last part of this page allows you to clear all requests with a specific topic:

The Logging section allows you to configure and view server log information, including:

See also the "Logging" section in "Managing the Java-based Server" in the DirX Identity Connectivity Administration Guide.

This menu entry displays all active schedules. These are timers that control the timeout of workflows and activities and the waiting time for activities that need retry.

The available columns are:

UID - an internal unique ID.

Time - the initial date for this schedule.

Task - information about the task to be performed.

By default, the Full check schedule is displayed. The workflow engine performs the full check to look for non-processed items. These items could exist if events were not correctly processed.

The Statistics view shows statistics information since the last server start. It presents a set of counters that typically represent the number of received events and responses and of errors. The counters are reset to 0 when the server starts. See also "Statistics" in "Managing the Java-based Server" in the DirX Identity Connectivity Administration Guide.

Statistics are provided for:

Workflow Overview

This statistic provides the following information:

Event Overview

This statistic provides the following information:

Realtime Workflows

This statistic provides the following information:

Request Workflows

This statistic provides the following information:

This section displays all running worker threads in this server. The columns in this list are:

The first line of each Worker Container block provides the following information:

The Worker Container block shows:

Watching this list, you can see the running and waiting worker threads. You can configure the resource families and the number of threads for a Java-based Server at the corresponding configuration object in the Connectivity view (note that changing these parameters requires a restart of the corresponding Java-based Server).

The details button allows you to reduce the number of worker threads or create additional ones temporarily. This information is lost after Java-based Server restart.

After clicking the details button, these fields are displayed:

Click Add or Remove to add or remove threads of this resource family type.

The Action field displays the number of threads that will be added or removed.

Click Save to perform the displayed action (creating the new worker threads and deleting worker threads). Click Cancel to go back to the Workers list without performing any action.

This menu entry shows all loaded (active) workflow definitions. Three types of definitions can be available:

Realtime workflows - shows real-time workflow definitions.

Request workflows - shows request workflow definitions

Open the tree structure (click the triangles) to view the loaded definitions. The tree structure is identical to the folder structure visible in the DirX Identity Manager. Clicking a leaf node (there is no triangle before the entry) displays these fields:

This menu entry shows all workflow instances for the following types of workflows:

Real-time Workflows - shows the real-time workflow instances.

Request Workflows - shows the request workflow instances.

When you select a menu item, a dialog is displayed to specify a filter for selecting specific workflow instances. The following sections provide information about:

Object Name: com.siemens.idm:type=idsj,topic=core,name=Server

Attribute: State - an integer value that represents the server state ranging from 0 to 10, where 10 is good. Internally, the state represents the current server’s use of heap memory. A value below 4 indicates a server with a high memory load.

Object Name: com.siemens.idm:type=idsj,topic=core,name=Statistics

Attribute: SEVERE - the number of SEVERE messages that occurred.

Attribute: WARNING - the number of WARNING messages that occurred.

A high number indicates connected directories that have been unavailable for a long period or misconfigured workflows, or other severe issues.

Object Name: com.siemens.idm:type=idsj,topic= ProvTSListener,name=queueType.type.cluster.resource

where queueType is provisiontots, setpasswordrequest or workflow.provisiontots

and type.cluster.resource is taken from the corresponding attributes of the target system.

Attributes:

name - the queue name the adapter is listening to.

messagesReceived - the number of messages received.

messagesSucceeded - the number of messages that were processed successfully.

messagesRedelivered - the number of received messages that were re-delivered; that is, they were processed before but failed temporarily.

messagesFailedTemporary - the number of messages that could not be processed successfully and were re-delivered with a delay.

messagesFailedFinal - the number of messages that could not be processed successfully and where a retry was not possible; for example, because the maximum number of retries was reached.

Object Name: com.siemens.idm:type=idsj,topic=adaptor,name=AdaptorName

where AdaptorName is, for example, ProvisioningRequestListener, EntryChangeListener, DeadLetterQueue, and so on.

Attribute:*state* - the adaptor’s state: listening, waiting, or suspended.

Attribute: outstandingResponses - the number of current outstanding responses for sent requests received from processing workflows. This field indicates the number of events that are not yet finished. A high number indicates a heavy load. If the value reaches the high watermark, the adaptor enters the waiting state. Note that this is not a real warning case as the server will process these requests and will reconnect to the message broker when the low watermark is reached and will retrieve further requests. Only if the number is constantly high for a very long period should the situation be considered a warning.

Attribute: entryCount - a special attribute for the DeadLetterQueue (DLQ): the number of stored events that could not be successfully processed. A high number indicates connected directories that have been unavailable for a long period, misconfigured workflows or other severe issues.

Attribute: highWater - the high watermark value.

Attribute: lowWater - the low watermark value.

Object Name: com.siemens.idm:type=idsj,topic= ProvMsgDispatcher,name= queueType

where queueType is provisiontots, setpasswordrequest, or workflow.provisiontots.

Attributes:

name - the queue name the dispatcher is listening to.

messagesReceived - the number of messages received.

messagesFailed - the number of messages that could not be forwarded to either the default queue or the target system-specific queue.

Object Name: com.siemens.idm:type=server.extension.adapter,name=resolutionAdapter

Attributes:

JmsConnectionStarted - whether the adapter is currently connected to the Message Broker.

JmsConnectionStarts - how often the adapter has started a JMS connection.

JmsExceptions - how many exceptions have been received from the Message Broker. Such an exception typically means that the JMS connection was lost.

JmsRebinds - how often the adapter has tried to re-bind to the Message Broker after the connection was lost.

MessagesReceived - the total number of messages that have been received.

MessagesSucceeded - how many messages have been processed successfully and resolved the user.

MessagesRedelivered - how many messages have been re-delivered due to failure.

MessagesFailedTemporary - how many messages have failed temporarily. When a failure is considered to be temporary, the adapter tries to re-deliver it to process it after the retry time has expired.

MessagesFailedFinal - how many messages have failed finally. A message fails finally if the error is not temporary or the maximum number of retries has been reached.

MessagesIgnored - how many of the received messages have been ignored. A message is ignored if the user has already been resolved after the change that this message represents. Note that the message contains the time of change. The adapter adds a grace period to cope with potential time differences at client and server.

For each realtime workflow that has run at least once, an object is created with the full workflow name; for example, Ident_Extranet_Realtime from the My-Company scenario:

Object Name: com.siemens.idm:type=idsj,topic=core,name=Statistics,
name0=My-Company,name1=Main,name2=Target Realtime,name3=Extranet Portal,
name4=Ident_Extranet_Realtime

Attribute: START - the number of workflow runs.

Attribute: SUCCEEDED - the number of succeeded workflow runs. The difference of these 2 values contains failed or running workflows.

Attribute: WARNING - the number of workflows with warnings.

Attributes: join.ModifyFailed, join.AddFailed, join.DeleteFailed, join.SearchFailed – each value represents the number of failed request operations. These numbers should be zero or small.

For each request workflow that has run at least once, an object is created with the full workflow name; for example, Manager Nomination from the My-Company scenario:

Object Name: com.siemens.idm:type=idsj,topic=core,name=Statistics,name0=confdb,
name1=workflow,name2=Definitions,name3=My-Company,name4=Approval,
name5=Manager Nomination

Attribute: START - the number of workflow runs.

Attribute: SUCCEEDED - the number of succeeded workflow runs. The difference of these two values contains failed or running workflows.

Attribute: FAILED - the number of failed workflow runs.

Attribute: Apply Changes.SUCCEEDED - the number of succeeded Apply Changes activity runs.