Managing Tickets

Tickets support the concept of scheduled change management: scheduling a change to an identity management object for some time in the future instead of performing the change right away. A ticket system also provides a way to automate and manage cascading changes to inter-related identity management objects that must be carried out as a result of a change to one of the related objects.

Ticket management tasks generally include:

  • Creating new tickets for changes to identity management objects

  • Viewing tickets to check their status and content

  • Making modifications to tickets; for example, to correct errors in ticket data that are hindering ticket processing

  • Processing tickets

  • Deleting tickets

DirX Identity provides a built-in ticket system that can manage tickets for all standard objects - users, business objects, privileges and so on - and also supports the integration of external ticket systems and target system service management scenarios.

The next sections provide conceptual information about DirX Identity’s internal ticket system not covered in other DirX Identity documents and outlines DirX Identity support for customer-specific tickets.

For detailed information about DirX Identity’s internal ticket system and how to integrate service management scenarios into DirX Identity, see the DirX Identity Use Case Document Service Management.

Understanding Internal Tickets

DirX Identity’s internal service management component is its built-in ticket system, which allows you to specify the changes to be made to an object and then specify a due date for when the change is to occur.The ticket object provides temporary storage for the change data to be processed at the specified date, and the DirX Identity services process the change data automatically when the specified due date arrives.

This section describes the internal ticket system’s design and operation, including:

  • Ticket structure

  • Ticket folder structure

  • Ticket naming scheme

  • Ticket life-cycle

  • Ticket states

The section also describes how to view and manage internal ticket objects in DirX Identity Manager’s Provisioning view.

Understanding Internal Ticket Structure

DirX Identity’s internal ticket system supports a two-tier ticket structure:

  • The master ticket contains all changes to be directly applied at a specific date (the due date). If no direct changes are available, the master ticket acts as an informational ticket that connects the lower-level sub-tickets.

  • The sub-ticket is linked to the master ticket and represents one or more attributes to be approved or an assignment to be approved.

The following figure shows the two-tier ticket structure and the relationship between object actions and ticket structure.

Ticket Structure
Figure 1. Ticket Structure

As shown in the table, the first four columns represent the four possible actions that can be performed on a complex object (for example, a user or a privilege):

  • Attribute changes (one or more attributes) that do not require approval.

  • Attribute changes (one or more attributes) that require approval. If the attributes changes require different approval workflows, the corresponding number of sub-tickets is created.

  • Assignment changes (one assignment) that does not require approval.

  • Assignment changes (one assignment) that requires approval. Each assignment change creates an individual approval workflow, which results in the corresponding number of sub-tickets.

The internal ticket system creates a master ticket and one or more sub-tickets depending on the combination of these actions (marked with an X in the corresponding columns). The table shows only a maximum of two sub-tickets. More are possible.

Some interesting cases are:

1 - Attribute change without approval: only creates a master ticket that is resolved at the due date.

6 - Attribute change with approval combined with an assignment without approval: the master ticket contains the assignment that is applied at the due date. The sub-ticket contains the attribute change that is to be approved first before it can be applied to the object.

7 - Attribute change with approval combined with an assignment with approval: in this case, an empty (or so called info) master ticket is created. It connects the two sub-tickets that each contains one of the required approvals.

10 - Assignment with approval: in this case, the sub-ticket is merged with the master ticket. This is only possible if there are no changes that need no approval and if there is only one sub-ticket available. Case 5 represents the same situation, but for an attribute approval.

As mentioned earlier in this section, a complex object change can consist of four possible actions, as shown in the following figure:

Relationship between Object Changes and Ticket Structure
Figure 2. Relationship between Object Changes and Ticket Structure

The master ticket contains all changes without approval. The sub-tickets contain either an attribute change or an assignment to approve.

If changes without approval do not exist and there is only one potential sub-ticket, the resulting structure is a simple ticket with only one action to approve. The following figure illustrates this structure:

Simple Ticket
Figure 3. Simple Ticket

As shown in the figure, the sub-ticket is merged with the master ticket, which results in a simpler ticket structure.

Understanding Internal Ticket Folder Structure

