Atrium Integrator Connections - workaround to stop the pain!

If you are using Atrium Integrator in your ITSM System I'm sure you already had issues with connections.

Maybe you also made the mistake and you created more than one connection, for each of your environments [dev,qa,prod] and ended up in changing all the connections for each step, while staging them to another environment 

At on premise system it already helps, if you are using one connection with the same name in all stages, and your Spoon UI is configured to not overwriting connection while importing  transformations. (which need to be set in every single Spoon UI)

 But dealing with AI connections in helix environment become much more complicated than I've ever expected.

We can develop and debug the AI jobs in our system using a client gateway to the helix server, but you need to use different connections for development/debug and serverside execution. even if you are working on the same stage!

Means if you have a transformation, which for example 5 AR Input/AR Output,CMDB Output or AR Upsert/ Table Input steps, and you need to do some debugging, to run the same job in spoon you need to change ALL connections, do your debugging/change stuff and again change all connections back to run it on serverside

It's not hard to see that this will cause big problems, because maybe you will forget of one or to steps.

 

How to get this solved?

 I've created a transformation which set all your connections, depending on the system you run the transformations, by using variables.

 

Custom Transformation

Custom Transformation

This means you need to setup your connections once for using variables. 

Like this for example:

AR Connection with variables

AR Connection with variables

 

Afterwards you need to configure how to set this variables for each in the transformations "set constants" step.

Configure connection values

Configure connection values

You need to set all your variables for each different connection. (AR, DBs)

Finally add your development hostnames into the javascript step:

add you clients to the javascript array and set your stage

add you clients to the javascript array and set your stage

 

IMPORTANT:

This transformation need to be the first transformation in each job to set the corret connection parameters for serverside executions.  In your local dev system after opening spoon you should run this transformation to set your connections.

 

 

You can run it locally, on your client gateway, or on your server, on DEV, QA, Prod stage it doesn't matter - no more need to change connection. If you set up once.

 

Maybe you also had an idea to get this solved for your environment? how are you dealing with this?

Feel free to create a pull request if you also have a good idea.

Download Transformation

How to make your Atrium Integrator Jobs smarter

smile blog@linkedin.png

In the last couple of years we’ve created tons of Atrium Integrator Jobs to import or modify data.

If you want to import or modify data to BMC Remedy, you need to do some checks if data is already there or something like that.

At the moment you can use

  • “Merge Joins”,

  • “Stream lookup” or

  • “DB Lookup”

to handle this.


Using a “Merge Join” to lookup data

Using a “Merge Join” to lookup data

Why shouldn’t we design transformation this way?

While creating transformations with the Merge Join or Stream lookup, you have to receive ALL data from your lookup form, and not just the part you need.

We know this is very inefficient because it is very slow, it takes a lot of memory, and it takes time to create all those steps.

Also the DB Lookup Step is no good solution, you can not lookup multiple rows, and it can not handle the remedy datatypes (dates, binaries, selections, … ).


Our solution for this problem

To make this easier for everyone, we’ve developed our own step for the Atrium Integrator, which can be used to simply lookup your needed data with just one simple step. This small step completely matches our product philosophy “smile” (smart integrations, less effort).

Same transformation using AR Lookup Step

Same transformation using AR Lookup Step

AR Lookup Step Features

  • decide whether you want to receive all matching rows or only the first

  • get rid of all steps for sorting, searching and filtering

  • handles datatypes: characters, dates, numbers, binaries, currencies, selections

  • and best of all: it is free to use!

Installation

To install the plugin you need to place the jar file on your client, where your spoon is installed local and on your server.

The place for the plugin is the same on both systems:

../data-integration/plugins/steps/ARLookUp


Usage

AR Lookup Step

AR Lookup Step

This step is similar to to the CMDB Lookup and DB Lookup Step, which already exists on your system.

  • Select the AR connection and form name at the top.

  • Choose whether you want to receive the first match (single row) or all matching rows (multi row).

  • In the first table select both key fields(stream field and form field)

  • In the second table select the fields you want to receive from your lookup form.

Datatype handling

  • Date

    • to receive the data as a timestamp, set the lookup field to “Timestamp”

    • to receive the data as a date, set the lookup field to “Date”

  • Selection

    • to receive the numeric value from this selection, set the lookup field to “Integer”

    • to receive the string value from this selection, set the lookup field to “String”

  • Binaries

    • to receive the attachment name, set the field to “String”

    • to receive the attachment binary, set the field to “Binary”

  • Currency

    • To receive the numeric value, set the field to “BigNumber”

    • To receive the currency value, set the field to “String”

    • To receive the conversion date, set the field to “Date”




Advanced license monitoring now available

We always wanted to help our customers to optimize their license usage and costs. License monitoring was therefor in our monitoring solution SMILEcontrol from the beginning. We could measure total and active floating and fixed licenses. But this was not enough. If you don’t have ITSM Suite licenses for all your users you need to know exactly in which application your licenses are consumed.

With our latest version we automatically give you all the details for every license monitor you create.

E.g. you create a monitor for floating licenses will report the total number of consumed licenses and also a separate metric for each application type. (Problem Management, Asset Management, Change Management, Incident Management, …).

You always wanted to know how many Problem Management Floating licenses you consumed 3 month ago at lunchtime? Now you can :-)

Background: What Are REST APIs? Why Do We Use It?

rest-apis.jpg

The Problem

Often, a remote procedure call (RPC) was used to design APIs, ensuring that, it seemed and felt as if the code was executed locally. In this way, APIs worked like functions. On the flipside, their transition to the Web became complex. The connection-less nature of HTTP compelled and forced developers to formulate an appropriate strategy.

Some technology stacks proposed a solution in which an RPC-like stack attempted to conceal the contents. While this trick did increase the speed for transferring applications to the Web, it posed another issue. Developers began engaging in inefficient code practices, resulting in low-quality code. Around this time, the idea of REST was floated via a paper.

How did REST solve the Problem?

Instead of relying on complex protocols such as SOAP, RPC, COM+, and CORBA, REST adopted a far simpler route; it used HTTP calls to communicate on an inter-machine level. REST made these calls message-based, where the HTTP protocol was needed to unlock the contents of these messages. Hence, REST is a simple, uncluttered architectural style that uses the request/response mechanism on the top of the HTTP protocol.

Anatomy of a Request

Requests consist of a body and a message. It tells the server to execute a task. A response is similar, except for the addition of another field: status code. A request in REST consists of the following four key components.

1.    The Endpoint

Also known as the route, the endpoint is the requested URL. The format of an endpoint is as follows:

root-endpoint/?

The API’s starting point that is being requested is called the root-endpoint. For example, Twitter’s root-endpoint is https://api.twitter.com. The path searches for the requested resource.

2.    Method

The method entails a request type that is sent to the server by the client. There are five request types - each of them is similar to the CRUD functionality.

·       GET – It is used to fetch a resource from a server. It is similar to the READ operation.

·       POST – It produces a new resource on a server. It is similar to the CREATE operation.

·       PUT and PATCH – They update resources on a server. They are similar to the UPDATE operation.

·       DELETE – Removes a resource from a server. It is similar to the DELETE operation.

3.   Headers

Headers are a communication medium through which both server and client exchange information. Headers are useful for a variety of applications such as representing the information in the body content or being used for authentication. HTTP headers follow a property-value format wherein a colon separates them. In the following example, a header informs a server that it contains JSON content.

"Content-Type: application/json"

4.    The Data

Also known as the message or body, data stores information that the client sends to the server. Except for the GET request, all other requests can send data. For example, if you use the command line utility cURL, you can send data with the following format where p1 and v1 represent the first property and first value respectively.

curl -X POST <URL> --data p1=v1

Why REST is used?

·       REST offers scalability. Since there is separation of concerns between the server and client; developers can easily scale up different modules of the application. They can perform server migrations and modify the data – the only prerequisite is that each request sends data correctly. Because of this separation, developers can easily create both their front-end and back-end on different technologies.

·       Since the client and server are separated, REST ensures that the UI is uncoupled from the data storage and server. In development, this can be quite handy. For instance, it enhances the interface’s portability with other platforms. Similarly, it also facilitates a project’s scalability.

·       The detachment between server and client makes REST independent. You can use it with any language or platform. Thus, REST can adapt to any platform or syntax. You can use it with Node.js, Python, Java, PHP, C#, and other servers. However, you cannot change the language of the responses which is usually XML or JSON.  

What makes REST so popular?

REST succeeds because it does not attempt to bind your API to the client-side technology. REST API can be accessible from various client-side technologies like an IoT device, an iOS/Android app, or a React/Angular front-end Web project. This is why it is widely used by companies without concerns over dependence on a specific client-side technology stack.

Additionally, bear in mind, that REST API ensures that the server is stateless and supports caching. Caching is necessary because if several requests are requested for the same resource, caching the request’s result means that the server’s scalability must increase.

On the other hand, statelessness ensures that any call that is made to the API is not tied with a specific server. In this way, developers can easily construct a scalable server infrastructure. The stateless server nature ensures that all the server calls are required to add complete data for executing requests.

manyos technology

If you need help regarding REST APIs for BMC Remedy, you can contact manyos. The company maintains strong reputation with regards to their knowledge and their development efforts over REST APIs, particularly how they integrated ticketing systems with their state-of-the-art APIs. You can look into their ITSM API which is used to link enterprise-level software BMC Remedy, SmartIT, and MyIT. Just recently, they added another feather to their cap with the release of a new product: SMILEconnect. SMILEconnect ensures that users do not have to engage in complex and time consuming customizations and can easily generate their integrations and interfaces.

ITSM AMQP-Bridge available for free

itsm-bridge.jpg

Ever wanted to connect BMC Remedy with Message Broker Systems like RabbitMQ? Now you can.

In the last 15 years, we have designed and built many integrations between BMC Remedy and various partner systems. While the partner systems varied the requirements for the integrations had a lot in common:

  • failsafe connections - even if one partner system is not available it should not break

  • scalability - nearly all needed to support high availability, high throughput or both

To fulfil these requirements we usually created some kind of interface queue where outgoing events were stored until the partner system polled them. While this had many advantages it came with a few major drawbacks:

  • delay in communication - the queue is only polled every so often

  • not very scalable - a queue form requires exclusive access

  • technology dependency - the partner system needs to be able to talk to the queue from

When we designed our new generic interface framework for BMC ITSM it was clear for us that we needed something better. We still wanted to loosely couple the systems but we wanted instant communication. We also wanted our framework to scale well for high availability and high throughput.

Common design patterns to solve these problems are message queues. Their history reaches back to the early mainframe days but even today their advantages are still valid. Many modern microservices use message queues for asynchronous communication and remote process execution. We were sure that message queues were the way to go for us. There was only one problem: BMC Remedy can’t talk to them.

Our solution

We first wanted to create a vendor form plugin. This would allow us to create messages on a queue like normal records in forms. But it would also require a fair amount of configuration on the customer side and we need to rebuild the plugin with every BMC Remedy release, service pack and hotfix. That wasn’t an option. We needed something else.

BMC Remedy can talk to outgoing web services out of the box. So we created a gateway/bridge that provides a soap endpoint. Each request to the endpoint will publish a message on the broker.

ITMS -&gt; AMQP Bridge architecture

ITMS -> AMQP Bridge architecture

We can address this bridge from every Set Fields action in filter workflow. It accepts an exchange name, a routing key and a message as options.

Example usage of the bridge in a set fields action

Example usage of the bridge in a set fields action

The bridge will return success if the message was published on the exchange or error if anything went wrong. An additional message is provided for errors.

With this bridge, we achieved instant communication for our generic api framework for BMC Remedy ITSM and we also made sure it is ready for high availability and high throughput.

We believe the AMQP Bridge can help you as well to build better integrations. We, therefore, decided to make it available as open source. Feel free to use it in your projects. Any contribution is welcome. Happy coding!

Get the amqp Bridge
Open the documentation