Tired of closing records manually?

The situation

You are most likely familiar with the ITRP sandbox environment (…/itrp.qa). You configure and test new things there. At some point you want to train people with your specific configuration but over time the sandbox became messed up.

Many open test records like Requests, Changes, Tasks are open and need to be closed before a training starts to make it easier for the audience. The challenge you face is to close probably 100s of records manually.

Manually in the automator age?!? Not so much

You simply need to register a Change that triggers the automator package and you are done. After a couple of minutes your sandbox environment looks clean again and your audience does not get lost in test records.

clear-sandbox.png

The automator package – main function

The package is straight forward. It checks whether the above change is selected and started. Then it closes all changes and afterward all requests.

Hint: If a change is closed all linked tasks are closed automatically. That way there is no need to loop over open tasks.


(function() {
 if (!firePackage(PKG_SETTINGS.implementationTaskTemplateId,task.template.id, task.status)) return;
 log('automationTaskTemplateId: ', PKG_SETTINGS.implementationTaskTemplateId);
 log('task Template ID ', task.template.id);

 closeChanges();
 closeRequests();

}());
//Helper functions
...
}

Happy training!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

automator-logo

Advertisements

Reduce clicking to obtain information

Use case

Imagine you sit in front of the ITRP inbox. An implementation task has been assigned to you. The specific relevant information rests in the Request’s custom data field because a request template with an UI extension provided the structured input form.

Therefore, you need to click on the Request link of your task, to open the Request in a new tab (cmd + shift + click). The inefficient thing is that you need to work with 2 tabs,  you read specific information in one tab and you need to comment in a second tab.

ui

The automator solves this problem with a couple of lines of code

//This package copies "custom_data" from the request
//to all tasks, so that people do not need to click

const PKG_SETTINGS = {
 automTaskTemplateID: 139
};

(function main(){
 if (task.template.id !== PKG_SETTINGS.automTaskTemplateID) return;
 const chg = task.change;

 if (chg.requests.length === 0) return;
 const req = chg.requests.first();
 const reqCustomData = req.custom_data;

 for (let t of chg.tasks){
   let mergedCustomData = assign({}, reqCustomData, t.custom_data);
   update('tasks', t.id, {
     custom_data: mergedCustomData;
   });
 };
})();

Output

The automator package copies all UI extension data to all tasks if a certain Task Template is used. Therefore it works in a generic way. Independent of what you have in your Request UI extension. It always works!

Furthermore you can select what UI data you want to see in specific tasks. Simply put your field selection into the UI Extension and add the extension to your task template.

output

Now, you instantly know what you need to do, without clicking around. Makes sense, right?

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

automator-logo

 

ITRP_reporting includes audit records

Product sheet

Many customers asked whether the automator is involved in our ITRP_reporting solution or not. No. We use our PowerShell framework to populate the SQL database. Right now, this is the most efficient and effective technology for that purpose.

Audit records

Audit records can not be exported by using the ITRP standard export functionality. Audit data need to be exported via the API. This is the newest capability of our reporting solution.

For what purpose do you need the audit records?

Examples:

  • How often have tickets changed assignments / Service Instances?
    • If your Service Desk follows a “Capture, structure, solve or assign (change the Service Instance in ITRP)” approach, it tells you how well the Service Desk performs in terms of narrow the issue down to the root cause, when they structure the ticket
  • How often has a ticket being touched?
    • Depending on detailed data this could be an indicator of working not efficient or people are simply not trying to solve the ticket in one go.

Easy to generate standard dashboards

Our PowerShell framework normalizes the database automatically, including the audit tables. Based on that easy to use structure it is easy to generate dashboards in PowerBI or another tool of your choice instantly.

ITRP_reporting_backlog

Product sheet

techwork-logo

k.konwalin@techwork.at

 

Stimulate experimentation

Companies increasingly rely on the automator to perform workflow automations. In most of the cases our consultants develop and maintain automation packages. To constantly deliver high quality, all requirements get CATWOE checked before we start with the technical development. Of course the output gets checked against CATWOE too. During technical implementation consultants use 3 different environments – Development – Sandbox and Production.

In addition to that we implemented the possibility to save versions within each environment in order to encourage experimentation. Encouraging experimentation likely increases the quality and readability of the automation package further.

automator-versions

How does it work?

It is very simple:

  1. Create a new version
  2. Experiment
  3. Whenever you want switch to a previously saved version
  4. Happy!

man-in-a-party-dancing-with-people-3

k.konwalin@techwork.at

During the summer 2 – Automator audit report

Following the last blog post, the 2nd major development for the automator during the summer 2017 is the “Automator audit report”.

Purpose

The purpose is to get a document about automator packages describing the nature of your automations. It can be used for internal and external audits or to get a quick overview about what’s happening.

