Background Information

This chapter describes basic information that is important for understanding the descriptions of the use cases presented in this document.

About Domain Names

You can choose the Domain Name of the Provisioning domain freely. Typically, it reflects the customer name or the project name.

Due to restrictions of various operating systems (especially UNIX) it is not possible to use any character of the UTF-8 character set in file, folder or service names. As a result, DirX Identity generates a Technical Domain Name from the user’s Domain Name. This Technical Domain Name contains only alphanumeric characters, underlines and dashes.

DirX Identity uses the domain and technical domain name to distinguish items such as files, folders and services.

For details about naming schemes, see the chapter "Managing DirX Identity Servers → Managing the Java-based Server → Naming Schemes" in the DirX Identity Connectivity Administration Guide.

Note that the domain name for which a specific Java-based Server works is visible in the Java-based Server tab of Java-based Server object in the Connectivity configuration.

About Message Topics

If there is a common Connectivity domain for all Provisioning domains, there is only one messaging service instance. This instance transfers messages common to all Provisioning domains and messages specific to one Provisioning domain.

DirX Identity uses the technical domain name in the message topic to associate the messages with their related Provisioning domain.

For a detailed explanation of the Messaging Service in DirX Identity, see the section "Managing DirX Identity Servers → Managing the Messaging Service → Using Messages in DirX Identity " in the DirX Identity Connectivity Administration Guide.

Note that the flag Include domain into topic in the General tab of the Domain object specifies whether publishers - that is, all clients - must include the domain name into the topic. This is the default setting. Resetting this flag is only allowed for specific migration scenarios. See the DirX Identity Migration Guide for more information.

Be sure to configure clients that do not read this flag correctly; for example, the Windows Password Listener.

According to this flag, the subscribers - for example, the Java-based Server adaptors - only retrieve messages that belong to their domain.

About Workflow Configuration

You can configure request and provisioning workflows for each Provisioning domain.

Request Workflows

Configure these workflows in the corresponding Provisioning domain.

Java-based Workflows

Java-based workflows include provisioning workflows and password change workflows that work between a DirX Identity domain and connected systems as well as event-based processing workflows that work on entries within the Provisioning domain.

Configure these workflows in the common Connectivity Configuration domain in the folder

Workflows → domain_name

Note: When using the Target System Wizard to set up new target systems, these workflows are created in these domain-specific folders by default.

Tcl-based Workflows

There is no technical restriction on where to configure Tcl-based Workflows. We recommend that you store domain specific workflows in the folder:

Workflows → domain_name

This makes it easy to understand what a specific workflow is for.

Schedules

The Java-based Server loads all active Java-based schedules only for a specific domain from the path ConnectivitySchedulesdomain.