Introduction

This article explains how to import requests from another system to Octopus. This type of import can be useful for maintaining a certain history.

                                                      WARNING

This type of import involves risk, 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 problems with the import and to obtain assistance and advice as needed.  

Update 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

• ImportRequest Activities
• ImportRequest Attached Files
• UpdateIncidents / SR
• XML Configuration File
   
• Back to main page for DataImporter

• Backto the Import Source Specification list

What you need to know:

The reference template files (.xlsx et .xml) to prepare imports are included in the Incidents-SR_EN.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.

  • Do not fill for an incident or record will be rejected.

• 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, Closed and Pending status will be imported as is. The pending status will required the pending reason. 
  • If the Assignee field is empty, the New, Assigned, In process, Suspended and Cancelled values will be imported as New. 
  • If the Assignee field is filled, the New, Assigned, In process, Suspended and Cancelled values 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.
  • If 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, Resolved or Closed.
• Impact - Text (50)
  • Must correspond to a configured impact level in Octopus.
  • 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 a configured urgency level in Octopus.
  • 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 a configured priority level in Octopus.
  • 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 or Closed 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).
  • The activity effort must be between 00:01 and 99:59
  • For example, for one and a half hour, write 01:30 in the column.
  • A day value is converted into hours. For example, 1 = 24 hours, so 24:00.
  • When the minutes exceed 59, they are converted into hours. For example, 0:75 = 1:15.
  • If there are seconds added, they are ignored. For example, 1:10:25 = 1:10.
  • 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 or the SR.
  • 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.

  • Example : Main site|Sub-site 1|Sub-site 2. 

  • 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
  • Service associated to the incident and must already exist in Octopus.
  • Must not be present for an SR otherwise the request will be rejected.
• ImportedCost

  • Maintenance cost associated to the CI of an incident. 

  • If the CI maintenance cost must count for an SR, the Impacts CI cost calculation field of the SR type must be checked. 

  • This cost will not be visible in the request, but will affect the CI cost  the next time the costs are recomputed. 

Configuration File (XML)

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

<?xml version="1.0" encoding="utf-8" ?>

<Sources>
      <Source Name="ImportIncidentSR">
<ConnectionString>Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\Import\Incidents-SR_EN.xlsx;Extended Properties="Excel 12.0 Xml;HDR=YES";</ConnectionString>

      <ViewName>[ImportRequest$]</ViewName>
      <Content>Incident</Content>
      </Source>
</Sources>

Refer to the XMLConfiguration File article that explains how to program references to the data 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 generic user and associate all your request to this user that can be deactivated after.