What are the most important iPaaS features that are needed today?
- Robust set of pre-built connectors
- Ability to easily create custom connectors
- Strong data mapping functionality
- Easily choreograph service interactions
- Configurable workflow triggers
- Consumability—artifacts created in iPaaS, like connectors and flows, can be consumed from within the platform or invoked externally as an API
- Seamless integration with API Management
READ MORE: Learn the difference between iPaaS and API Management.
Important iPaaS features in detail
Robust set of prebuilt connectors
Agility. Speed to market. Minimum viable product. An iPaaS needs to support these goals by providing simplified integration with a wide set of common services. The ability to start integrating within minutes while using no coding skills is a key consideration when selecting an iPaaS. Connectors encapsulate the security and vendor-specific logic required to communicate with a service and present it to the integration specialist in an easy to consume format. Configure a connector once and reuse it across your enterprise. Keep the vendor-specific details in the connector and out of your application code.
Ability to easily create custom connectors
Even the most robust iPaaS cannot account for every integration, so it needs to be simple to create new connectors and add them to your catalog. The platform should provide the ability to create a connector from existing services and APIs in your catalog by importing the service definition (JSON, Swagger, SOAP). This will allow you to extend existing APIs and leverage them as components in the iPaaS. Breathe new life into existing services by making them available within your iPaaS and give your application developers simplified access to your enterprise’s full set of capabilities.
Strong data mapping functionality
Services from various vendors are not designed to communicate with each other. Facilitating communication is a basic function for an iPaaS, but what about the data in each system? The data structure for a customer in your SaaS CRM system probably does not look like the customer data structure in the internal system you are trying to integrate it with.
Strong, visual, data mapping tools get you out of the business of data integration by allowing you to create a common data model to use within your integration. iPaaS will automatically map data to and from your common data model and the systems you are integrating with.
Maps can additionally be leveraged to insulate orchestration flows. Did the service you are integrating with change its data model? Just update the map. Want to easily extend your orchestration to integrate with an additional service provider? Just extend the map to include the data model of the new service provider.
Easily orchestrate service interactions
Connectors deliver easy-to-consume interfaces to services, workflows help you bring them together into meaningful processes. An iPaaS should deliver a visual interface for constructing reusable workflows, providing the integration specialist with the ability to build, test and deploy new integrations.
The workflow allows you to orchestrate service calls and inject any necessary business logic between them. Once a workflow has been created it becomes a reusable asset itself, allowing integration specialists to create new integrations by changing the service endpoints. New integrations can be created in minutes rather than days.
Configurable workflow triggers
An iPaaS should deliver flexibility in how workflows can be invoked. Some workflows will trigger when an event occurs while others may need to be invoked directly. Event-driven, scheduled or directly invokable via API are patterns that need to be supported in order to cover most use cases.
In an event-driven workflow, a connector can either poll or be notified by a service. When the event occurs, the workflow will be triggered. This can be used in scenarios where you need to keep data synchronized between systems or when an event in one system should trigger a series of events in other systems.
Invoking a flow via an API can be used in scenarios where you don’t want to embed flow logic into an application. Rather the application can send a request, containing all pertinent information, to the iPaaS workflow and allow it to execute the flow logic. This pattern simplifies application code and allows the flow logic to change without impacting your deployed applications.
We touched on this point briefly before when mentioning that workflows can be invoked via an API and how that can be used to streamline the code of applications that consume integrations. Remember connectors? They should behave the same way. When a connector instance is created it should present itself to the integration specialist and application developer as an API. Since the connector contains the credentials required to connect to the service, you don’t need to include it in your application code.
Now your application developers need not contact your CRM administrator whenever they are building an application that needs to read customer data, they just invoke the connector which has encapsulated the credentials. Now, since the connector contains the credentials for reading your CRM you are going to want to control who can invoke the connector which leads us to…
Seamless integration with API Management
Connectors, maps and workflows all sound great, but in the real world, you are going need to control who has access to which resources. The ability to seamlessly surface the APIs exposed by your iPaaS assets within an API Management solution is critical to a secure implementation. API Management allows you to create a secure proxy layer between your iPaaS and the applications which consume its resources, allowing the implementation of policies to control access, rate limiting and service level.
Want to know more? Learn how it’s iPaaS to be HIP and HIP to be iPaaS.