automator-audit-report.png

A side effect is that switching costs get lower again. That means the following: should you ever decide to switch from the automator environment to your own development- and operating- environment your Java Script developer gets a nice overview what needs to be configured. After that your JS developer simply uses the automator package code and develops missing components. Your risk to use the automator is basically zero.

automator-logo

k.konwalin@techwork.at

During the summer – physical button

We are going to develop 2 new automator capabilities in Summer 2017.

  • Physical button
  • Automator audit report (will be a another blog post)

Physical button

Everyone can push a button right? We are connecting the physical button to ITRP.

bttn.png

Well, but what could be a purposeful function?

An Example

One example is printer maintenance. Some companies outsource printer maintenance completely i.e. the vendor is changing, maintaining everything except adding paper. Right now, without the button a toner change request could work like that:

  • User goes to the printer
  • Printer is low on toner
  • User contacts the Service Desk
  • User uses another printer
  • Service Desk looks for the Printer Serial No.
  • Service Desk calls the printer company or writes an email

With the button it will work like that:

  • User goes to the printer
  • Printer is low on toner
  • User pushes the button
  • A Service Request in ITRP will be created automatically and an email including Serial No. etc. goes to the printer company, of course automatically

Result:

Time and nerves saved for Service Desk staff.

Other Examples

There are many other examples for using such a button. The spectrum goes from ordering Pizza, creating a request because the vending machine run out of coffee to automate orders of spare parts.

automator-logo

k.konwalin@techwork.at

 

 

 

Lift the CMDB to a completely new level

automator-logo

The CMDB (Configuration Management Data Base) in ITRP can not only be used for ITIL’s definition of a CMDB but also to provide configuration parameters for automator packages. That way you can specify the specifics of your automations in ITRP.

Business case

Especially service forms add major capabilities to ITRP’s Self Service. Recently I released the Service forms blog post. There the automator provides a simple wizard and saves the customer entries in the request module and provides a couple of other automations like adding the person if the person can not be found in the people module and so on.

service-forms-automate-io.png

Advantages of that approach

There are several advantages for ITRP administrators:

  • Configure the behaviour of Service forms within ITRP
  • No coding necessary
  • Maximize the business value with one automator package

Real world examples

  • Structured surveys
  • ITRP wizard – step by step easy to use Request Fulfilment front end for customers
  • CI based Self Service form

Conclusion

Automator service forms can be configured for different purposes by using the ITRP CMDB. That way business benefits can be maximized in an easy way.

k.konwalin@techwork.at

ITRP projects and Kanban

automator-logo

Project implementation teams and maintenance teams certainly benefit from agile methodologies because it mainly reduces confusion and offers transparency. The benefits of Kanban are:

  • transparency in the context of project progression
  • transparency in the context of pressing problems
  • faster task completion
  • lower resistance during adoption
  • faster non bureaucratic response to changes

Kanban itself is not a full project management method – it is more of an idea of how projects could be managed by the team itself.

IT people appreciate that they can respond to changes quickly, that they can easily iterate and that they select what to do, so it gives them more autonomy.

On the other hand, a flexible system like Kanban can make it difficult to focus and push a project to completion if not careful enough. There is less set in stone, and no process to make sure the project is continuing smoothly – so it easily happens that a project loses direction.

Combine traditional project management with agile

To have more control over projects it might be a good idea to combine traditional project management with agile.

automator_ITRP_Kanban

 

That way the business or business representatives in IT control the input and output factors of the agile development and can make sure to not loosing direction.

IT people can work with their Kanban system and appreciate the flexibility.

Conclusion

Agile alone might not be enough. Traditional alone might not work either, because IT people work not at their best if too much control is enforced. So combining both, might be worth a try.

k.konwalin@techwork.at

 

 

 

JavaScript

automator-logo

During our first automator steps we introduced a “JavaScript – like” language to script automation packages. This was a necessity because of our execution engine back then.

After a year of automator experience we decided to adapt a different by far more powerful execution engine and pure JavaScript in its version V2016.

javascript-automator

What does it mean from a business perspective?

  • Every JavaScript developer can write automation scripts after a short introduction.
  • If you decide to cancel your automator subscription, you can simply take the automation scripts and use them in your own environment. Only small parts have to be added by your JavaScript developer.

What does it mean in technical terms?

