<resource>
<name>ITSM Ticketing Resource</name>
<!-- Connector to the ITSM system -->
<connectorRef type="ConnectorType">
<filter>
<q:text>connectorType = "com.example.itsm.ItsmConnector"</q:text>
</filter>
</connectorRef>
<connectorConfiguration>
...
</connectorConfiguration>
<projection>
<assignmentPolicyEnforcement>none</assignmentPolicyEnforcement>
</projection>
<schemaHandling>
<objectType>
<kind>work</kind>
<intent>ticket</intent>
<delineation>
<objectClass>ri:ticket</objectClass>
</delineation>
<!-- Tickets are projections of cases -->
<focus>
<type>CaseType</type>
</focus>
<!-- Ticket name: use the case OID, so the ticket can be found by the case -->
<attribute>
<ref>ri:ticketName</ref>
<outbound>
<strength>weak</strength>
<expression>
<script>
<code>midpoint.focusContext.oid</code>
</script>
</expression>
</outbound>
</attribute>
<!-- Ticket title from the case name -->
<attribute>
<ref>ri:title</ref>
<outbound>
<strength>strong</strength>
<source>
<path>name</path>
</source>
</outbound>
</attribute>
<!-- Read the ticket state back into the case -->
<attribute>
<ref>ri:state</ref>
<inbound>
<target>
<path>state</path>
</target>
<condition>
<script>
<!-- Do not propagate an (initial) empty state back to the case -->
<code>input != null</code>
</script>
</condition>
</inbound>
</attribute>
<!-- Read the ticket outcome back into the case -->
<attribute>
<ref>ri:outcome</ref>
<inbound>
<target>
<path>outcome</path>
</target>
</inbound>
</attribute>
<synchronization>
<reaction>
<situation>linked</situation>
<actions>
<synchronize/>
</actions>
</reaction>
</synchronization>
</objectType>
</schemaHandling>
</resource>
ITSM Ticketing
|
Manual resource feature
This page describes configuration of Manual resource midPoint feature.
Please see the feature page for more details.
|
|
EXPERIMENTAL
This feature is experimental.
It means that it is not intended for production use.
The feature is not finished.
It is not stable.
The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all.
Use at your own risk.
This feature is not covered by midPoint support.
In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.
|
|
Since 4.11
This functionality is available since version 4.11.
|
Introduction
Manual resources rely on cases (tickets) to track the progress of provisioning operations. By default, the cases are managed internally by midPoint and system administrators handle them in the midPoint GUI.
As an alternative, midPoint can manage the tickets in a real ITSM system (e.g. Jira, ServiceNow, Remedy or a similar tool). The ITSM system is accessed through a regular midPoint resource (with a connector to the ITSM system) that is used exclusively for the tickets. Such a resource is called a ticketing resource.
This feature was introduced in midPoint 4.11. It is built on the regular midPoint synchronization machinery:
-
A midPoint case (
CaseType) is now a projection holder. It can have shadow objects (projections) linked to it, just like a user or an organization. -
The ticket in the ITSM system is represented by a shadow with the
workkind on the ticketing resource (e.g. with theticketintent). -
The manual connector is configured to use the ticketing resource. When a provisioning operation is executed on the manual resource, the manual connector creates a case and, at the same time, creates the ticket on the ITSM system as a projection of that case.
-
The state of the ticket (and its outcome) is read back from the ITSM system by inbound mappings on the ticketing resource. When the ticket is closed in the ITSM system, midPoint detects that, closes the case and finalizes the provisioning operation.
How It Works
-
A provisioning operation is executed on the manual resource, e.g. an account is to be created as a result of a role assignment.
-
The manual connector creates a case for the operation and links a new ticket shadow (kind
work) to the case. The ticket is created on the ITSM system through the ticketing resource, using its outbound mappings. -
The system administrator works with the ticket in the ITSM system. When the operation is done, the ticket is closed there and its state changes.
-
The shadow refresh task imports the ticket state from the ITSM system. The inbound mappings on the ticketing resource update the state (and outcome) of the case.
-
midPoint notices that the case is closed and finalizes the provisioning operation, exactly like in the classic manual-connector scenario.
From the point of view of the system administrator the workflow is the same as with the classic ITSM plugin: they see and handle the tickets in the ITSM system. The difference is that no custom plugin is needed - the integration is expressed by ordinary midPoint schema handling and mappings on the ticketing resource.
Ticketing Resource
The ticketing resource is a regular midPoint resource pointing to the ITSM system.
The important parts of its definition are the object type for the tickets (kind work, intent ticket) and the mappings:
-
The outbound mappings define how the ticket on the ITSM system is created from the case. E.g. the ticket title can be set from the case name and the description from the operation details.
-
The inbound mappings read back the ticket state and outcome into the case. This is how midPoint learns that the ticket was closed (and with what outcome).
-
The delineation of the object type associates the ITSM object class with the
(work, ticket)kind/intent tuple.
A minimal example of a ticketing resource:
The attribute references (e.g. ri:ticketName, ri:title, ri:state) must match the attributes of the ticket object class defined by the ITSM connector.
The example above is intentionally minimal; in a real deployment the mappings will need to be adjusted to the concrete ITSM system.
Manual Connector Configuration
To enable the ITSM ticketing on a manual (or semi-manual) resource, the built-in manual connector is configured to use the ticketing resource.
The following configuration items are available in the connectorConfiguration of the resource:
| Item | Default | Description |
|---|---|---|
|
not set |
OID of the ticketing resource used to manage the tickets on the ITSM system. If not set, the cases are managed internally by midPoint (the classic behavior). |
|
|
Kind of the ticket object type on the ticketing resource.
Use |
|
|
Intent of the ticket object type on the ticketing resource. |
Example:
<connectorConfiguration
xmlns:conf="http://midpoint.evolveum.com/xml/ns/public/connector/builtin-1/bundle/com.evolveum.midpoint.provisioning.ucf.impl.builtin/ManualConnector">
<!-- OID of the ticketing resource (see above) -->
<conf:ticketingResourceOid>6a1a5f1e-9c7d-4b2a-8e5f-0d3c4b5a6978</conf:ticketingResourceOid>
<!-- The ticket object type on the ticketing resource: (kind, intent) -->
<conf:ticketingObjectKind>work</conf:ticketingObjectKind>
<conf:ticketingObjectIntent>ticket</conf:ticketingObjectIntent>
</connectorConfiguration>
If the object type on the ticketing resource is (work, ticket), the ticketingObjectKind must be set to work, because its default value is generic.
|
When ticketingResourceOid is set, the manual connector creates every provisioning case together with a ticket projection on the ITSM system (instead of a purely internal case).
The case is the projection holder of the ticket, and the status of the operation is tracked by reading the ticket state from the ITSM system (via the shadow refresh task and the inbound mappings).
See Also
Compliance
This feature is related to the following compliance frameworks: