What does it take to start using Service-Flow
There are a few different scenarios, where there will be a need to describe what does it take to start using Service-Flow. 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 Service-Flow is included as a component of the overall architecture.
I want subscribe to Service-Flow and be in control of my own integrations
This scenario means that Service-Flow 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 Service-Flow and we need to implement an integration. What do I need to know/do?
In this case you will be a passive part in the Service-Flow 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.
To enable integration to Service-Flow ecosystem, network level communication between the tool and Service-Flow 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.
Connection to an on-premise tool is always ultimately up to the organization and it's 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
For secure, encrypted communication, there always needs to be valid server certificates at both the tool and Service-Flow side.
The way messages are relayed can be decided to suite your best practices. The basic principle is that Service-Flow 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 Service-Flow 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 integation at Tool specific guides. If you cannot find your tool from the list, please let us know and we'll set it up for you.
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 can be configured to be push of pull. The preferred way always depend 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 Service-Flow when an update happens. That way we ensure all updates are relayed through the integration in a timely, realtime manner. For more data driven integrations and legacy systems (e.g. CMDB integrations), polling (pull) setup might be needed. That is possible as well.
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.
For sending messages to Service-Flow, HTTP Basic authentication is used.
For Service-Flow to send messages to the connected tool, Service-Flow 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.