Getting Started

What does it take to start using ONEiO

There are a few different scenarios, where there will be a need to describe what does it take to start using ONEiO. In most cases, there is a need to implement one or more integrations between different systems. This need might arise also when an architecture design is going on and ONEiO is included as a component of the overall architecture.

I want to subscribe to ONEiO and be in control of my own integrations

This scenario means that ONEiO will be a tool for you to standardise your integrations. This means that you have the ownership of the integration, and ultimately you decide how the integration is configured.

My customer/vendor/partner is using ONEiO and we need to implement an integration. What do I need to know/do?

In this case, you will be a passive part of the ONEiO integration. This limits the things you need to consider when setting up the technical connection. On a top-level you can approach this like this would be any other customer integration where your customer will adapt to all of your requirements.   

Connection setup

To enable integration to ONEiO ecosystem, network-level communication between the tool and ONEiO needs to be available. The required tasks depend on the location of the connected tool.

Cloud-based tool

If your tool resides in the cloud, typically there is no need to open any network-level firewalls.

On-Premise tool

Connection to an on-premise tool is always ultimately up to the organization and its policies. Here's one secure way to implement the connection, by using a reverse proxy.

For possible firewall configuration changes, you can find the needed info at Production & Test IP addresses and ports

Certificates

For secure, encrypted communication, there always needs to be valid server certificates at both the tool and ONEiO side.

Messaging setup

The way messages are relayed can be decided to suit your best practices. The basic principle is that ONEiO will adapt to any mechanism you will choose to use.

Connecting to a commercial tool

If you're using a commercial tool (ServiceNow, Jira, Zendesk, etc.) directly, the adapter in ONEiO will handle all the needed things to communicate with your tool. This covers all inbound and outbound messaging, including attachments. You can find guides on how to set up tools for integration at Tool-specific guides (Login Required). If you cannot find your tool from the list, please let us know and we'll set it up for you.

Generic APIs

Communication protocol

Communication can be SOAP, REST, FTP, FTPS, SFTP, email, etc. The communication is configured separately for inbound and outbound directions, so you can also use different protocols and transports for them. If you are using some other means, please let us know and we'll set it up for you.

Communication mechanism

Communication can be configured to be push or pull. The preferred way always depends on the tool connected and the needed use case. With modern event-based integrations (e.g. Incident or Change process integrations), the preferred way is that the connected tool sends a message to ONEiO when an update happens. That way we ensure all updates are relayed through the integration in a timely, real-time manner. For more data-driven integrations and legacy systems (e.g. CMDB integrations), polling (pull) setup might be needed. That is possible as well.

Attachment handling

There are many ways attachments can be handled. They can be included directly in the message, or the message can have information where the file can be downloaded. What ever the way is, let us know and we'll set it up for you.

Authentication mechanism

For sending messages to ONEiO, HTTP Basic authentication is used.

For ONEiO to send messages to the connected tool, ONEiO supports all common methods; HTTP basic, OAuth2, SSL certificate authentication, various token based authentication mechanisms, etc. If you don't find the needed mechanism from the list, let us know and we'll set it up for you.