JavaScript developers can make use of the following possibilities:

  •  Base language features
    -> Variable declaration with var, let, const
    -> if and else with {} Blocks
    -> let x={}; Blocks to create new data objects
    -> for, for of, break
    -> while, do.. while
    -> switch
    -> regex
    -> template Strings
    -> Block and line comments
    -> functions (named, anonymous, self calling, nested)
  • Base functions like
    -> isFinite, isNaN
    -> parseFloat, parseInt
    -> decodeURI, decodeURIComponent
    -> encodeURI, encodeURIComponent
  • Base objects like
    -> Math, Number, Date
    -> Infinity, NaN, undefined
    -> true, false
  • Standard Operators like
    -> Logical Operators (==, !=, <, >, <=, >=, ===, !==, ||, &&)
    -> Math. Operators (+, -, *, /, %)
    -> Ternary Operator (condition?then:else)
  • Default set of functions:
    -> stringify and parse – for JSON handling
    -> log, logError, logVerbose an logDebug
    -> date and moment – to create a Date and Moment object
    -> newMap and newSet() to create the Map and Set Objects
    -> setProperty and getProperty to access a property by its name
    -> isNull, isArray, checkNull
    -> uuid, atob,btoa, encodeHTML, decodeHTML
    -> formatdate, formatDateTime, formatNumber, …
  • HTTP, REST, GRAPH, MAIL, Proxy functions
    -> http functions that can be used e.g. for SLACK integration
    -> rest functions can be used e.g. for JIRA integration
    -> graph functions can be used for Office 365 & Sharepoint integrations
    -> proxy functions that can execute powershell scripts on premise
    -> In detail:
    -> http_get, http_post, http_put, http_patch, query_stringify
    -> rest_get, rest_post, rest_put, rest_patch
    -> graph_get, graph_post for office 365 access
    -> sendMail
    -> executeOnProxy
  • ITRP functions
    -> fetch, fetchAll, fetchFilter
    -> update, create, deleteItrp for Itrp Accounts
    -> addNote, addApprover, link, mergeAudit
    -> isUserTokenValidInAccount, hasUserTokenRoleInAccount
    -> exportPromise, importPromise, waitForPromise
  • Template Management
    -> templates now support the smart {{variable}} style
    -> templates allow ASP style development (<%=variable%> and <% /* code */ %>)
    -> templates can only access global package variables
    -> text in variables can be used as template now
    -> in detail:
    -> createTemplateTextMail, createTemplateHTMLMail, createTemplateText
    -> textFromTemplate, subjectFromTemplate,
    -> bodyFromTemplate, bodyFromTemplateText
    -> useContentAsTemplate
  • NOT implemented
    -) Use of classes, and therefore no use of the “new” keyword
    -) Asynchronos calls or use of functions – all is handled synchrone
    -) continue is not allowed in loops
    -) All elements that are not listed above

Conclusion

Every JavaScript developer is now able to develop automation packages within the automator framework. Workflow automation is now easier than ever.

k.konwalin@techwork.at

ITRP Workflow transfer Test 2 Production

automator-logo

Business case

Workflows can become complex when considering different stakeholders. Customers usually want to have intuitive Self Service forms. IT teams aim to streamline their activities. Manual and time consuming tasks are low hanging fruits to gain efficiency to free up time for the customer or other more important things.

When it comes to ITRP workflows the transfer from the “itrp.qa” environment to the production environment (“itrp.com”) is manual. Most people know that finding tiny mistakes during a manual transfer can be time consuming and annoying.

tw-Test2Production

What does one ITRP based workflow usually contain?

In a more advanced form it contains the following components:

  • a Request template
  • linked to a Change template
  • linked to task templates
  • Request-, Change- and Task templates linked to UI extensions

How people approach ITRP workflow configuration:

Everything is developed / configured in the Test environment (“qa”). Components like UI extensions are getting tested during development and at the end of the cycle a couple of test cases are entered to ensure that the whole process works.

Everything is tested and works fine.

Now, the “manual” transfer starts…

and a couple of annoying and sometimes time consuming difficulties. Services, Service Instances deviate between test and production. Teams are not defined. SLA’s need to be created, modified, and the list goes on.

How does the automator help?

The automator’s latest feature lets you transfer selected workflows from production to test and from test to production. That way the environments don’t deviate that much over time. In ITRP language the automator transfers selected Request templates, Change templates and dependencies like Task templates, UI extensions etc.

Intelligence of the automator:
Before a workflow can be transferred the automator analyses the source and target environment. Whenever costs are involved (i. e. ITRP users with a role), contracts (i. e. SLA’s), or IT people could be confused (e. g. teams that do not exist in the production environment) the automator simply creates a manual “to do list” before the automated transfer can be performed. As all required dependencies are transferred additional testing in the target environment is not really necessary, it’s just to gain more confidence.

Test2Production.png

Goal reached

ITRP developers/configurators save time and can therefore spend more time with customers or refining other workflows.

List of most wanted ITRP integrations @ https://www.itrp.com/integrations

All the best

k.konwalin@techwork.at