For most of us who deal with custom development every day, one of the top challenges in every software project is app integration. Whenever the requirements mention any kind of integration, development teams tend to add a big uncertainty factor, regardless of the technology being used or the system to integrate with. The fact is that every integration has its particularities, and not all are that easy to identify or disclose up-front.

For that reason, development teams typically plan to resolve the integration part at the very beginning of the project, even if the project is just a small proof-of-concept (POC). They do so to make sure that the integration is possible, which mean answering “yes” to the following questions:

  • Can both systems communicate with each other, and is there no firewall/proxy or any other connectivity constraints?
  • Can the authentication to the external system APIs be done?
  • Does the development team have the connection or the necessary tokens/credentials/certificates to configure the integration?
  • Are the required APIs and data available?
  • Does the development team have someone who is an expert on that specific type of integration? I.e., do they somehow understand target system APIs, communication protocol (REST, SOAP, OData, etc.), or the authentication flow (oAuth, JWT, etc.)?

Only after clearing all those questions, development teams are optimistic that the project can be delivered according to the requirements and planned schedule.

This is greatly reflected in OutSystems survey “The Speed of Change: How Fast Are You?”, in which 2,200 respondents (not OutSystems customers) ranked "integration with legacy systems/lack of APIs” the top reason for application delivery delays. Respondents also mentioned that API/integration backend development was the third skill in which internal development teams plan to invest in training in-house developers.

Top challenges that slow down app delivery. Source: Speed of Change report.  
 
Skill development priorities. Source: Speed of Change report.

In addition to that, according to Gartner,

“By 2025, more than 70% of large enterprises will move from a single-vendor monolithic ERP strategy to a more inclusive composable strategy.”

This means that organizations are on the path of having more and more systems that will have to communicate with each other efficiently.

Enters Integration Builder

Having this in mind, OutSystems released the Integration Builder, which completely changes the paradigm of how integrations are configured in OutSystems.

Integration Builder offers to any developer, regardless of the skillset or expertise, the ability to leverage data and services available in other systems to create integrations faster. With Integration Builder, developers only have to go through a handful of configurations like choosing the target system, selecting the data that the OutSystems application requires from the external system, entering the external system credentials, and then using the connector across multiple OutSystems applications.

Although Integration Builder should be used as the first choice when doing integrations in OutSystems, there are other two ways to connect OutSystems to other systems:

  • Development teams can implement from scratch the integration using the platform’s REST and SOAP capabilities
  • Or rely on OutSystems thriving Community, which contributes with many connectors available on the Forge.

So, when should you use what?

Integration Builder vs. Forge Connectors

A few months ago, OutSystems MVP Marco Arede published a great article comparing Integration Builder with implementing an integration in a manual way.

Inspired by Marco’s blog post, I decided to make a similar comparison to show you the difference between using Integration Builder connectors versus using community-based forge connectors. This isn’t to say that using Forge connectors is a bad option; quite the opposite. But in cases where we have an Integration Builder connector, there are additional benefits you can leverage.

Disclaimer: in this analysis, I didn’t consider just a particular connector or type of connector. Generically, any Forge connector will have all or most of the characteristics described.

table-bp-integration-builder-vs-forge-connectors-v2 

When to Use Integration Builder or a Forge Connector?

There is no one-size-fits-all when it comes to an integration scenario. That’s why we provide several options that can be used separately or in combination to achieve the desired outcomes.

Still, the following decision tree can help you decide which is the best path depending on the scenario you’re facing.

Integration builder vs Forge connector decision tree 

Want to Learn More?

Watch How to Integrate Everything and Connect to Anything Tech Talk to learn more about the different ways to integrate your OutSystems apps with external sources.

For other relevant sources, check out the following pages: