Automator mail attachments

automator-logo

Business case:

If you integrate a small service provider via an email interface it is important to send attachments too. Thinking the other way around, attachments from the Service provider have to appear in the ITRP note of the request.

automator_attachment

Email out attachments:

Adding a couple of lines of code to your existing mail out package makes it possible to send inline images and non-inline attachments.

// attach all inline images
$mailAttachments = [];
//Exec Engine v1: foreach($note in $request.notes) {
for($note of $request.notes) {
for($noteAtt of $note.attachments) {
        if ($noteAtt.inline) {
            $mailAttachments.push({
                filename: $noteAtt.name,
                path: $noteAtt.uri,
                cid: "link-inline" // looks better on apple mail
                //cid: uuid()      // instantly loaded on outlook
            });
        }
    }
}

//and non-inline attachment of last note
$lastNote = $request.notes.last();
for($noteAtt of $lastNote.attachments) {
    if ($noteAtt.inline == false) {
        $mailAttachments.push({
            filename: $noteAtt.name,
            path: $noteAtt.uri
        });
    }
}
$mailData.attachments = $mailAttachments;

Email in – add attachments to the note:

Adding attachments from an incoming email to the note is even simpler. In that case you just need to add one line to the update statement.

update("requests",$request.id,{
    note:$mail.body,
    attachments:$mail.attachments
  });

 

Note:

These couple of lines of code help significantly to reduce coordination problems because of missing information.

Yours, k.konwalin@techwork.at

Summary pdf for the accounting department

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:

In some organisations the accounting department needs a pdf file after an order has been executed. With ITRP this is easily achievable via an approval task because such tasks send a summary pdf file to the approvers.

However, there is no need for the accounting department to approve or reject something because the goal is simply to get the pdf file in an email – in that sense it is of course a workaround. To achieve this, the automator automatically completes the “Purchase – Order summary to accounting” task automatically, therefore no human interaction is required. In my example this is done via the user “Howard Tanner”. In a live environment we use an “Automation” user instead of “Howard Tanner”. Further we pretend that and “Chet Baker” works in accounting.

PO_summary2.png

The pdf file “Chet Baker” (accounting) gets

change_summary_pdf

The automator package to complete the task automatically

The package is executed whenever the task “Purchase – Order summary to accounting” changes from “Registered” to “Assigned”.

/***** Begin send pdf to the accounting department *****/

mergeAudit(task);

if (task.template.id == $Summary_pdf_to_Accounting &&
task.audit_is_changed_status && task.audit_new_status== 'assigned') {
update('tasks', task.id,{
note: '``` Completed by automation - Summary pdf sent to Chet Baker ```',
status: 'approved'
});
}

/***** END send pdf to the accounting department *****/

Note

This automation package takes 5 minutes to write. Without the automator nobody would probably automate this simple task. Some would probably choose to complete it manually or forward an approval email from someone else.

k.konwalin@techwork.at

 

Mail interface to small external service providers 2

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:

Please find the full description of the business case in blog post “Mail interface to small external provider 1“.

In this post we provide an automator package to read the mail the service provider sends back and stores the information in the note field. What needs to be done?

Minimal requirements:

  • We need to look for the ITRP Request Number in the subject (Request # …)
  • We need to fetch the request in ITRP
  • If the request is there we need to look for custom data to apply the internal Service Instance, Team and Member, so that the request is back in the correct inbox.

 


log('******* Mail back from the external provider ********')

$subjectMatch = mail.subject~'Request #(\\d+)';
$itrpRequestNr = $subjectMatch[1];

if ($itrpRequestNr) {
  $request = fetch('requests', $itrpRequestNr);

  if ($request) {
    $teamID = $request.custom_data.wdc_team_id ? $request.custom_data.wdc_team_id : $WDC_Default_Team;
    $memberId = $request.custom_data.wdc_member_id ? $request.custom_data.wdc_member_id : '';
		$serviceInstanceID = $request.custom_data.wdc_si_id ? $request.custom_data.wdc_si_id : '';
    
    $bodyMatch = mail.text~'([^]*)Your original request description:';
    $providerText = $bodyMatch ? $bodyMatch[1] : mail.text;

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

    update('requests', $itrpRequestNr, {
      team_id: $teamID,
      member_id: $memberId,
      service_instance_id: $serviceInstanceID,
      status: 'assigned',
      note: '```' + $tzDate + ' -- Email back from external provider```:\n\n' + $providerText;
    });
  }
}

log('******* Mail back from the external provider END ********')

 

What it does in human language:

Line 3 and 4: Looks into the subject line of the Email for “Request #” and stores all numbers (digits) after the # in variable “$itrpRequestNr”.

Line 6 and 7: If there is a number stored in $itrpRequestNr then it fetches the request into variable “$request”.

Line 9 to 12: If there is a request stored in “$request” we look in the custom data field for the team id, member id and service instance id and store them into variables.

Line 14 and 15: In the mail body everything above “Your original request description:” is stored in variable “$providerText”. The assumption is that the provider sends the original description at the end of the email. If the line can not be found the whole body content is stored in variable “$providerText”.

Line 17 to 22: Like I described in the last post is to get a valid timestamp for the note. Therefore it will be easy to read when the email came in from the external provider.

Line 24 to 30: It just updates the request with all the data mentioned.

Wrap up

This post and the last post explain how to build a cheap email based interface between ITRP and another Service Management tool. The whole interface takes 2 hours to set up in a live environment.

k.konwalin@techwork.at

 

 

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