The purpose of this document is to provide a technical overview of the ONEiO solution. The intended audience is technical stakeholders within customer organisations and ONEiO partners.
About Service-Flow Corporation and ONEiO SaaS Solution
Figure 1: ONEiO Architectural Overview
ONEiO has been developed from the ground up as a multi-tenant platform, which is running in the cloud. Following is a description of its architectural components.
ONEiO Integration Hub
ONEiO Integration Hub is a multi-tenant, cloud-based service that consists of three main components: Broker, Adapter and user interface. This is where the actual integration processes are created, executed and managed. Platform and all related components and services are fully managed and controlled by Service-Flow and thus there's no need for end-users to set-up any technical management procedures.
ONEiO Integration Hub is hosted within the EU in a data center that has successfully passed multiple security certifications, e.g. SAS70 Type II, ISO 27001 and PCI DSS Level 1.
Broker routes messages between systems using content-based rules and applies transformations to the data.
Adapters deliver messages between external systems and the broker. They transform system-specific messages to the ONEiO canonical format enabling routing and data transformation rules. Adapters are either system-specific or more generic and are developed and maintained by ONEiO. ONEiO is constantly on the lookout for more ITSM tools that could be connected to the ONEiO ecosystem through adapters.
The ONEiO user interface is a web application that allows users to view the messaging between their services. It also provides tools for administering systems, routing rules and mappings.
Customer systems are (ITSM, CRM, ERP, etc.) tools connected to one another through the ONEiO Integration Hub. These tools are usually located either inside customer internal networks or in the cloud as SaaS applications.
ONEiO is made highly available and fault-tolerant by building the system as an asynchronous, staged event-driven architecture (SEDA) where components communicate by transmitting messages and responding to events. Communication is further enhanced by persistent queues, which makes the system fault-tolerant as the receiver doesn't even need to be running for the sender to send a message.
24/7 monitoring is used to detect problems as they occur and to alert the ONEiO Operations Team. ONEiO database runs in a replicated setting where a crash of a single DB server doesn't bring the whole system down. The replication is done between separate data centers.
ONEiO maintains the service in real-time, i.e. without any customer-visible down-time.
Adapters act as the communication bridge between end systems and the broker performing two main responsibilities. First: adapters transform system-specific messages to the ONEiO canonical format enabling routing and data transformation rules within ONEiO. Second: adapters convert the messages into a adapters specific representation and deliver them to the end system according to the system-specific communication protocol. As there are great differences between end systems, this can mean anything from sending the message as an email to converting it to complex system-specific XML-representations, sent to a SOAP interface using a custom communication protocol.
With adapter functionality, ONEiO produces ready-made recourses; endpoint types. To this entity, ONEiO has built a set of functionalities that enables the user to use the corresponding tool with a minimum requirement of the detailed knowledge of the behaviour of the connected tool.
Endpoint types are either system-specific (e.g. ServiceNow, Jira, Dynamics365, Hubspot, etc.), vendor-specific (e.g. Your-local-MSP) or more generic (e.g. generic SOAP/REST). New endpoint types are developed by ONEiO when there is a new kind of system that needs to be added to the ONEiO ecosystem. There is no additional cost to a customer for this development.
Broker is the central service that handles the actual message routing and stores the integration conversations between related parties. Conversation is a context where all messages and routing information for a single integrated entity (e.g. an incident) is stored. For example, in integration between ticketing systems the conversation has information of all the messages passed between systems for a single ticket. Conversation makes it much easier to understand what has happened and in what stage the integration is in.
Figure 2: ONEiO UI showing latest messages in ”Message queue”.
Figure 3: ONEiO UI showing ticket lifecycle in ”Ticket Conversation”.
Routing is based on rules. These rules contain the following parts:
- Route information (e.g. source system, source entity type, target system, target entity type)
- Operation condition (e.g. create, update)
- Attribute and conversation conditions (e.g. content-based conditions that have to be met for the route to apply)
- Attribute mappings (e.g. the actual mappings from source to target data)
- Attachment mappings (whether to send attachments, possible filtering etc.)
Multiple rules can match the incoming message and in this case it might be routed to multiple target systems.
Attribute mappings are the actual workhorse in transforming data between separate systems. ONEiO supports many kinds of different mappings, like direct copy from field to field, template, append, 1-1 translation and n-n translation.
Figure 5: ONEiO mapping editor
Connecting to ONEiO Best Practices
Extending your ITSM processes outside the boundaries of your organisation requires integrating with the service provider's ITSM system, for instance by using ONEiO. Establishing a secure bi-directional network connection that enables the connectivity typically requires changes to the network infrastructure in which ITSM -tool has been deployed.
Connecting a SaaS ITSM tool that runs outside the customer network
If the ITSM tool is already running outside the customer network, it can usually be connected through HTTPS from ONEiO without any additional network settings.
Figure 6: SaaS connectivity
Connecting an ITSM tool that runs in customer internal network
A reverse proxy acts as a controlled gateway between internal and external network resources by publishing internal services (i.e. ITSM-tool) to external users (here ONEiO). By placing the reverse proxy in a Demilitarized zone (DMZ), access to it can be controlled and fine-tuned to match your requirements. Typically, access from the public internet is limited to HTTPS from ONEiO while the service published is the web service API of ITSM tool. By using a reverse proxy, you retain full control of your network and security while gaining the additional benefit of using external services.
Figure 7: Secure reverse proxy -based connectivity between customer and ONEiO
We at ONEiO take security very seriously. For a SaaS solution that communicates with several services across network boundaries, security is a critical aspect that must be carefully scrutinized on several layers.
ONEiO needs to store data into its database. This data includes all the messages passing through the system, user account information and configuration. ONEiO needs to store all the message information at least until the message has been processed and sent to target system. All data routed by ONEiO is stored securely within the certified data centers with strict Access Control.
ONEiO encrypts the messages that it has received and stores it to it's database in encrypted format. ONEiO servers have an encryption key used in the AES encryption. This key is generated by ONEiO and known only by ONEiO, so even if someone could get access to the DB, they cannot read the message payloads.
All communication between ONEiO components needs to always be encrypted. ONEiO uses HTTP over TLS between web browsers and the components running in cloud and also between all internal services. ONEiO uses SSL certificates signed by trusted, well-known certificate authorities.
ONEiO is deployed to Amazon Web Services (AWS) cloud in Ireland.AWS has successfully passed multiple security certifications, e.g. SAS70 Type II, ISO 27001 and PCI DSS Level 1.
AWS related reading:
Communication between your ITSM tools and the ONEiO is secured by strong certificates signed by well-known Certificate Authorities. For most cases, HTTP over TLS (HTTPS) is the preferred communication protocol, providing strong security with minimal changes to your infrastructure.
ONEiO Integration Hub is a distributed system where access to the services is controlled by Access Control Lists. The services are developed and tested according to industry best practices (OWASP ASVS), with security, fault tolerance and availability in mind. ONEiO application security is audited yearly by an external security company.