Introduction

Updating only a few requests should be done manually in Octopus, because updating with an import always has a certain level of risk.

But if a batch import to update incidents/SRs is required, this article explains how to update request that already exists in Octopus with an import. 

If the Incidents/SRs have not yet been imported, follow the instructions from the DataImporter - Import Incidents / SR article as this import is not the same.  

                                                      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.  

References

• DataImporter - Import Incidents / SR
• Import Request Activities

• Import Request Attached Files

• XML Configuration File
   
• Back to main page for DataImporter
• Back to the Import Source Specification list

​

What you need to know: 

The reference template files (.xlsx and .xml) to prepare imports are included in the Update Incidents-SR_EN.zip file.


This type of import is useful either to add missing information in batch or to modify information already available in requests. Most fields can be modified as long as they follow the rules of the request logic. For example, if we add a resolution date, several other fields need to be present.
 

Required Fields

• IncidentNumber
  • Must contain the number to identify the request.
  • The number may be the one from Octopus or from the source system that was prefixed to the incident subject
• 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 a 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 the record will be rejected.
• Issue - Text (500)
  • Represents the request subject.
• Status
  • Must be a valid request status

  • Accepted values are: Assigned, Pending, Resolved, Closed. 

  • The Resolved, Closed values require additional information like the date, effort, note. 

  • The Pending value requires the reason. 

• User
  • Must correspond to the Windows Username of an active user
• Requester
  • Must correspond to the Windows Username of an active user.

Optional Fields

• 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 with an assignee, the assignee must be part of the specified group.
• 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 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 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 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.
• ResolutionDate - Date and Time

  • Represents the resolution date in the following format YYYY-MM-DD HH:MM:SS.

  • The resolution date must be greater than 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 for 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 with the incident or the SR. Only one CI is allowed, even thought it is a 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 with 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 a 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="UpdateIncidentsSR">
<ConnectionString>Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\Import\Update Incidents-SR_EN.xlsx;Extended Properties="Excel 12.0 Xml;HDR=YES";</ConnectionString>
<ViewName>[UpdateRequest$]</ViewName> 
<Content>Incident</Content>

<!-- Additional tags -->   
<IncidentIdentificationMethod>ByImportedIncidentID</IncidentIdentificationMethod>
<UpdateOnly>True</UpdateOnly>
<ReplaceCI>True</ReplaceCI>
   </Source> 
</Sources>

Refer to the XML Configuration File article that explains how to program references to the data sources.

Additional Tags to Update Incidents and SRs

To import request updates, the XML files used can contain additional tags. These tags are not mandatory and if they are not specified, the default value will be used. 

Request Identification Method

Permitted values for the IncidentIdentificationMethod tag:

• ByIncidentID : Octopus Incident/SR number.
• ByImportedIncidentID (Default value) : Numéro de requête de la source importée

To use this tag, add the following line to the XML file:

<IncidentIdentificationMethod>VALUE</IncidentIdentificationMethod>

Operator for the update of incidents-SR

Permitted values for the UpdateOnly tag:

• True : To enable update.

• False (Default value): To disable update, the request would then be created in the system. 

To use this tag, add the following line to the XML file:

<UpdateOnly>VALUE</UpdateOnly>

Operator for the CI update

Permitted values for the ReplaceCI tag:

• True : To change de CI. 
• False (Default value) : To ignore changes to the CI.

To use this tag, add the following line to the XML file:

<ReplaceCI>VALUE</ReplaceCI>