Mail interface to small external provider 1

automator-logo

Prerequisites if you like to try it:

  • You already have an ITPR demo account. If not, you can easily request one with demo data.
  • You already signed up for a techwork automator demo account. If not, goto the registration blog post.

Business case:

Having a small specialized service provider with a homegrown Service Management tool often rises the integration question. Of course, there are various options. The best one is that the small service provider uses it’s own ITRP account and you simply create a trust.

Sometimes, this is not possible for whatever reason. Easiest is to integrate via email. In my demo example I use GigaTera to showcase that scenario – even though GigaTera has it’s own ITRP account, therefore I pretend they don’t have one.

Now, you probably ask the question, why we need to write a couple of lines of automator code for that and not use the standard ITRP email functionality?
Answer: The requests may go back and forth between the external provider and the internal team and I want exactly the same assignments if information comes back from GigaTera.

How does the request go back and forth?

To the external service provider (GigaTera): The internal team (in my example the windows server team because the affected service instance is “Windows for Email”) simply applies the “SAN1 for Widget Houston” service instance, to assign the request to the GigaTera team. This assignment triggers the automator package that sends the email. I apply the service instance and avoid “manual” Team changes because I want all Service Level agreements to be correct. (Subject of this blog post).

Back from the external service provider: On the other hand the external provider most likely sends an email with information back to us. What I want to achieve is that the Service instance “Windows for Email” is automatically applied alongside the “old” team and member. If a team member was assigned I want this team member to work again on the request. In short the request should have the same meta data as before plus information from the external provider. (Subject of the next blog post).

automator_simple_mail_interface

To achieve that I simply write data to the “custom_data” field. I remember the team id, the member id and the service instance id.  No custom data will be erased or overwritten, we just add data from the audit.

  ...
  $custom_data = request.custom_data;
  $custom_data.wdc_team_id = request.audit_old_team.id;
  $custom_data.wdc_member_id = request.audit_old_member.id;
  $custom_data.wdc_si_id = request.audit_old_service_instance.id;

  update('requests', request.id, {
    custom_data: $custom_data
  });
  ...

 

The ITRP record with its custom data:

automator_write_custom_data

The complete script:


log('******* External Provider mail interface - create request ********')

mergeAudit(request);
log(request);

if (request.audit_is_changed_team && request.audit_new_team.id == $GigaTera_Storage_Team) {
  $custom_data = request.custom_data;
  $custom_data.wdc_team_id = request.audit_old_team.id;
  $custom_data.wdc_member_id = request.audit_old_member.id;
  $custom_data.wdc_si_id = request.audit_old_service_instance.id;

  update('requests', request.id, {
    custom_data: $custom_data
  });

  for(let note of request.notes) {
		$lastNote = note.text;
  }

  $mailData.to = 'klaus@techwork.at';
  $mailData.subject = 'Widget Data Center - Request #' + request.id;
  $mailData.body.text = 'Requested by: ' + request.requested_by.name +
  											'\nService Instance: ' + request.service_instance.name +
    										'\nImpact: ' + request.impact +
    										'\n\n\nLast Note: ' + $lastNote
  sendMail($mailData);

  $date = date();
  $m = moment($date);
  $tz = $m.tz("Europe/Vienna");
  $tzDate = $tz.format("DD.MM.YYYY, HH:mm");

  update('requests', request.id, {
    note: '```' + $tzDate + ' -- Request email to GigaTera has been sent ...```'
  });
}

log('******* External Provider mail interface - create request END ********');

Interesting to note:

 

I also write a note to the request with a timestamp to indicate that the email has been sent on a particular date and at a particular time.

The timestamp can be formatted in various ways because the automator integrates the “moment.js” framework. This framework parses, validates, manipulates and displays dates.

k.konwalin@techwork.at

 

 

 

Advertisements

Relink Incidents from a Problem to a Change

automator-logo

Prerequisites if you like to try it:

  • You already have an ITPR demo account. If not, you can easily request one with demo data.
  • You already signed up for a techwork automator demo account. If not, goto the registration blog post.

Business case:

Having Incidents linked to a Problem makes sense for the team investigating the root cause of a Problem because Incidents may provide important information. By the time the Problem is solved all related Incidents should have been completed  – a workaround provided by the problem record should have helped.

Implementing the solution for the problem in the production environment is often done via a Change. Therefore a Change will be linked to the Problem.

An Incident can be linked to a Problem or to a Change. For the Change manager and the Change team it might be of importance to  have the Incidents linked to the Change.

With a short automator script the Incidents are relinked as soon as a Change gets related to the Problem.

mergeAudit(problem);

if (problem.audit_is_changed_change && problem.audit_new_change) {
  foreach(req in problem.requests) {
    update('requests', req.id, {
      problem: null,
      change_id: problem.change.id,
      internal_note: '``` -- Relinked from Problem: '
        + problem.id + ' to Change: ' + problem.change.id + ' --```'
    });
  }
  update('problems', problem.id, {
    note: '``` -- Requests relinked to Change: '
      + problem.change.id + ' --```'
  });
}

What it does:

The script looks if a Change is newly linked to the Problem. If yes each Incident (‘requests’) gets updated with a ‘null’ Problem value. The link to the problem is now cut. The new link created via the change_id relinks the Incident to the Change. To make it easier for the IT staff an internal note is added to each Incident indicating that the Incident has been ‘Relinked’ from the Problem to the Change. The Problem gets a note too.

Any variation is possible. For some organisations it might be of value to relink only open Incidents to the Change, for others all.

The script with comments:

//get Audit data of the Problem that is being updated
mergeAudit(problem);

//New change linked to the problem?
if (problem.audit_is_changed_change && problem.audit_new_change) {
  //run through all Incidents(request) linked to the problem
  for(let req of problem.requests) {
    //update each request. Set the problem link to 'null' and relate
    //each request to the change and add an internal note
    update('requests', req.id, {
      problem: null,
      change_id: problem.change.id,
      internal_note: '``` -- Relinked from Problem: '
        + problem.id + ' to Change: ' + problem.change.id + ' --```'
    });
  }
  //update the problem with a note too
  update('problems', problem.id, {
    note: '``` -- Requests relinked to Change: '
      + problem.change.id + ' --```'
  });
}

Interesting to note:

The Internal_note field is updated of each of the Incidents, therefore the user does not see the note in Self Service.

k.konwalin@techwork.at

 

 

Email in from multiple mailboxes – easier than you think

automator-logo

Prerequisites if you like to try it:

  • You already have an ITPR demo account or a production account. If not, you can easily request one with demo data.
  • You already signed up for a techwork automator demo account. If not, goto the registration blog post.
  • Create a test mail account at for instance gmail.com

Business case:

Each ITRP account has its own email address. It is always the id of your organisation’s ITRP account plus @itrp.com. You can find your id when you open the “Account Overview” section in the settings console. Note: There is no email address for your ITRP demo environment.

Basically each ITRP account is associated with one mailbox. Which is fine, because as you might know you can have multiple ITRP accounts for different purposes and all people, organisations etc. are then defined in the directory account.

However, some companies operate with just one ITRP account and they want to read emails from multiple mailboxes. For instance people are used to write emails to “firewall-requests@organization.com” if they need any changes on the firewall, or “facility.maintenance@organization.com” if light bulbs need to be changed and they still use “SAP-development@organization.com” to log new requirements for SAP.

The automator provides the capability to do that in a smart way.

1st – you can define multiple mail boxes:

inboxes

2nd – attach an email profile to a package:

Because of that capability you don’t need to read the mailTo address. In my case the package automatically reads only from the sap-development inbox.

SAP_dev_profile

 The automator package

The package checks if the person exists in ITRP and creates a RFC for the Service Instance “SAP Basis Europe Development (D45)”.

$mailFrom = mail.from[0];
$mailFromAddr = $mailFrom.address;
$mailFromAddr = 'beatrice.baldwin@widget.com'; 

$filter = 'primary_email=' + $mailFromAddr;
$person = fetchFilter('people', $filter, 'directory')[0];

if ($person) {
  create('requests', {
    subject: mail.subject, note: mail.text,
    category: 'rfc',
    requested_by_id: $person.id,
    service_instance_id: $SAP_Basis_SI
  });
}
else {
  log('reject mail: ',$mailFromAddr);
}

 

The code with comments

$mailFrom = mail.from[0];
$mailFromAddr = $mailFrom.address;
$mailFromAddr = 'beatrice.baldwin@widget.com'; 
//simulate beatrice as sender

$filter = 'primary_email=' + $mailFromAddr;
$person = fetchFilter('people', $filter, 'directory')[0];
//look in the directory account for beatrice in that case
log('$person.id :', $person.id);

//if the person (Beatrice) exists create a RFC and fill all
//required fields in ITRP
if ($person) {
  create('requests', {
    subject: mail.subject, note: mail.text,
    category: 'rfc',
    requested_by_id: $person.id,
    service_instance_id: $SAP_Basis_SI
  });
}
else {
  //if the person (Beatrice) does not exist just write into the log
  log('reject mail: ',$mailFromAddr);
}

 

Interesting to note

One of the latest updates of the automator is the capability that you can write JSON syntax. Instead of writing code like:

$newSAPrequest.subject = mail.subject;
$newSAPrequest.note = mail.text;
$newSAPrequest.category = 'rfc';
$newSAPrequest.requested_by_id = $person.id;
$newSAPrequest.service_instance_id = $SAP_Basis_SI

create('requests',$newSAPrequest);

you have the option to use JSON syntax :

create('requests', {
    subject: mail.subject, note: mail.text,
    category: 'rfc',
    requested_by_id: $person.id,
    service_instance_id: $SAP_Basis_SI
  });

It makes it just a bit easier.

k.konwalin@techwork.at