DataImporter - Import Requests (Incidents / SR)

Table of contents

Overview

This article explains how to import requests from another system into Octopus. This type of import is useful to keep the history of the requests. 

NOTE: 

This type of import involves risks, especially if Octopus is already in production in your environment.

It should be done by a person seasoned in the knowledge of DataImporter.

We also recommend that you contact us before importing to ask for a temporary test database to minimize the risk of import problems and to obtain assistance and advice as needed. 

It is not possible to update the requests

Note that this type of import can be done only once to create the requests. Repeating the import from the same source will not update the requests. If the import is done with the request numbers, at the second import, the system would return an error that the record already exists. And if you import without the request number, the second import will create the request again, and will give you duplicate requests. 

References

 

What you need to know:

The reference template files (.xlsx et .xml) to prepare imports are included in the Requests.zip file.

Required Fields

  • Type - (Incident or SR)
    • Determines if it is an incident or a service request (SR). It is possible to import incidents and SR from the same file
  • SRType
    • When importing an SR, this field becomes mandatory
    • The name of the SR type, must already exist in Octopus and it can be configured in the Tools > Reference data management... > Service request > Types menu
  • Issue - Text (500)
    • Represents the request subject
  • Status
    • Must be a valid request status
    • Accepted values are: New, In process, Assigned, Pending, Suspended, Resolved, Closed or Cancelled
    • Resolved, Close and Pending status will be imported as is
    • New, Assigned, In process, Suspended and Cancelled will be imported as Assigned
  • User
    • Must correspond to the Windows Username of an active user
  • Requester
    • Must correspond to the Windows Username of an active user.

Optional Fields

  • IncidentNumber
    • Must contain the number of the request from the import source
    • The number will prefix the incident subject
  • DetailedDescription - Text (5000)
    • Request's detailed description
    • This field is required if it is mandatory in the Octopus options
  • Group - Text (50)
    • Represents the group assigned to the request and it must be the name of a valid group
    • When a request is associated to an assignee, the assignee must be part of the specified group
    • f no group is specified, the request will be assigned to the "Service Desk" by default
  • Assignee
    • Octopus user who will be assigned to the request
    • Must correspond to the Windows Username of an active user
    • This field is required if the request status is "Assigned", "In process" or "Resolved"
  • Impact - Text (50)
    • Must correspond to the a configured impact level
    • Example: "1 - High", "2 - Medium", "3 - Low"
    • The impact can be configured from the Tools > Reference data management... > Incident > Impacts menu
    • This field is required if it is mandatory in the Octopus options
  • Urgency - Text (50)
    • Must correspond to the a configured urgency level
    • Example: "1 - Urgent", "2 – Normal"
    • The urgency can be configured from the Tools > Reference data management... > Incident > Urgencies menu
    • This field is required if it is mandatory in the Octopus options
  • Priority - Text (100)
    • Must correspond to the a configured priority level
    • Example: "1 - Critical", "2 - High", "3 - Normal", "4 - Low"
    • The priority can be configured from the Tools > Reference data management... > Incident > Priorities menu
    • This field is required if it is mandatory in the Octopus options
  • Category
    • Must correspond to the an existing category in Octopus
    • Must not be present for an SR otherwise the request will be rejected
    • When a sub-category is specified, the category becomes mandatory
    • This field is required if it is mandatory in the Octopus options and if the status of the incident is "Resolved"
  • Subcategory
    • Must correspond to the an existing sub-category in Octopus
    • Must not be present for an SR otherwise the request will be rejected
    • This field is required if it is mandatory in the Octopus options and if the status of the incident is "Resolved"
  • OpenDate - Date and Time
    • Represents the open date in the following format YYYY-MM-DD HH:MM:SS
    • If unspecified, the system will use the current date during import
    • This field is required when the status of the request is "Resolved" and it must be smaller then the resolution date
  • ResolutionDate - Date and Time
    • Represents the resolution date in the following format YYYY-MM-DD HH:MM:SS
    • The resolution date must be greater then the opening date
    • This field is required when the status of the request is "Resolved" or "Closed"
  • ResolutionEffort
    • Format HH:MM:SS (in Excel the column must be in text format). For example, for one and a half hour, write 01:30 in the column
    • This field is required if it is mandatory in the Octopus options
  • ClosureDate - Date and Time
    • Represents the closure date in the following format YYYY-MM-DD HH:MM:SS
    • The date must be equal to or greater than the resolution date
    • This field is required when the status of the request is "Closed"
  • OnHoldReason - Text (100)
    • Indicated the "Pending" reason of the incident
    • The reason must be one that is already configured in Octopus
    • The pending reason is configurable from the Tools > Reference data management... > Incident > Reasons for pending menu
  • ResolutionDescription - Text (5000)
    • Represents the description of the resolution activity
    • This field is required when the status of the request is "Resolved" or "Closed" and it is mandatory in the Octopus options
  • ResolutionActivity - Text (100)
    • Represents the TYPE of activity describing the resolution
    • The activity types are configurable from the Tools > Reference data management... > General > Activity types menu
    • This field is required when the status of the request is "Resolved" or "Closed" and it is mandatory in the Octopus options
  • ClosureNote - Text (5000)
    • Represent the closure note associated to a "Closed" request
    • The closure note is not mandatory
  • CI
    • CI associated to the incident
    • The identification method of the CI is the CI name
    • This field is required if it is mandatory in the Octopus options
  • Site - Text (200)
    • Site associated to the request
    • The system will create the site (or sub-site) during import if it does not already exist
    • To specify sub-sites, use the pipe sign "|" to separate the sub-sites in the hierarchy
    • The sites are configurable from the Tools > Reference data management... > General > Sites menu
    • This field is required if it is mandatory in the Octopus options
  • ITService
    • IT service associated to the incident and must already exist in Octopus
    • The IT service is only to be imported for incidents and must not be present when importing service requests

Configuration File (XML)

The declaration of the source is done by indicating the INCIDENT value in the <Content> tag.

NOTE: The XML file used as this example is for an import done from Excel 2007 or 2010. To explain the tags used in all types and to find out more about the types of files, please refer to the XML Configuration File article
<?xml version="1.0" encoding="utf-8" ?>

<Sources>

   <Source Name="ImportationRequete">

      <ConnectionString>Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\Import\IT Requests.xlsx;Extended Properties="Excel 12.0 Xml;HDR=YES";</ConnectionString>

      <ViewName>[ImportRequest$]</ViewName>

      <Content>Incident</Content>

   </Source>

</Sources>

Tips and Tricks

  • Mandatory Fields
    • If the import is being done at the start of an integration, hence if you are not in production with Octopus yet, we strongly suggest that all mandatory fields be deactivated. Later, when you active the mandatory fields, you will only have to manage the opened requests.
    • The configuration of mandatory fields is done from the Tools > Options... > Visible and required fields menu
  • User, requester and Octopus user
    • While importing request it is not possible to associate a request to an inactive user or inactive Octopus user. If you have such cases in your request history, use a fictitious user and associate all your request to this user that can be deactivated after.
X
Help us improve our articles








Help us improve our articles