Internal tickets are organized into the following folder structure in DirX Identity Provisioning’s Tickets tree view:

  • The tree for internal tickets starts at Tickets -> Internal.

  • A type folder exists for each object type; for example, Users, Roles, and so on.

  • Date folders that reflect the due date are created under each type folder; for example, 2011-09-05.

  • The date folder contains the ticket objects.

Here is an example:

Tickets → Internal → Users → 2011-09-05

Understanding Internal Ticket Naming

DirX Identity’s internal tickets are organized into master tickets and sub-tickets, as described in "Understanding Internal Ticket Structure".

DirX Identity names a master ticket according to the following scheme:

  • The first part is the object name; for example, Tinker Boris for a user.

  • The second part is created dynamically and contains the creation time; for example, 13:45:12. This scheme allows for creating several tickets for the same object within the same day.

  • If two tickets for the same object are created within the same second, DirX Identity automatically adds an extension; for example, -1.

  • The ticket status is displayed in the tree and as a header in the property page (Manager only); for example, Input.Completed.

Here is an example of master ticket naming:

Tinker Boris 13:45:12 (Input.Completed)

Tinker Boris 13:45:12 -1 (Input.Completed)

Master tickets can contain sub-tickets. DirX Identity names a sub-ticket according to the following scheme:

  • The first part is the operation; for example, ADD.

  • The second part is the name of the resource; for example, Analyst Reports.

The two-tier naming scheme allows the master ticket to represent the subject, while the resources that are to approve are visible below it.

Here is an example of a sub-ticket name:

ADD Analyst Reports

Understanding the Internal Ticket Life-cycle

Administrators create tickets by supplying a Due Date value for the change in Web Center or DirX Identity Manager. DirX Identity processes - for example, request workflow activities - can also create tickets as required. You can find more information about how to create tickets at the user level in the following locations:

  • The section "Working with Due Dates" in the chapter "Using the Web Center" in the DirX Identity User Interfaces Guide

  • The section "Using the Provisioning View" in the chapter "Using DirX Identity Manager" in the DirX Identity User Interfaces Guide

  • The section "Working with Internal Tickets" in the "Follow-on Tutorials" chapter of the DirX Identity Tutorial

  • The context-sensitive help for objects displayed in DirX Identity Manager and Web Center

DirX Identity’s Services layer creates a ticket automatically if a change order contains a due date. Internal tickets can be created for three operation types:

  • Object creation - if object creation works with a request workflow, the ticket is created from the workflow’s ApplyChange activity. Before this point, the object exists only as an order in the workflow.

  • Object modification - the ticket is created immediately if a due date is present.

  • Object deletion - the ticket is created immediately if a due date is present.

The scheduled Process Internal Tickets workflow regularly checks the state and due date of all tickets and processes tickets that are ready to process. You can find more information about this workflow in the following locations:

  • The section "Working with Internal Tickets" in the DirX Identity Tutorial "Follow-on Tutorials" chapter, which demonstrates how to run this workflow by hand to initiate ticket processing.

  • The "Internal Service Management "use case described in the DirX Identity Use Case Document Service Management, which describes how to set up and run this workflow as part of setting up the built-in DirX Identity ticket system.

  • The section "Process Tickets Internal Workflow" in the chapter "Using the Maintenance Workflows" in the DirX Identity Application Development Guide, which provides configuration and operation information about this workflow.

A ticket is marked for deletion when a DirX Identity process sets its DELETED state and provides an expiration date. The DirX Identity Services layer uses the Cleanup Objects workflow to remove all tickets that are in state DELETED, that have an empty history and whose expiration dates have been reached or are blank. The Cleanup Workflow is a Tcl workflow that uses the Policy Agent to run consistency rules for object cleanup. It can be called explicitly or periodically by the scheduler. You can find more information about this workflow in the section "Cleanup Objects Workflow" in the chapter "Using the Maintenance Workflows" in the DirX Identity Application Development Guide.

Understanding Internal Ticket States

The following figure shows the possible ticket states and the state change flow.

Ticket States
Figure 4. Ticket States

The ticket states are:

(None) - the service layer (or any service that uses it) creates a ticket either in Input.Completed or InApproval status. Input.Completed is used if no approval is necessary before the ticket is applied. InApproval is used if an approval is necessary. In this case, the ticket is linked with the corresponding approval workflow.

Input.Completed - the ticket is ready to be processed by the Process Internal Tickets service.

InApproval - the ticket requires the corresponding approval workflow to complete. If the approval is successful, the ApplyChange activity runs. This activity sets the ticket state to Approval.Accepted if the approval is successful (accepted). If the activity doesn’t work correctly or the approval is not successful (rejected), the activity does not propagate this situation. During the next run of the Process Internal Tickets service, the situation is detected and the state is set appropriately.

Approval.Accepted - the ticket state after an accepted approval. This ticket is processed again at the due date by the Process Internal Tickets service.

Approval.Rejected - the ticket state after a rejected approval. This is an end state.

Approval.Error - the ticket state after a failed approval workflow. This is an end state.

ApplyChange.Completed - the ticket state after successful ticket processing by the Process Internal Tickets service at the due date. All completed orders for attributes and assignments are resolved. This is an end state.

ApplyChange.Error - the ticket state after unsuccessful processing by the Process Internal Tickets service at the due date. This is an end state.

Use the default query folders provided for internal tickets in the Tickets → Internal → _Queries subtree (see "Working with Internal Ticket Objects" for details) to explore tickets of a specific state, especially tickets in the ApplyChange.Error state. Check the reason and then try to solve the problem.

Working with Internal Ticket Objects

When you log into DirX Identity Provisioning and select Tickets from the view bar, DirX Identity displays a hierarchical tree of tickets that you are allowed to manage in the left-hand pane. The following figure shows the Tickets view.

Viewing Internal Tickets with DirX Identity Manager
Figure 5. Viewing Internal Tickets with DirX Identity Manager

As shown in the figure:

  • The Internal subtree displays DirX Identity’s internal tickets.

  • The _Queries subtree displays the queries you can run on internal tickets. DirX Identity provides a set of default queries; for example, to search the Internal tree for tickets with specific status, for active tickets, for error tickets and processed tickets, for tickets with time constraints and tickets that perform specific operations on specific object types. You can also create your own queries; see the topic "Creating a Query Folder" in the "Core Components" section of the DirX Identity Manager online help for details.

  • The other folders in the Internal subtree are organized according to object types and due dates as described in "Understanding Internal Ticket Folder Structure" and named according to the scheme described in "Understanding Internal Ticket Naming".

  • You can also view the ticket state in the tree; for example, InApproval or Input.Complete.See the section "Understanding Internal Ticket States" for details.

The Tickets tree view may display separate subtrees of customer-specific ticket types in addition to the Internal subtree, if external ticket systems have been integrated into DirX Identity.

To view the properties of a ticket, click its entry in the tree.DirX Identity also provides a search dialog that you can use to select and display a subset of these objects.For more information, see the Core Components" section of the DirX Identity Manager online help.

When you select a ticket object, DirX Identity displays the ticket state in the property dialog heading and a set of tabs that you can use to view (and edit) the ticket’s properties.Click the tabs in the property dialog to move between the different property categories.See the context-sensitive help for information about internal ticket property dialogs and attributes.

To change the value or one or more of the properties displayed in a tab, click Edit.Manager keeps the changes you make to the object in its internal cache until you click Save.As long as you do not use Save, you can use the Manager’s Reset function to restore the settings to their old values (the values that are stored in the Identity Store (Provisioning Configuration)).

About Customer-Specific Tickets

Customers can also create their own customized ticket solution.In the DirX Identity Provisioning → Tickets view, customer-specific tickets are displayed in separate customer subtrees at the same level as the DirX Identity-supplied Internal subtree.

The folder structure, naming schemes, states and life-cycle of these tickets - creation, modification, processing and deletion - is customer-specific.For ticket deletion, we recommend using a process that uses the Cleanup Objects workflow provided with DirX Identity.For more information about this workflow, see the section "Cleanup Objects Workflow" in the section "Understanding the Tcl-based Maintenance Workflows" in chapter "Using the Maintenance Workflows" in the DirX Identity Application Development Guide.

The section "Working with Source Tickets" in the DirX Identity Tutorial "Follow-on Tutorials" chapter demonstrates how to integrate an external "source" ticket system with DirX Identity’s provisioning mechanism via a sample Web service.The Service Management DirX Identity Use Case Description demonstrates this and other alternatives for integrating service management systems into DirX Identity.