Test Driven package Development

The purpose

TDD (Test Driven Development) simplifies the process to generate well designed package code. It further eliminates the risk of package failures due to implementation changes nearly completely. The notion of Fail (red), Pass (green), Refactor increases code quality on a continuous basis.


The process

At first a test always fails, this means that your code does not implement the feature the test is about. Next you do just the minimum in order to pass the test. So the output of the test changes from red to green. Then you refactor the implementation package and the test should remain green.


Green is a good thing!

The added value

It often boils down to the following scenario. You develop a package, everything works fine for a long time. Then you like to change something. Changing implementation code is always risky. The TDD functionality reduces that risk to a minimum, meaning that you can act faster to implement changes and sleep better!



Product sheet

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.


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.

[code language=”javascript”]

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


//Helper functions


Happy training!




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.


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

[code language=”javascript”]
//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;


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.


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





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?


  • 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.


Product sheet




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.


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!



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”.


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.


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.



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.


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


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.






Lift the CMDB to a completely new level


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.


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


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.


ITRP projects and Kanban


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.



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.


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.







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.


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


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